Detect / avoid gravel roads

[Bernd Welter]

Recently a player approached me with the following challenge:

We have a use case where we need to prevent trucks from driving on gravel/unpaved roads as far as possible. There are sometimes gravel/unpaved routes that is technically the shortest route but not the best road to travel since trucks can get stuck on these roads.
Some of the locations the vehicles need to visit would require gravel/unpaved roads to be used though, but as far as possible we should be able to avoid these roads to prevent trucks from breaking down or getting stuck in mud.
We were not able to clearly see if there is a setting we can use to avoid gravel routes as far as possible in the routing API.

Let me first look into the underlying theory:

• Routing uses segment attributes such as
  • eight defined network classes (NC_0 = motorway... NC_1=highway .. NC_6=, NC_7=bicycle and walkways
  • truck attributes
  • speed_classes (SC_0 .. SC_7)
• these attributes are cross checked with parameters such as
  • malusByNetworkClass
  • LevellingScope
  which serve to avoid/prefer certain segment categories.
• sidenote: there's no specific "road is gravel road" attribute...

Let me show up some sample routing output:

In this route (1396,6 km) I show the network classes used: from left (start) we use the lower classes which is typical in an urban environment. After a certain distance we reach the higher network classes and transfer the vehiclke to the destination area on NC_0/NC_1. In the destination area we use minor roads till we finally reach the waypoint. The routing options in this example were set to standard which means "away from waypoints only use higher network classes" (Leveling is enabled)

The second example (1387,6 km) is "artificial" - I enforced a short route via distanceTimeWeight=0 (not a practical value). Furthermore I disabled leveling (all leveling scopes are set to UNBOUNDED) and I also set the malus values (disliking) to a neutral 0.

I used xRoute2 tools for this theoretical article because the current implementation in PTV Developer Routing API does NOT

• give access to the underlying technical output (segment lists including the network class attributes)
• give access to direct API parameters overriding the routing preferences when it comes to network classes

If you are facing such issues we might assist with technical insights.

From my perspective it could be worth discussing about custom profiles.

Bernd