Help the NA Team improve workflows involving barriers and restrictions

[MelindaMorang]

Dear Network Analyst users,

The Network Analyst Team would like input from those of you who work with barriers and restrictions in Network Analysis layers.  Your input on the following topic will help guide our development efforts:

When you use restrictions or barriers, these restrictions and barriers can sometimes conflict with locations (stops, facilities, origins, destinations, etc.) in your NA layer. For instance, a new polygon barrier might fall on top of one of your existing points, causing your Route to fail at solve time because the existing point is located on (snapped to) a restricted network edge.  Similarly, if you turn on a restriction, a point might be rendered inaccessible by the restriction, causing your solve to fail.

If you have experienced this behavior, please answer the following questions:

• Do you view this behavior as a problem?  Does it annoy you, hinder your analysis, etc.?

• If this behavior is a problem for you, how do you currently work around or avoid this behavior (eg., loading barriers and setting restrictions before loading stops, toggling the "Exclude restricted portions of the network" button)?

• If this behavior is not a problem for you, do you want your solve to fail if your stops/facilities/origins/destinations are located on a restricted edge?  Why?

We are currently improving upon the behavior described above.  In our new design, points located on (snapped to) edges that have become inaccessible due to a new restriction or barrier will be automatically relocated at solve time to the next-closest non-restricted edge (within the specified search tolerance).  Solve will always succeed.  You will no longer need to worry about loading your barriers and input points (stops, facilities, etc.) in a specific order.  You will no longer need to relocate your input points if you change your restrictions. Conflicts will be detected and corrected automatically at solve time.

Points that have been relocated will be flagged in the attribute table with a status of "Not located on closest" so that you can see which points have been affected by the auto-relocate behavior.  Another field will show you the distance of that point to the network edge it was located on.  You can use these fields to double-check the behavior and manually correct the locations if necessary.

• What do you think of this idea?

• Do you have any concerns?

• Is there anything we've missed that could further improve your workflows?

Please feel free to discuss these topics here.  If you would like to discuss them more extensively by phone or e-mail, please send me a private message through GeoNet, and I'll let you know how to contact me.

Melinda Morang

Product Engineer

Esri - Network Analyst Team

[RellFowler]

Hello Melinda,

Thanks for the suggestion and the post!  I think this is a great  idea and will allow some options where we have experienced issues with points that fail.  I like the classification of the result as using closest, that allows a solve while notifying that it may not be the best solve.  I am still concerned about the impact of points that still fall outside of the range specified (for instance if it is set to 500 feet and a suitable edge is not found). 

To be honest, the biggest issue we have is the failure to produce a solve if any of the input points are not valid.  The option to Ignore Invalid Locations resolves this problem but our users are not happy since the failures can alter the results, i.e. removing locations that are required for the solve.  Conversely, if the option to ignore these invalid locations is false, then any collection of points with any single or multiple invalid locations will not run, only error out.  Is there a way to report a failure with the Ignore Invalid Locations as false and still solve for the remainder of the locations?  Perhaps return the point that was invalid so the end user knows which one was failing?

[MelindaMorang]

Thank you so much for your input, Rell.

Regarding points that still fall outside the range specified: If this is a consistent problem for you, you can just increase the search tolerance (range).  Is there some other reason increasing the search tolerance wouldn't work for you?

Regarding the Ignore Invalid Locations setting:

The current ArcMap 10.x behavior is as follows:

• If "Ignore Invalid Locations" is checked True: The solve succeeds, but it throws a warning message saying 'Location "[blah]" in "Stops" is on a non-traversable network element position.' That location is simply skipped, and the route will bypass it completely.
• If "Ignore Invalid Locations" is unchecked False: You get the same warning, but the solve fails, and no output is produced.
• You can also uncheck the "Terminate on Solve Error" option. The tool now always succeeds in running, even if no output is actually produced because the solve failed.

So, to summarize: Regardless of your "Ignore Invalid Locations" setting, you can always extract the features that caused the problem from the warning messages.  If you want solve output to be produced, you need to set "Ignore Invalid Locations" to True.  Does that answer your question?

The proposed new behavior wouldn't change the "Ignore Invalid Locations" setting, but it would make it much less likely that points would be invalid in the first place.  They wouldn't locate on restricted areas to start with, and if the restrictions and barriers changed after they were located, they would be relocated automatically at solve time.