Height parameter puzzle

2543
8
06-09-2011 08:03 AM
RobertLindquist
New Contributor
I have a network dataset built which includes a parameter for vehicle height.  Starting at the same origin and continuing to the same destination, I try to solve for a vehicle of differing heights.  For example, the first test tries a vehicle of 14'2" (170 inches) and a route is successfully created.  The second test tries a vehicle of 14'6" (174 inches) and a route is NOT found -- this of course could be correct -- height issues could prohibit this vehicle.  BUT, I then try a vehicle of 15'2" (182 inches) and a route is successfully created. 

The question is:  how can the route solver find a way for a taller vehicle to get through when it is telling me that a 8" shorter one cannot get through?
Tags (2)
0 Kudos
8 Replies
RobertGarrity
Esri Contributor
My hunch is that there is an issue with the evaluators for one or both of the network attributes that are required to set up a height restriction. (One descriptor attribute is required to get the max height value from the source features, and a restriction attribute is required to compare a parameter value indicating the vehicle height with the max height value.)

Could you post what type of evaluators you're using and how the values are calculated so that I can try to spot any problems?

I'm guessing you would have something like the following:
1. Max Height Descriptor Attribute:
Attribute Name--MaxHeight
Attribute Type--Descriptor
Evaluator Type--Field
Evaluator Logic--[MaxHeight] (That is, the network attribute value is pulled from the MaxHeight field of your source feature class.)

2. Height Restriction Attribute:
Attribute Name--HeightRestriction
Parameter Name--VehicleHeight
Attribute Type--Restriction
Evaluator Type--Function
Evaluator Logic--MaxHeight < VehicleHeight (That is, the edge is restricted if the vehicle height parameter is greater than the maximum height descriptor attribute value. Note that one possible cause for the unexpected routes is that your comparison operator might be an equals sign rather than a less-than sign.)

Regards,
Robert
0 Kudos
RobertLindquist
New Contributor
Robert:

Thanks for your response.  Here's what I'm using for evaluators:

1.  MaxHeight attribute
Attribute Name--MaxHeight
Attribute Type--Descriptor
Evaluator Type--Field
Evaluator Logic--[MaxHeight]
The MaxHeight attribute in the streets table is defined as long integer and contains values for vertical clearance in inches i.e. 176 (or 14'6") for segments affected by a clearance issue.  For all other segments the value is set to 1000 inches (which effectively allows passsage of any height vehicle).

2.HeightRestriction
Attribute Name--HeightRestriction
Parameter Name--VehicleHeight  (default value of 0)
Attribute Type--Restriction
Evaluator Type--Function
Evaluator Logic--MaxHeight < VehicleHeight  (I was hoping that I'd mis-entered an = operator as you suggested, but it is <

I have tested some other vehicle heights on the route and the interesting thing is that values in the 0 - 171 inches range pass; values of 172, 173, 174, 175, and 176 fail; and values over 176 pass.
0 Kudos
RobertGarrity
Esri Contributor
Thanks for posting the info about the attributes, Robert. Unfortunately, I'm not sure what is causing this issue given what I know so far. Would you mind clipping out the source features around the area of your route and sending them to me to see if I can fix the problem? My email address is my user name followed by @esri.com.
0 Kudos
RobertLindquist
New Contributor
Thanks Robert.  I just sent some data, along with some more explanation.  You should be getting an email notification from Illinois CMS that the data has been sent to you, and a link to retrieve it.
Bob
0 Kudos
RobertGarrity
Esri Contributor
I haven't received anything yet. Did you send it to rgarrity@esri.com?

Thanks,
Robert
0 Kudos
RobertLindquist
New Contributor
Sending now ... there was a problem with the file transfer service ... fixed now.
0 Kudos
RobertGarrity
Esri Contributor
Hello, Bob. It looks like this is a problem that has to do with the interplay of network hierarchy and restrictions.

There's a lot to it, but I'll try to explain. When hierarchy is used in a solve, the solver looks for ways to step up the hierarchy levels and, as it does so, filters out lower-levels of the hierarchy from the search. This hierarchical filtering process is optional, and is offered to speed up the solve time; however, a drawback is that it makes the network more sparse, and thus makes it more likely for the network to become disconnected, which in turn would make it impossible for Network Analyst to find a solution. (Another drawback is that a solution may be less than optimal.)

There's a help topic that explains the basics of hierarchy: About network analysis hierarchy. See the graphic at the bottom of the topic for a quick explanation of broken hierarchies.

"Hierarchy transitions" are the points in the network where edges with lower level hierarchy values connect to edges with higher level hierarchy values. As the route is being solved, a limited number of hierarchy transitions are found before Network Analyst stops searching for higher levels or for the connecting backwards search from the second stop. (If it connects with the backwards search, a solution is found.) If the transitions found exceed a maximum specified number, and a solution isn't found or the highest level of the hierarchy isn't found, the solve fails.

By tossing restrictions (and barriers) into the mix, the network is more likely to become disconnected. Also, the edges that are searched and the transitions that are found are likely to change when restrictions are present.

What's happening in your case is the non-exhaustive hierarchical search is funneled to different areas of the network due to different height restrictions. For example, the route you solve for vehicles with a height of 177 inches hit a restriction earlier on in the search than the vehicles with a height of 176. Therefore, the searches for the two different routes continue in different areas of the network. As you can see in the attached graphic, the route for the 176 inch vehicle doesn't quite find the backwards traversal. (The points in the graphics represent the junctions that were reached in the search. The two red ovals highlight where the bidirectional search almost connected.)

A big factor in failing to find a solution here is that you are restricting tollways, and tollways make up most, if not all, of your 1st level hierarchy. So if the solver can't get up to the highest level, it will only search out on the second-highest level until the default limit of hierarchy transitions are found. If it could get on the highest level, it wouldn't limit itself by transitions, instead it could potentially search the entire level. As long as both searches in the bi-directional search can reach the highest level of the hierarchy, and the hierarchy isn't disconnected, you've got a route.

So that's the general problem, below are some solutions.

Solution 1: Turn off the hierarchy.
Restrictions can still disconnect two areas of a network even with hierarchy off, but they are much less likely to do so. In this problem, a solution is found when hierarchy is off.
Solves will take a bit longer with this solution, but you won't have as many failures.

Solution 2: Adjust the hierarchy of your network.
This is to compensate for restricting tollways (i.e., the highest hierarchy level). I'd suggest redefining the hierarchy to four levels and group Func_Class values of 1 and 2 into the highest level (1).
Solves will take a bit longer with this solution as well, but you won't have as many failures either.

Solution 3: Increase the maximum number of transitions searched.
This is a very advanced solution because it requires editing your system's registry. I'm just mentioning it, but not recommending it.
It's done by...
1. Adding a DWORD value to the following key: HKEY_CURRENT_USER > Software > ESRI > Desktop10.0 > NetworkAnalyst > ODCostMatrix > MultiAStarAlgo.
2. Naming the DWORD value "NumTransitions".
3. Entering a numeric value for NumTransitions.
I tried bumping the value up to 40 and the route solved successfully, you could probably get away with using a smaller number. (Deleting the DWORD value entirely returns the number of hierarchy transitions that are searched to the default.)
Again, solves will take a bit longer if you use this method.

I hope this is helpful to you. Let me know if I can try to clarify anything.

Best,
Robert
0 Kudos
RobertLindquist
New Contributor
Thanks for the explanation, and for all the time you took to help with this problem.
0 Kudos