xRoute performance differences with Feature Layers

[CAPcargo]

Hi,

We are currently working on some processes which are developed to use the calculateRoute request against xServer2, and we’ve noticed a significant difference in execution time depending on whether feature layers are enabled.
For a route with +/-19 tour stops, the overall processing time is around 45 seconds, out of which the xServer execution time alone is about 34 seconds. The rest is client-side processing.
However, when we disable the feature layers, the xServer execution time decreases drastically.
In our current setup, we are using the following feature layers:

• PTV_TruckAttributes (this one is important for us since we want to include the vehicle parameters and run the calculation based on those values)
• PTV_PreferredRoutes (this one can be disabled and it is not important for all requests)
• PTV_TrafficIncidents (this one is also important for us, since we want to provide information about traffic jams and incidents relevant to the selected tour date)

I also executed the same request using your PTV Run Request Runner tool and observed the same significant difference in execution time with and without feature layers, which confirms that the delay is coming from the xServer side.

I would like to ask:

1. Is it expected that the calculation time increases so significantly when feature layers are enabled?
2. Is it possible to separate the data in PTV_TrafficIncidents - for example, to retrieve only the data for the current period, or to use different parameters for traffic jams and historical data?
3. Are there any recommendations or performance optimization tips you can provide for this kind of request?

I'm providing you the full SOAP request (it includes vehicle profile, geometry options, waypoints, and route options).

Thank you in advance for your feedback!

Best regards,
Irena

[Maximilian Vogel]

Hi,

using feature layers means that more (map) data is being processed, so a certain increase in execution time should be expected. But it's not only the data processing increase, but also how the algorithms work with this data. A few hints:

• If you disable PTV_PreferredRoutes the runtime decreases to roughly 15 seconds (on my test system). I strongly suggest to disable this feature layer for all requests where you don't need this data. Basically, to prefer certain roads (that otherwise might not be selected) the algorithm has to do more work.
• The algorithm works differently when the time consideration modes ExactTimeConsiderationAtStart and ExactTimeConsiderationAtArrival are used with time-dependent data such as PTV_TruckAttributes or PTV_TrafficIncidents. Thus, certain caching mechanisms and other performance optimizations cannot not be done anymore.

1. Is it expected that the calculation time increases so significantly when feature layers are enabled?

Yes, especially with the usage of PTV_PreferredRoutes.

2. Is it possible to separate the data in PTV_TrafficIncidents - for example, to retrieve only the data for the current period, or to use different parameters for traffic jams and historical data?

Not that I'm aware of. I might be completely off, but I don't think it would help alot to filter data within PTV_TrafficIncidents. Compared to other data, it's not that much. PTV_TrafficIncidents contain live incidents like construction sites, traffic jams, sometimes weather warnings, but not historical data. Use PTV_(Truck)SpeedPatterns if you're interested in such data. This will, again, increase the execution time a lot, so I'd rather recommend to use the parameter "simplifiedRouteCalculation" when using PTV_(Truck)SpeedPatterns.

3. Are there any recommendations or performance optimization tips you can provide for this kind of request?

In some cases it may help to use the restriction mode AUTOMATIC within the searchSpaceBounds, see here. Beyond that and the already mentioned things, there's not too much you can optimize. It would be possible to make some heuristics more aggressive at the expense of the quality, so I wouldn't recommend that.
Another option could be to use high-performance routing but that probably doesn't fit your use case if you (always) want to use ExactTimeConsiderationAtStart.