Ada County SIG

Our office is beginning a cleanup of road centerline geometry. If you've spent any time at all inspecting that dataset then you'll know that it's not all that pretty - lots of curves that should be smooth but aren't, lots of straight roads modeled with somewhat sinuous centerlines, etc... We've begun the task of cleaning those issues up in order to enhance users' cartographic experience.

One issue that we anticipate arising form this involves anyone who uses these centerline features as boundaries for other polygon features, and the topology between road centerlines and these other polygon features must be enforced. For instance, Rob Hall (Ada County Sheriff) must maintain emergency response areas. Where these areas are split by roads, the polygon boundaries must be coincident with road centerlines in order to ensure that the correct policeman (or fire truck or ambulance) will be dispatched to each side of the road.

If your agency maintains a data layer that is topologically dependent upon road centerlines, please let us know by replying to this thread.

Thanks,
Dan

Dan, we (Boise City) have quite a few layers that are (supposed to be anyway) coincident with street centerlines - primarily, but not always, I-84 and other major roads. Many of our planning layers use street centerlines as the divide between areas. I'm guessing, but I think there might be as many as 10 layers that are supposed to be topologically dependent upon street centerlines. If you need to know exactly, let me know - it will take me a little while to do the research.

Jimae

Thanks Jimae,

I suppose I should be a bit more clear. We want to know so that we can help you develop ways to move the boundaries in these layers to match centerlines . . . or even better, we hope that YOU can show US how to make these changes more easily.

The key is is that the topological relationship must be enforced. There are lots of layers out there that often go to centerlines - zoning is the most high-profile of our layers that falls into this category - but not many of these layers are absolutely dependent upon their topological "correctness" with centerlines. Heck, we don't even use centerlines when creating new zoning features. The example of Rob Hall's police atoms is one example where this topology is absolutely critical. Do all ten (or so - I don't need an exact count) of the layers you're talking about actually depend upon their boundaries being coincident with road centerlines in order for them to fulfill the roles they were created for? Sorry for being such a loquacious boob. Let's try this . . .

In short, I suppose I should have asked, "Will the movement (generally less than 5 feet) of a couple thousand road centerlines break anyone's applications?"

Thanks,
Dan

Dan - you're going to love this reply... To the best of my knowledge, movement of street centerlines won't break any of our applications (as in software applications). However, it will result in our data breaking the data quality rules we have set up for those 10-ish layers.

But... In reality, there is no way for us to enforce those rules now anyway. Since we don't maintain street centerlines, how are we to know if the centerlines move? At one time someone went through and snapped each of those layers to the centerlines. But, I suspect (am fairly certain even) that the centerlines have moved in places since then and we didn't know about it. Thus, our data is already breaking our data quality rules. Other than running complicated GDB topology checks every time we get a basemap delivery, there is no way to confirm coincidence of our layers with the centerlines. In essence, we have ordinances and other formal documents that state that certain boundaries are located along such and such street - but how do we operationalize that in GIS? I'm guessing it's pretty much the same for you and Zoning.

All I can say is 1) we do the best we can and 2) do what you need to to adactl (street centerlines) and Boise City will work with it. At least that's my opinion. Thanks for keeping us posted on changes! 

Dan,

Jimae is correct in stating that none of our applications will fail (I hope).  However, there are approximately 16 layers to my knowledge that use the centerline as a boundary either by description or design.

I agree with Jimae that we would need to figure out how to snap to the new centerline to create integrous data.  It gives me a headache just to think about it!  But let me state that I am all for it.

I appreciate your efforts to take this project on since it has long been one of the sources of concern for me.  Do you have an approximate date of completion so I can set up a plan for making changes to the data I maintain?

Barb

Dan, I think we're fine here at ACHD. Thanks for tackling these improvements!

 

Chuck

Thanks Barb & Jimae & Chuck,

For cases like Boise's situation, I think there's a solution. It's not a nice, neat, elegant solution; but it's a solution nonetheless. To introduce the solution, I think you'll need a bit more information on the project . . .

We converted our adactl coverage to a SDE feature class for this cleanup process. Our goal is to clean it up in SDE (while also performing all the usual regular maintenance on it), and once it's all cleaned up we can abandon the adactl coverage altogether. Meanwhile, we're continuing on with business as usual in the coverage (without doing any cleanup), so the adactl that we'll be delivering for the next couple months will still be exported from the coverage.

Once we're ready to flip that switch and abandon coverages (there'll be another change management request for that when we have an ETA for the finish of the cleanup project), we'll put out two centerline datasets simultaneously. One will be from the coverage and one will be from the cleaned-up geodatabase. Both will be from the same moment in time so they should be identical other than the cleaned up lines. At that point, users can add both datasets to a topology; where features from one dataset don't overlap features from the other, there are your changes.

Fair warning: that topology will be redder than the first draft of my thesis was after my advisors got done with it. :) But that shouldn't surprise anyone who's ever taken a close look at adactl.

Does that sound like it'll work? Have I overlooked anything? That won't *fix* the slivers we're creating, but it'll alert you to them anyway.

Thanks,
Dan

One additional change that will be made: the road centerline feature class will not contain railroads and runways. Those features will be stored in a separate feature class and can be distributed to anyone who relies on them.

Note the sample dataset that I've posted in the files section of this website.

One MORE additional note: There *will* be schema changes to this feature class, but they haven't yet been determined. For now, our effort is focused on cleaning up the geometry and refining routability. Of course, with these schema changes, we don't anticipate abandoning any of the information currently contained within adactl, but we anticipate reorganizing it, making field names more meaningful, and that sort of thing.