PTV Group - Logistics Forum

Hi there,

every once in a while a client wonders about missing toll when they compute routes. In most cases the cause for this experience is the missing time consideration mode:

For toll segments where the price depends on the time of the segment usage we do only return a price if the time is known. This requires a proper time dependency mode such as

• ExactAtStart / ExactAtArrival
• Snapshot
• TollOnly

These modes require a reference time which is then be used to determine the time context of a segment.

The following TimeConsiderationModes do not support a proper time context and therefore may ommit relevant toll contributions:

• None (simply means timeconsideration is set to NULL)
• Optimistic

The following output shows the impact of the TimeConsiderationMode on the toll prices:

Some players ask which mode they should apply in their usage scenario. Well, sounds like a question of taste. Here are some ideas:

• generic TENDER: if you want to determine a rough price of a route where you don't know the exact time context just go for a TollOnlyTimeConsideration and set the reference time to 12:00 on the next monday.
• Latest departure: if you want to know when you would have to leave from a waypoint to be in time on the next waypoint use ExactTimeConsiderationAtArrival together with the desired arrival at the next stop to determine the latest point in time when you'd be able to arrive in time.
• ETA calculation: if you know the current position of a vehicle and you want to determine the potential time of arrival just use ExactTimeConsiderationAtStart together with the current timestamp of the vehicles last GPS position
• Reconstruction: Probably the most challenging one. Reconstruction means that coordinates have been recorded during a trip and are matched to the road network afterwards in a popst processing step. This requires a map matching engine (xMapMatch2) and the output of that engine is then forwarded into xRoute 2 which does not have to recalculate the geometry but "simply" applies the toll on the given xMapMatch paths. Unfortuntely the MapMatcher 2 does not support timestamps. So it is up to the user to decide what time consideration and reference times he wants to use within the post processing xRoute call. If you are dealing with this I can only recommend to get in touch with a technical consultant at PTV to check this.

I hope this table gives you the necessary input - if not: get back to us to discuss your scenario!

Bernd

Some follow-up question of a partner:

Do we can use "TollOnlyTimeConsideration" with reference time parameter for dates in the future (like next year) for toll price calculations?
Example for this could be toll price changes for countries from certain date and we want to calculate price projections for future routes.
And could you explain shortly the differences for toll prices between parameters presented below:

Code: Select all

"timeConsideration": {
"$type": "ExactTimeConsiderationAtStart" , "referenceTime": "2024-02-01T06:00:00Z"}

Code: Select all

"timeConsideration": {
"$type": "TollOnlyTimeConsideration" , "referenceTime": “2024-02-01T06:00:00Z"}

Well, I recommend to look into this short video of Unidirectional Dijkstra Routing which shows the creation of temporary data structures. With this approach the "reference time context" of an evaluated segment depends on the "distance from the source". I did not label this "from the start" because the algorithm can be applied in forward direction (ExactAtStart) and in backward direction (ExactAtArrival).
This is a most realistic approach.

With the TollOnly approach the segment evaluation works as shown in this "bidirectional" video. This approach is faster but the time context of the segments is equal for each segment: the given reference time.

• Both approaches enable the user to consider future tariffs.
• In countries where the toll prices do not depend on time the quality of the TollOnly approach is probably sufficient.
• In countries where time dependent toll tariffs apply the usage of a more precise approach such as ExactAt... may return better results.

Bernd