AnsweredAssumed Answered

Help the NA Team improve workflows involving barriers and restrictions

Question asked by MMorang-esristaff Employee on Mar 25, 2015
Latest reply on Mar 26, 2015 by MMorang-esristaff

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

Outcomes