OK I have a road database layer where all the streets have been sequenced in a non-geospatial order by segments.
These segments may divide by owner (Town, State, etc...), and/or crossing from and to street (in their own separate fields). And then there is a road name field, and a field with an attached road segment number. Unfortunately the road segments have NOT been arranged in geospatial sequence for the road. So you might have a road go
road_1, road_4, road_3, road_6, road_5 if you had attached each segment together in their actual sequence they are attached together by the same road name. I would like to use the network toolbox to get these segments all in sequence from beginning to end based on their geospatial proximity to the next segment. What's the quickest way to do this? The original file is a shape file with an attached DBase file.
Note: I just have a basic license. Do I need to add the Network Analyst license, or can I still use a tool that doesn't require it from the Network Analyst Tools toolbox?
Solved! Go to Solution.
I do not see any association between that conclusion and anything that either I or Richard have said.
Why is it so difficult to answer the question? Is there any value in getting the Network Analyst to help improve my results of this tool or not? If not, then just say so.
Thank you.
quite simply, tools are not a panacea for understanding
LR and Network Analyst both behave better with networks that have correct attributes and geometry. LR is primarily best for facilities management tracking that is concerned with events along a single roadway that is logically named and that follows a well laid out path between two end points, while Network Analyst is best for routing and analysis that can follow any of the possible paths on the entire set of interconnected roadways.
Each tool set will reveal different weaknesses of the network in the geometry or attribution. They each have strengths and weaknesses that the other may address.
They both work best when topology is correct and roadway connectivity is explicitly contained in the geometry without the need to apply fuzzy tolerances that may introduce unexpected connections or disconnections. A geodatabase topology is often a third component of a good network that provides the best approach to resolve issues in the network geometry that will improve the network for both LR and Network Analyst.
My method does not use Network Analyst. I have much more recently created a network from my centerlines, but so far I have not made any changes to the process to replace the fields.
The two do have some overlap, for example, both need to be aware of one-way verses two-way segments, since I make separate routes for each direction when the roads separate into one-way segments. To deal with roads that split and merge into one-way and two-way segments I added fields to my LR creation process that separate North or West segments from South or East segments. When it follows a merged two-way segment the Route IDs for both directions are applied and when it splits to a one-way segment only one of the directional Route IDs is applied according to the one-way direction. Split roadways are a reality, but they tend to be a pain for facilities management, since they create more complexity in the ways things need to be referenced that the field crew descriptions leave ambiguous. In my network, with the exception of freeways/highways, I have dissolve dual centerlines to single centerlines in all but a few cases since facilities management takes priority over network routing in my operations. These routes are a subset that undergo a separate process for route creation from the 90% set of routes that don't involve one-way segments, since it takes more steps to separately create them and merge their schema back into the simpler to generate dual-direction routes.
A person who has a well defined network for network analyst will have to identify these roads as well, but they may favor retaining of split roadways if they do not consider facilities management to be a priority and instead need to solve routing problems primarily. In my experience, centerlines have no single form that fits all needs perfectly and each organization has to adjust the network layout to fit their primary mission objectives.
Thank you. I didn't see this answer until now. Well at least now I know.
Good discussion here. I just want to add that the network analyst tools like the route solver can help "reorder" a set of roads using the Find Best Order option. So if your street data is topologically connected, then you could build a network dataset on top of it. Make a route analysis layer, select all the roads with same name, say, main street, and then select all the end points, hint: nodes (or create mid-points using the Feature to Point tool) and load them as stops and solve with Find Best Order option. This will create a new route and each of the input points will have a sequence number in order that you can use for the order. So you could automate this process for each unique road name in your data and as Richard alluded to in one of his posts, you can get 80% work done this way and rest manually. The linear referencing (dynamic segmentation) approach to constructing a "Route" needs a name to group the streets and then some fields with measure values to order the streets into that route. And I think that is what you are missing, the measures. So you can not use the dynamic segmentation to geo-spatially order your data.
Another tool that may help you in your efforts is a GP tool called SORT that can reorder your rows based on an input sequence. Network Analyst has a tool called DissolveNetwork that merges adjacent roads if it can (to reduce the number of edge) and spatially sorts them on disk to make it more efficient to retrieve (for faster route solves).