Infer default legal speed limits from OpenStreetMap tags

[Outlet2048]

The developer of StreetComplete has created a new project that documents all the default legal speeds for many many countries which can be used to improve routing time estimates where no maxspeed tags are set

Github page: https://github.com/westnordost/osm-legal-default-speeds
Project demo page: https://westnordost.github.io/osm-legal-default-speeds/

"It can be used by data consumers such as router software to fill the gaps in OpenStreetMap data, i.e. when explicit maxspeed tagging is missing because there is no explicit sign or because it hasn't been tagged yet.

Additionally, it can be used to supplement the legal speed limits for other vehicle types (buses, goods vehicles, motorcycles, ...), as these can be assumed to never be tagged unless explicitly signed."

[Outlet2048]

Related discussion with much more information and rationale here: navit-gps/navit#1196

[biodranik]

Wow, thanks for the links! @vng it would be great to reuse these speedlimits instead of the current heuristics: https://westnordost.github.io/osm-legal-default-speeds/legal_default_speeds.json

[westnordost]

There is some logic necessary to interpret the information in that JSON. It's not that much (~1000 LOC without unit tests), about 70% of that is parsing the filter syntax to match "road type" to actual OpenStreetMap tags.

But in order that not every user of this data needs to write their own code for that, I created a reference implementation in Kotlin Multiplatform in the above mentioned github project. This compiles to native, JVM and JavaScript. So, you should be able to use that library directly without having to port it to C/C++. It has no dependencies.

To effectively use this library, you will need to have a country geocoder (position -> country code it is contained in). If you do not have something like that, https://github.com/westnordost/countryboundaries is a Java library that does that but if there is interest, I may convert it to a Kotlin multiplatform library so it can also be used in native code.

Also, for good results, you will want to have some heuristic to decide whether a road is within or outside of an urban area. If you do not have this yet, both GraphHopper and Valhalla use a similar approach by looking at the density of streets, see graphhopper/graphhopper#2637 . CycleStreets uses another heuristic based on proximity to landuse=* polygons.

[westnordost]

Ah, also, the talk from the State of the Map 2022 about that is now online, too: https://media.ccc.de/v/sotm2022-18524-inferring-default-speed-limits

[biodranik]

We need a C++ parser, or some other parser to convert that info into the simple and already mapped table. This info can be embedded into map regions at the generation stage, so there will be zero runtime overhead.

[westnordost]

Right, so you want to fill in this maxspeed info during the phase in which the data is generated from OSM data.

As I wrote, the reference implementation is written in Kotlin multiplatform, which compiles to native too. So, likely you won't need to port that functionality to C++ but can use that library directly.