U-Turn Restrictions

[JustinHunter]

Version 10.1 - I cannot seem to get Network Analyst to respect the restrictions I've allocated for U-Turns. Directly in ArcMap I have "U-Turns at Junctions" set to "Not Allowed" and when I solve one of my routes I get a u-turn one of the first steps.

I also notice that when I run this same route through my ArcGIS Server it does not make the U-Turn even though I have one of the RouteParameters as RestrictUTurns = "esriNFSBAllowBacktrack"

Yes I understand I'm trying to get them to do the opposite. In fact, I'm trying to get them to act the same. As I began testing my application I noticed that not allowing U-turns will cause issues, but I can't get my ArcGIS Server to allow me to allow them. Trying to duplicate what my server does I set my ArcMap to not allow U-turns but it allows them no matter what I say.

I cannot seem to figure this out. I even published my ArcGIS Server with the setting of: Restrict U-Turns: esriNFSBAllowBacktrack

Thanks

[JaySandhu]

The no turn policy at a junction prevents u-turns on to the same edge. It is most likely that the castle downs road is a divided road and a turn is being made on to the other side. Directions puts in the word to indicate you are making a U turn there but it is not a u-turn on the same edge. If you want to prevent u-turns at divided roads then you will need to digitize turn restrictions in a turn feature class that participates in that network.

Regards,
Jay Sandhu

[JustinHunter]

Ok, that much is understood. Could you assist me in figuring out why my ArcMap and ArcGIS Server act in complete opposites? All settings are identical, so far as I know.

[JaySandhu]

The ArcGIS Server and ArcMap call the same underlying solver. So there should be no difference in how the actual solve happens. The difference is in what settings are on or off between the two different ways to call the underlying solver. Perhaps there is some different restrictions set, or in ArcMap hierarchy is OFF but server has it set to ON, or the points are being located on a different edge or with different curb side properties. So I suggest changing some properties in ArcMAP and seeing if you get the same route as server. If you cannot find any differences, then I suggest you can turn on logging in the server and capture the calls being sent for the route solver and post them here and also post a screen shot of the proprerties of the route layer (analysis settings and/or attribute parameters) from ArcMap and also the route/directions that you get from server.

Jay Sandhu

[JustinHunter]

After doing much testing I have come to the conclusion that UseHierarchy as a RouteParameter does not do anything. When I run this directly from the REST API http://blahblah/arcgis/rest/services/routeservice/NAServer/Route/solve it makes a difference, but

RouteParameters param = new RouteParameters();
param.UseHierarchy = false;

does not get considered - it always uses the default that the server was created with. Perhaps a bug? Is there any way I can verify this. I'm using .NET - I tried to run Fiddler but nothing was being picked up - new to that application so I'm not sure if I have to modify it. I also turned logging to debug, but there was no actual data displayed.

[JustinHunter]

To sum things up - I re-set up my routing service and started doing testing. I'm able to get my server and map to match except for one issue. There are circumstances where the WPF Toolkit does not send the UseHierarchy flag to the REST API so no matter what you set it to in your code, the server always uses the services default. I turned on Fiddler to do some more in-depth investigating and this is the conclusion I have come to.

I guess just seeing it use a 'connecting road' between a highway to do a u-turn, I assumed it was another issue. This is completely unrelated to u-turns, but the connectivity between the WPF Runtime and the REST API.

This is most unfortunate.

[JustinHunter]

For a final word - RouteParameters() { UseHierarchy = false }; does not send anything to the REST API, however UseHierarchy = true does. Therefore I re-published my routing service to have hierarchy off by default, that way I have the ability to toggle it on and off through the RouteParameters. Publishing a routing service with hierarchy on will never allow you to solve a route with hierarchy off.

I thank you for your assistance, once you explained the u-turn function it helped me begin investigating other avenues.

[DmitryKudinov]

The problem with not serializing-out useHierarchy=FALSE parameter was addressed in latest release of WPF SDK 1.0 (June 2012, assemblies versioned 3.0). Please try it.

If you cannot upgrade to the latest WPF SDK, there is a workaround:

<esri:RouteTask Url="http://tasks.arcgisonline.com/ArcGIS/rest/services/NetworkAnalysis/ESRI_Route_NA/NAServer/Route/Solv..."
                   
Basically you�??ll need to define the full url to the operation in the route task, set the useHierarchy parameter manually, and include a placeholder to neuter the addition of the operation (e.g. Solve) by the API.

Hope this helps,
Dmitry

[JustinHunter]

The problem with not serializing-out useHierarchy=FALSE parameter was addressed in latest release of WPF SDK 1.0 (June 2012, assemblies versioned 3.0). Please try it.

If you cannot upgrade to the latest WPF SDK, there is a workaround:

<esri:RouteTask Url="http://tasks.arcgisonline.com/ArcGIS/rest/services/NetworkAnalysis/ESRI_Route_NA/NAServer/Route/Solve?useHierarchy=false&amp;x="
                   
Basically you�??ll need to define the full url to the operation in the route task, set the useHierarchy parameter manually, and include a placeholder to neuter the addition of the operation (e.g. Solve) by the API.

Hope this helps,
Dmitry

Thanks for your time, Dmitry. I'm not sure if there's a difference between the ArcGIS API for WPF and the ArcGIS WPF Runtime, but I'm using the API. Either way, I'm satisfied with my work around but I appreciate the information. 🙂