Specialized maxheight editor

The data for truck routing is still challenging :)

Even the basic tags like maxwidth, maxheight and maxweight are missing in a lot of places to make truck routing unusable there, especially when using smaller roads.

One problem is that the missing tags are often not obvious or visible on openstreetmap.org. There are some efforts to improve them like the tool from Geofabrik or this tool (which sometimes stops working because the overpass API is overloaded).

Also another problem is that the number of them could be too overwhelming to even start with.

And so I took the opportunity with my own special set of ideas and created this tool:

https://osmtool.graphhopper.org/maps/osm-issues/#12/49.44834/11.09600

(source code)

which helps making missing maxheight, maxweight and bridge tags obvious.

Currently only using european PBF from geofabrik and my intend is to update it weekly. Ie. no real time data. This is currently necessary because 1. overpass API is too often down when I needed it in the past and I don’t want to let me or the mapper wait and 2. I don’t know postgis and 3. we need a routing graph to do the elevation import and interpolation for the importance estimate (see below).

The tool is highly focussed and does not include maxwidth or hgv=no tags because we have to start somewhere. Also it was created and AI helped.

I never created a tool that does edits to the database, so I’m seeking for constructive feedback that helps to improve it and make it safer and according to the guidelines :)

How to use it?

You can use the red circles as indication to look in your area or even remote via mapillary etc to fix the missing tags. Pick the bigger circles first.

Another approach is to zoom in until the mapillary-found maxheight signs appear and everywhere where no green circle (already mapped maxheight) is near it is likely that you found a missing tag. The tricky part is that often times there are several signs several dozen meters away and “near” is tricky to define.

Then there are missing bridge tags. First disable everything else in the filter and enable “bridge tag missing”. These spots are rare, but because two ways cross each other the chance that something has to be mapped or fixed is nearly 100%.

The last opportunity are hundreds of possible missing maxweight tags but for them it is not yet clear to me how to filter or sort them as only a tiny subset is important.

What do the different colors mean?

Just different tags. Should be self explanatory.

What do the different sizes of the red circles mean?

The red circle marks a missing maxheight tag. But there are also bigger and smaller sizes, where bigger means a higher chance that there is a maxheight tag necessary.

Obviously a maxheight tag is necessary if there is a bridge crossing the street or if there is a tunnel. But bridges crossing motorway are often very uninteresting to map because they are high enough (maxheight=default) and so additionally to the highway tag I’m using some heuristics to estimate “high enough”.

For that procedure I use GraphHopper’s precise elevation data. And although the result cannot be used as a strict filter it works rather well for a sorting procedure. Also note I currently use “only” zoom level 12 elevation data and the estimates would be a bit better with zoom level 13, but the disk requirements would explode for this project, even if it is just for Europe.

I found a bug or have a problem

Please reply to this topic and let me know. Do not create an issue on github until the project’s future is clear.

What is the project’s future?

I would find it more interesting to have it directly integrated in one of the bigger editors and offering some data in the background. Or let this feature integrate in something more popular like the OSM Inspector instead of creating yet another special tool :)

10 Likes

Nice. Maybe some of those tasks could be added to StreetComplete?

1 Like

Yes, good idea. But I’m unsure about the process. Do I approach them or does the community decide this somehow?

Additionally to StreetComplete (which requires visiting the locations as far as I understand) I also have armchair mappers like me in mind :)

1 Like

They seem to have a quest for maxheigh already, but maybe it could be interesting to use our insights as a filter or something.

1 Like

Not really a bug, but maybe something to consider to reduce false-positives.

Therefore it’s not possible to have a maxheight here, yet.


There is actually some precedent in StreetComplete for using an external data source like this.

The former AddSuspectedOneway quest used Telenav/ImproveOSM data via a separate API. The external data acted as an additional candidate filter on top of the normal local OSM tag filtering. The quest was later removed because ImproveOSM was discontinued, not because this architecture was considered unsuitable.
(Task: Script that imports oneway-data dump and makes it available via a web API · Issue #1022 · streetcomplete/StreetComplete · GitHub + GitHub - streetcomplete/oneway-data-api: 🚗 A simple API for getting oneway data from improveosm.org ➡️ · GitHub)
(removed in Remove improveosm oneway suspects quest by westnordost · Pull Request #5725 · streetcomplete/StreetComplete · GitHub)

A GraphHopper integration could follow a similar pattern: keep the existing local AddMaxHeight logic, but use the missing_maxheight candidates and p_sign from GraphHopper as an additional filter/prioritization layer.

The main benefit would be reducing false positives. StreetComplete/SCEE currently only detects a road passing under a bridge geometrically; it has no elevation/DEM data and no way to estimate whether a height restriction sign is actually likely. GraphHopper can add both the estimated clearance and its fitted p_sign probability.

I would therefore see this less as replacing the existing maxheight quest and more as providing better candidates for the bridge/tunnel part of it. Other cases such as height_restrictor, parking entrances and electrified railway crossings could remain purely local.

The main trade-offs would be the dependency on an external service, weekly rather than immediate data updates, and sending the current bounding box to that service.

2 Likes

This is a tricky once because the bridge could already block the height and require a tag (no?)

The former AddSuspectedOneway quest used Telenav/ImproveOSM data via a separate API.

Interesting, thanks for letting me know. Something like this could indeed work in this case here.

1 Like

Nice work! :+1:

One that I immediately thought of was the roof over service / gas station forecourt e.g. Google Maps

Having more of them tagged would be a great help when towing a caravan!

1 Like

This should be detected via covered != no (currently same category as tunnels). Note that current coverage for the editor is just Europe and so it is not shown. Will try to expand it soonish.

Edit: this was indeed another case, which is now also added in the editor

1 Like

Very nice tool!
I found a case where it flags a proposed highway crossing over a residential road:
GraphHopper - missing OSM bridge tags.
Only with 31 % probability, but flagging a proposed feature is maybe a bit early, no?

Ups. Indeed highway=proposed should be excluded. Is now fixed!

1 Like

hi!

nice - but missing barrier=height_restrictor

regards Jan

1 Like

Since it was mentioned that StreetComplete could implement this, here’s what the app already asks maxheight for:

  1. vertices of roads that are either height restrictors or parking entrances to underground parking or multi-storey parking.

  2. Level crossings with railway lines that are electrified with an overhead contact line, except tram lines

  3. Tunnels, covered bridges or covered roads/paths

  4. Roads directly below roofs, overhead pipelines or railway/road bridges

All only asked for features that are non-private.

So in case you haven’t thought about these things yet, you can take them into account in your tool or directly peek at the source for AddMaxHeight.

3 Likes

Does that include where e.g. driveways are access=customers?

No, only no or private.