PTV Group - Logistics Forum

Hi there,

recently I've been challenged by several parties about how to react on the gap

• between an expected route (often compared with GOOGLE's output)
• and computed route.

The following bullt list gives some idea how to deal with this gap... It is not covering the details of the story but just gives a meta strategy - escalating from easy to complex.
The later bullets apply if the previous ones didn't solve the problem;-)

Feedback is always welcome!

Input condition: the route you get from the API is different from the route you expect...

• First of all: ensure to use the latest version of map and engine!
• Believe it or not: Quite often the expectation is the problem. Please review whether the route you received is really wrong or just an alternative you haven't considered so far.
• Maybe there's just a simple parameter such as a RoutingOption or a RoutingProfile you didn't apply but which would have returned the proper result. Are you aware of such simple options that prevent a route from taking toll roads? From returning the shortest versus the fastest route? From using ferries? There's more than 100 parameters and we will be more than happy to find the proper one together with you.
• Sometimes there's the need to refer to optional data such as FeatureLayers which is disabled by default. You probably know that PTV deals with TruckAttributes, TrafficIncidents, historical trafffic data. But did you activate this content within your API call?
• OK, you definetly activated the content but you are still not happy with the route? Did we consider a segment that you don't want to appear in the output? In other words: "the applied data condition of the standard map and optional data does not reflect your reality"? This happens due to various reasons: the data we got from the providers is incomplete or wrong. Now it is time to look into the parameter for specific GeographicRestrictions: if you want to forbid a set of segments you could look into prohibitedSegmentsByIntersectingPolylines (available both onPremise and in the cloud). But be aware that this only enables you to block roads - you can't open them with this approach. Furthermore it put's responsibility on your shoulders? What kind of vehicles aren't allowed to use these segments? Just the big trucks? Just the hazmat trucks???
• Now if you want to delegeate the responsibility for the proper opening/blocking of segments to the service based on your data reality you could evaluate the so-called Custom Feature Layer (April 2023: OnPremise only feature). With this approach you can create/override the standard data, e.g. if you have a special permission to use segments that would have been blocked by the standard.

PS: so I mentioned "simple parameters" - does this mean, that there are also complex parameters?
In fact I'd distinguish between those parameters that are easy to be understood (the ones mentioned above) and those where a user would have to know details about underlying data structures and algorithms. Though you have access to such parameters it is not recommended to touch them without prior contact to PTV. We know what happens under the roof and we have tools to tune such parameters. This level is like changing settings on your car's engine - only meaningful if you know in detail how an engine works. Applying such parameters on your own could lead to bad side effects such as strange routes, poor performance or both.

Coming back to the gap between GOOGLE and PTV Routing: in most cases the following parameters are causing the gap:

• Preferences between shortest and fastes geometries
• Google does not consider legal contraints such as truck attributes, restriction zones and preferred routes (focus of PTV is professional truck routing)
• Vehicle speeds : GOOGLE uses more optimistic speed values

Best regdards,
Bernd