Network Hierarchy appears to be overridden by cost parameter

[RobertLindquist]

I have used the Street Data Processing Tools available for processing Navteq streets data in ArcGIS 10.  The only twist is that I have added a "jurisdiction" field to the Streets data in order to segregate State jurisdiction roads from Non-State jurisdiction roads; an integer field where state jurisdiction = 1 and non-state jurisdiction = 2.  I then use this field as a Value for the hierarchy attribute. 

The problem is:  when I create and solve a route, it appears that the hierarchy is not being observed.  It appears that the Cost attribute is trumping hierarchy:  at times the route leaves a state road onto a non-state road and then re-joins a state road later in the path.  It is my understanding that once a route hits the highest level of hierarchy, it should not leave that level.

[MichaelRice]

It is my understanding that once a route hits the highest level of hierarchy, it should not leave that level.

This understanding is close but not 100% correct. Only once the search has explored "far enough" will it start to filter all but the higher hierarchy levels. Specifically, the search begins by allowing all hierarchy levels to be explored. Once it has reached a certain number of entries from its starting point into the next higher level, it will begin filtering all lower levels. This process iterates, progressively moving up in the hierarchy for long-range routes.

However, if your stops are relatively close together (or if there are not very many nearby entries into the next level), a path may be found before the search starts to filter out the lower levels of your hierarchy, which can give the results you are seeing.

Hierarchy attributes are intended primarily for speeding up the results of long-distance routes, without losing too much accuracy (i.e., we still want to find the shortest path possible). Can you offer some explanation as to why you are using this particular hierarchical formulation (i.e., using state-jurisdiction vs. non-state-jurisdiction roads)? What is the primary distinction between these two classes? What is the average distance of the routes you are trying to calculate?

[RobertLindquist]

Michael:

Thanks for the fast reply.  The reason for this hierarchical formulation is:  I am working on an application for the permitting of overweight/oversize vehicles for the State DOT.  They only have authority to issue permits on state jurisdiction roads, however truckers typically begin and end a trip on non-state roads -- they need to travel a short distance to get to a state road and are required to get a permit from a local authority to do so.  The idea is to minimize the number of local permits required and to assign the majority of the route to state jurisdiction roads.  So we are attempting to create routes which get to a state jurisdiction route as quickly as possible and then stay on state jurisdiction routes for as long as possible, even if an intermediate portion might allow for somewhat faster travel.

So, I'm trying to establish hierarchy that keeps these guys on a state jurisdiction road.  Some routes are long (hundreds of miles across the state) and some are short (just across town).  Any suggestions that you can provide would be greatly appreciated.

Thanks,

Bob

[MichaelRice]

This is quite an interesting use case. I think there is a better solution for you than trying to use a hierarchy attribute, as this is not really how they were designed to work. Below is a suggested formulation for solving this particular problem.

...we are attempting to create routes which get to a state jurisdiction route as quickly as possible and then stay on state jurisdiction routes for as long as possible, even if an intermediate portion might allow for somewhat faster travel.

This would suggest the creation of routes from a starting point, s, to a terminal point, t, broken up as follows:

s------>x------------------------>y------>t

The goal is to minimize the distance from s to x (its nearest entrance to state roads) and from y to t (where y is t's nearest exit from state roads), regardless of the shortest path cost between x and y.

Therefore, you can solve this as follows. Create a new restriction attribute in your network dataset called something like "State roads only", which returns false for state-jurisdiction roads and true for non-state-jurisdiction roads (this restriction effectively restricts all but state roads from travel, since true means restricted in the context of restriction attributes). Precalculate and store all entrance points onto your state roads. Call this set X. Similarly, calculate and store all exit points from your state roads. Call this set Y. Note that X and Y may have some members in common.

Now, for a given s-t route pair, create two Closest Facility layers. In the first, load s as the incident and set X as the facilities. Solve to find the single closest facility, x in X, based on traveling from incident to facility (this is an option on the analysis layer property pages). In the second layer, load t as the incident and Y as the facilities. Solve to find the single closest facility, y in Y, based on traveling from facility to incident.

This gives you the shortest path from s to x and from y to t, as defined above.

Then, you can create a new Route analysis layer to find the shortest path from x to y, making sure to turn on your "State roads only" restriction attribute for this solve, so that this path can only travel along state roads. You can combine the three separate subpaths to form your final, desired path.

Of course, you can further streamline this process if you have many such s-t pairs to process simultaneously, but hopefully you get the point. Please let me know if you have any questions about this suggested approach.

[RobertLindquist]

Michael:
Thanks for the suggestion.  It all worked, the interesting problem now is to figure out how to make all of this happen in an application in which the customer needs only to enter the origin address and the destination address.
Bob

[MichaelRice]

The simplest way might be to build a Geoprocessing model, which takes the input origin and destination addresses and processes the rest. The suggested workflow would seem like the perfect candidate for such a GP model.