Changing vehicle parameters at waypoints

When calculating a route with more than 2 waypoints, it often happens that logistic events occur at intermediate stops, which can modify some routing-relevant characteristics of the selected vehicle.

The most common use-case is obviously unloading or loading some goods at a stop, which implies a change of the weight of the vehicle. The nature of the transported goods can also be important, for instance when it relates to hazardous materials : some roads should then be either preferred or avoided. Last but not least, adding or removing a trailer will definitely modify the dimensions of the vehicle itself.

Such vehicle adaptions can sometimes have a sensitive impact on the path of the optimal route, or even on toll costs. And more commonly, they also directly affect the quantity of emitted pollutants and the energy consumption for a given route.

While it is of course possible to split a route request in several requests with different input vehicle configurations, it is much more performant and user-friendly to be able to consider these changes in a single request.     

This is why the version V1.14.0 of the PTV Developer Routing API now offers you to (re-)define some of the vehicle parameters directly in your on-road or off-road waypoints, with the POST method : calculateRoutePost.

Our new code sample provides you a fast-and-easy way to evaluate the influence of the change of load weight at waypoints. As shown on the screenshot below, it is preconfigured to test a route where unloading the goods at the second waypoint influences the course of the route. 

Please have a look on our technical concept to get more information about waypoints handling.

To keep yourself updated about upcoming releases and news you can use the subscribe function on the right hand side. If you got any question do not hesitate to get in contact.

Emission calculation with alternative drive-trains

The reduction of pollution and the sustainable increase in efficiency of transport chains to improve air quality are important factors in the logistics today. ISO standards therefore have been introduced to standardize the calculation of emissions that are released. Now, with the lately effective ISO/DIS 14083:2022 standard, new factors have been provided also considering alternative drive-trains.

With the new version of PTV Developer Routing API 1.14.0 the emission calculation has therefore been extended by this new standard. It enables now in addition to new factors the calculation of electricity consumption under consideration of new vehicle parameters for alternative drive-trains and can furthermore be combined with the latest factors of HBEFA 4.2.

This example shows the calculated emission consumption of a hybrid truck by using the factors of the ISO/DIS 14083:2022 standard and HBEFA 4.2

If you are interested in more detailed information, please refer to our technical concept – or even better, just try it out in our updated code sample or tutorial.

To keep yourself updated about upcoming releases and news you can use the subscribe function on the right hand side. If you got any question do not hesitate to get in contact.

Fastest, shortest … and now cheapest routes

Usually the ‘FAST’ routing mode tends to reduce the driver cost of your calculated transport routes due to shorter driving times, while ‘SHORT’ routing mode rather optimizes fuel consumption costs due to a shorter travel distance.

Multiple factors should indeed be considered in order to spare money : toll costs, energy costs, vehicle cost per kilometer, or even working-time cost per hour. Therefore, a new ‘MONETARY’ routing mode has been added in version V1.13.0 of the PTV Developer Routing API, to directly evaluate these factors within the objective function, in order to calculate the cheapest route according to our monetary cost model. Since V1.14.0 it is also possible to define costs per kWh for electric or hybrid vehicles.

In addition, you can now request detailed monetary cost reports even for routes calculated using the ‘FAST’ or the ‘SHORT’ mode, and then easily compare the resulting price for each mode in the desired currency.

The above example illustrates the result difference between the ‘FAST’ (in orange) and the ‘MONETARY’ (in blue) routing modes for a given start and destination.  

Please refer to our technical concept to get more information about when and how to use Monetary Costs routing, as well as the current limitations of this new mode. You can also try our new code sample to test it.  

To keep yourself updated about upcoming releases and news you can use the subscribe function on the right hand side. If you got any question do not hesitate to get in contact.

Sometimes length matters ;-)

Usually a route is optimized for travel time. The result is a fast route a real driver would follow accepting a longer distance, if necessary. But there are use cases where you want to optimize a route for distance, for example in case of billing purposes based on distance.

In the new version of the PTV Developer Routing API V1.13.0 you have the possibility to use the new parameter ‘routingMode’ by selecting ‘FAST’ (optimize for travel time) or ‘SHORT’ (optimize for distance).

In the above example there is the orange route with longer distance but lower travel time using mainly the motorway (‘FAST’) compared to the blue route with shorter distance but higher travel time crossing the black forest (‘SHORT’).

Please note that both modes do not calculate the absolutely fastest or shortest route. The results are still meaningful and avoid rural roads and residential areas. If you want to know more, just have a look on the corresponding technical concept or test it with our brand new code sample.

To keep yourself updated about upcoming releases and news you can use the subscribe function on the right hand side. If you got any question do not hesitate to get in contact.

Route violated! But where?

When there is no valid route for your vehicle between two waypoints possible at all, the route is nevertheless calculated and marked as violated. This is typically the case for prohibited areas around waypoints, which have to be entered or exited anyway. Other “obstacles” like weight restrictions on the way are usually bypassed and not part of the calculated route.

Up to now, you can request violation events in such routes containing the position, time and the vehicle property in question. In the new version of the PTV Developer Routing API V1.12.0 we also provide the polylines of the violated route parts by using the new parameter ‘VIOLATION_EVENTS_POLYLINE’.

With this polyline it is easy to display the violated route parts on a map. Illustrated above, the first part of the route is marked in red as this is prohibited for the current vehicle because of the surrounding forest. Of course, there is a new code sample for this feature and you are welcome to play around with it! 

To keep yourself updated about upcoming releases and news you can use the subscribe function on the right hand side. If you got any question do not hesitate to get in contact.

How to recalulate a driven route and calculate the toll costs?

Do you have a use case, where you need to calculate the toll costs or emmissions for a driven route?

You can calculate toll or emissions for a driven route if you combine the PTV Developer Map Matching API and PTV Developer Routing API

We now offer you a new Technical concept which describes in detail how to establish that! You also can check out our tutorial regardig toll routing.

To keep yourself updated about upcoming releases and news you can use the subscribe function on the right hand side. If you got any question do not hesitate to get in contact.