Accommodating custom road networks which are dependent on government provided Restricted Access Vehicles (RAV) classifications?

openrouteservice
1

Hi ORS Community,

Here in Australia, similar to many other countries, our roads have specific ratings which are dependent on the size of your vehicle, weight it can carry, different axle groupings, different trailer couplings, etc, etc.

As a reference, an example of just one of these grouping charts can be found here:
https://www.mainroads.wa.gov.au/globalassets/heavy-vehicles/getting-a-permit/tri-drive/tri-drive-prime-mover-trailer-combinations-vehicle-categories-and-descriptions.pdf

However, the government has been progressive enough to give open access to the Spreadsheet, KML or Shape files for each one of these restricted networks!

For reference, the overall map & an example data set (for one restricted network) follows:
https://mrwebapps.mainroads.wa.gov.au/hvsnetworkmap

Is it possible to have ORS calculate routes with respect to these individual restricted networks?

The “hackiest” method I can think up (that might actually work) would be literally to just have numerous different ORS instances running which are all pointing to manual subset .pbf files that represent each one of these restricted road networks, then increase the snapping/search radius and voila. However, this is obviously far, far, faaaaar from optimal - it would require hundreds of different instances of ORS to be running.

As a more logical starting point, leveraging ORS profiles seems to be the proper way to figure out a way to have this custom pathing functional. Would it be possible to create a profile for each “restriction classification” which when called will tell ORS to only calculate routes using a subset of the overall .pbf file; a subset which is somehow determined by the Shape files provided by the government?

It seems like this functionality is already somewhat present within ORS, as it’s possible to toggle on restrictions = “true” in the app.config file. However, I couldn’t find many details on what this functionality is actually doing on the backend (and I’m not skilled enough to trace back the code).

Hopefully this all makes sense, and hopefully I’m not re-posting an already asked question (had a search and couldn’t find anything too similar).

TL;DR - is it possible to essentially only calculate the route on some smaller subset of the overall road network (.pbf file), where this subset is is different dependent on which route profile you make the API call with? (And, each profile’s subset of the network is predetermined by some Shape file).

Any help or just information on how this functionality might work if it’s already possible (links to resources to build my understanding), or if it’s not possible functionality tips of what might be the best way to go about beginning to implement it, would be very, very, verrry appreciated.

Really grateful for the amazing community this product has gathered - and ORS is a truly awesome toolkit - everyone who’s contributed should be very proud in what they’ve built!

Hopefully this wasn’t too much incoherent babbling - haha :grimacing:

Cheers,
Troy

2

Hi @troy

that looks like pretty cool data. At the minute it is not possible to build graphs from multiple datasources (we were going to have a project for a very similar thing but unfortunately we did not get funding for it), but the most optimal way of using the data in openrouteservice would be to get the restrictions imported into OpenStreetMap directly as then openrouteservice can make use of them out of the box (we can take into account things like minimum height and maximum weights). That isn’t a particularly trivial thing though for larger datasets as there are a lot of rules that need to be followed for such an import (https://wiki.openstreetmap.org/wiki/Import), and you would want to update existing road features rather than just adding the features from the HGV datasets.

We are currently working on a project though that makes use of mapmatching algorithms to add extra data to the graphs, so that is something that could theoretically be used in the future to add the HGV data to the graph as well, but there is still some work to be done in that before it is released.

3

Thanks for that Adam, I’ll definitely have a read through the importing process into OSM now.

Simplest case would be (if it’s possible) to just add something like a “restriction_string_feature” to those road segments which need it. As you mentioned though, it’s probably much more easier said than done.

I’d definitely be interested in any improvements across this space. The matchmaking algorithms could definitely come in handy. Or, if it ever becomes priority for the project again; the multiple data sources could be handy too.

Appreciate all the hard work so far regardless :smiley:

Cheers,
Troy

4

Actually I’d say it’s more “correct” (at least semantically) to host several instances instead of (IMO the hacky way) letting profiles determine which network to use. That’s also how all other routing engines do it, e.g. Graphhopper for TomTom. Your solution would be very much the same in terms of RAM/processes to be used, although I’m not sure why this would apply:

it would require hundreds of different instances of ORS to be running.

If the network(s) they offer are compatible with each other (i.e. you can create a consistent topology across all (sub)network(s)), then the best way to go about this would be to create an “artificial” OSM file which collects all those networks in a single network. ORS (and all other FOSS routers) would then be able to read that out-of-the-box. You have the barrier here of defining the parsing logic to match whatever tags/attributes these datasets have to the OSM data model. We did smth very similar for TomTom and HERE data, though we offer it as a commercial service, hence it’s not open-source:

As Adam pointed out, it’s not trivial to make that conversion in terms of attributes, esp turn restrictions are a notorious pain.

Adding this data as an import to OSM would be ideal of course. Here I’d recommend to contact your local/regional OSM chapter to see about the feasibility. If those geometries are not in OSM yet, I’d imagine that these datasets would duplicate a lot of existing road segments which might make it close to impossible to import if they don’t have the same data source.

5

Ahhh I see. I guess the first think I started imaging was having 100 different Docker containers each running a small sub-network which screamed non-optimal to me - but I never considered they’d all sort of stay “dormant” until a profile sent a request.

I think all the (sub)networks should have consistent topology - they’re all (in my case) just different subsets of the overall Western Australian road network - so from a GIS perspective I’d imagine they should share all the same attributes. However, the issue would be (as you mentioned) the repetition of roads because one road may have many restricted access ratings, where as others may have just one (or even none). Another issue, further down the track of course, would be that if you queried for the route from point-A to point-B with a heavy restriction level then the closest road to source/destination would often be unrealistically far away. To more accurately deal with this issue you’d likely need to implement some logic to route from source → along non-restriction roads → closest restricted road point → along restricted portion → back onto tail end non-restriction roads → along there to destination.

I’m not sure if it helps the turning restrictions issue at all, but the State Government provides intersection and bridge restrictions along with all the road restrictions (for each access restriction classification level):

However, I’m guessing the issue is more so how to determine which way you can turn when your presented with an intersection? Had a quick skim through a lot of the datasources available and couldn’t find anything of the sort unfortunately:

Had a quick look and unfortunately doesn’t look like Australia has any representation in the OSM GIS space :frowning: It would be a wonderful addition to the OSM data to be able to enrich it all with the individual state government vehicle class restriction classifications. Is there any easy way to see what features (meta data) are currently available to come along with the OSM routes?

Doesn’t look like this is an easy/quick problem to solve - but appreciate you guys spending time to dumb things down to me anyway! Appreciate it :smiley:

Cheers,
Troy

6

Commonly that’s just how it is :wink: You can’t route anyone along ways they’re not allowed on. There is smth like access=destination which basically says you can start or end your trip on that road, but can’t take it thru. Usually for residential areas, but more complex access restrictions are possible too.

The easiest is https://www.openstreetmap.org/ with the query tool on the right sidebar. The most flexible/powerful is https://overpass-turbo.eu, but magnitudes more complicated to query. Or QuickOSM plugin for QGIS.

They are always represented as relations. Basically the turn restriction data is linking two ways (via several other ways or a single node), so no need for a geometry format.