Return features from Network Analyst Route solve

[AndyWhitaker1]

Is it possible to have the Network Analyst return the features (route segments) on a route?  It seems we only get the merged geometry and directions.

[AndyWhitaker1]

Hi @MelindaMorang, no @FabianoFerrazza3 and I are not working together, but his contributions to the question have been very helpful to me.  As @FabianoFerrazza3 has stated, it would be great to toggle this feature through the REST API or even the ArcGIS for JavaScript API.  As the web application developer, I do not have direct access to our organizations GIS servers, and thus interact with one of the above products through services.  This keeps the work on our side of the court, instead of a python script on the server.

That said, your explanation has been very helpful, as it helps me learn another option that's available.  After a quick discussion with the GIS analyst that I'm working with, and based on your comments, it seems that there's no way to return edges without the python script.  Thanks again!

[MaxZeng]

Hey @AndyWhitaker1 , if the GIS analyst you are working with, is publishing routing services using publish routing services utility, then you could probably use the geoprocessing service published through this utility instead? The route geoprocessing service published has a parameter called populate_route_edges, which should give you the traversed edges. At this point, the NAServer service doesn't have such parameter to return traversal result.

I would also be interested to know what you want to do with the traversal result, and see if there are other ways to get the information you need without returning traversal result. Thanks!

[AndyWhitaker1]

Hey @MaxZeng, thanks for the info. on the publish routing services utility.  I will have a chat with the GIS analyst to see if that's something they're willing to try.  I'm guessing there's a performance penalty, but it's something we can test.

What we're doing?  We're analyzing each route to find all of the bridges, signs, railroad crossings, and other features.  Currently, we take the geometry returned from the routing service and query for the underlying route segments in addition to features from a few  different feature layers.  Returning the underlying features on the route would provide us with some of the information that we must query for.  Since we have to perform a spatial "contains" query with a tolerance on these other layers, it would also eliminate the very small adjacent road segments that fall within the tolerance; this mostly occurs when roads intersect at a tight angle.

Presently, we're working on providing the user with a route that returns to the start location utilizing the exact same roads as the first trip leg - since these roads have been analyzed and deemed safe.  Having only the features traversed on the first trip leg would make this challenge much simpler. 

Current challenge is getting a list of the features traversed in order.  The spatial query to our network source layer (linework) to get the features traversed often returns the features out of order (especially on long routes).  To travel the exact same route for the return trip leg, we add a certain number of waypoints as stops to the route's return leg path (which only differs for divided highway segments).  However, at the moment, when the features are out of order, sometimes the waypoints we add are also added out of order, causing the route to visit waypoints in a way that adds a lot of extra distance.  Any suggestions are welcome.

[MaxZeng · Accepted solution]

@AndyWhitaker1Thank you for sharing how you are using the traversal result. After looking at your use case, the traversal result is indeed what you need to know those features that get traversed. Unfortunately NAServer service doesn't have the capability to return traversal result right now, so the only easy way to do it is using the geoprocessing service published via publish routing services utility (PRS). You could also create custom script that uses solver object as Melinda suggested and publish as geoprocessing service, but the geoprocessing service published via PRS are also written using solver object. The custom geoprocessing service created with solver object could be used to further extend what is not available in geoprocessing service published via PRS.

There are ways to make geoprocessing service faster though. Here is how:

Once you run the publish routing services utility, you will have a folder with these four services.

The NetworkAnalysis geoprocessing service (the first service in the screenshot), is published as asynchronous geoprocessing service by publish routing services utility. And it corresponds to GPServer asynchronous service. You could potentially go into the service parameters (by clicking the pencil next to the service) and change it to synchronous geoprocessing service. By doing this, instead of using submitJob on the geoprocessing service and query the job id for the job status, you will use execute on the geoprocessing service and wait for the job to finish. Here are some more information about executing sync geoprocessing service. 

Make the service synchronous will make the service run faster.

[AndyWhitaker1]

Thanks, @MaxZeng and @MelindaMorang for your assistance!  They are both viable solutions for returning the features traversed on a route.  I'll work with our GIS team to implement one of the solutions.