@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.
Ok, thank you.
Are there any method to get the traversed features in the "web scenario"?
I did did it by an ArcObjects soe, using the NALayer (.lyr file), but it's not compliant to the new Enterprise SDK.
Thank you again
Yes, depending on the service, you should be able to retrieve the traversed features by doing your workflow in python using the arcpy.nax solver objects. Here is some documentation: https://pro.arcgis.com/en/pro-app/latest/arcpy/network-analyst/performing-network-analysis.htm
The Route solver object has RouteEdges, RouteJunctions, and RouteTurns output types, so you should just be able to retrieve those.
Route solver object: https://pro.arcgis.com/en/pro-app/latest/arcpy/network-analyst/route.htm
Route solver result object: https://pro.arcgis.com/en/pro-app/latest/arcpy/network-analyst/routeresult.htm
Route output data types: https://pro.arcgis.com/en/pro-app/latest/arcpy/network-analyst/route-output-data-types.htm
I agree that ideally, this would be a REST parameter that could be set.
After reading through some of the docs, it seems that turning on some parameters on the network analyst service, such as returnRouteEdges might do the trick? My knowledge of this side of things is limited, as I'm a developer working on a GIS project, and not a GIS professional.
I saw a property for the Network Analyst, routeShapeType, which sounds like setting to TrueShape might return the underlying features?
@AndyWhitaker1 and @FabianoFerrazza3 are the two of you working on the same project? I'm not sure whether I'm having two separate conversations at once or if it's all the same thing. :beaming_face_with_smiling_eyes:
Regarding the python solver objects, you need to set returnRouteEdges to True and then retrieve the RouteEdges output type from the result. The routeShapeType property is unrelated. That controls the shape of the features in the Routes output. Regardless of your choice there, the "traversal result", which is the network edges that were traversed, will always be the same and can be retrieved through RouteEdges.