Und noch eine alte Ape als Teileträger.

Continuing the OpenstreetMap antipattern blogpost series here is another one.

This is a single landuse, spanning 12km. It follows streets in a tree like shape.

As for the obvious, this kind of landuses are prone to break. People tag highway tags on them, move them around by accident, and as they ALWAYS span more than your edit area nobody really is brave enough to do something with them. So this way/landuse stayed in the Database for 12 years, despite beeing semantically nonsense.

In this case we have a landuse=grass which is in itself a broken tagging as its not a use in itself. The Wiki article about landuse=grass tells you that most likely your tagging is wrong and you should use something else.

In this case the mappers intention was to not let any gap show up on the map between roads and landuses. We know about mappers glueing landuses to roads which is a semantic error in the OSM dataset as linestring object do not have a dimension as areas do have. This is another hack to eliminate the gaps between roads and adjacent landuses.

Nevertheless this is broken. The road itself is never a landuse=grass, its not even a landcover=grass, its tarmac or asphalt. Adjacent to the road there are the shoulders, which may carry grass from time to time, or a ditch which has grass on its banks.

Concerning the tracks, these carry a surface tag themselves so this landuse just trys to map for the renderer to get gaps in the background of the map closed.

So the antipattern is to not hack OSM data to do background filling. Not with glueing landuses to linestring objects, not by filling these with huge landuses as a last resort.

As long as we dont have a language/tags to fully describe road areas (which the shoulder and the ditch belong to) we should not hack around and fake objects to close gaps.

In my RouteQA initiative i mostly care about temporal changed routes, e.g. routes which change because mappers make changes to the map data. I try to catch mistakes early e.g. reversed oneways, broken turn restrictions, access restriction and the like.

When i add "clusters" e.g. areas i check routes within, i also try to fix the most obvious routing mistakes e.g. shortcuts or rat-race roads. Almost all cases are caused by sparse tagging. Mappers focus on the higher class roads which carry extensive tagging about maxspeed, lanes, lane_markings, surface and the like. All the small side or rough roads lack these information and suddenly the side roads are mathematically better. This is probably true for a single vehicle, but considering we direct most of traffic to these smaller roads these roads will never cope with the traffic we send.

The first thing is that i fix the sparse tagging by iterating on the side roads and fill the gaps. In 98% of the cases this will fix shortcuts or rat-race issues. But there are hard to fix cases i up to now had no clue how to fix.

I started a thread on osrm-talk and the routing mailinglists which basically returned "unfixable", "you need to fix the engine", "the side road is better so what", "this is easy" or "unfixable without mobility or live data".

I don't buy the "mobility or live" data as thats not for hobbyists, or non profits. You need money to buy and its a huge undertaking to process that huge stream of data.

The other options are assuming "something magic happens".

So i sat down and made a "Proof of concept" inventing a tag for customizing the route weight and using that in an OSRM profile.

The tag i used is route_weight_factor:motor_vehicle which shall contain a float from -0.8 to +0.8.

This then will be multiplied with the calculated weights from the physical tags like lanes, lane_markings, maxspeed, road class etc.

So a -0.8 means we go down to 20% of the speed of the road.

Here is the git commit for the car profile change:

https://github.com/Project-OSRM/osrm-backend/commit/c199019fefc8b0d31e45a6599c0a7f1343af2cfe

This enables to fix issues like this:

The small side-road is barely wide enough to fit a car. Sending 2 way traffic through there is definitely not an option. There is no legal restriction so we cant really exclude it. So we need want to make it worse than the way around.

It shows on how mappers would be able to influence and fix routing in case something like this would get an established tagging.

Also it would allow us to respond to public bodys e.g. city councils asking for routing changes in OpenStreetMap.

Erst ganz ruhig und minimalistisch mit Rhea und Dad ... Ein Rotwein zur Feier des Tages.

Dann Turmblasen und Weberei, wobei letzteres eher mit Jungvolk voll war.

I am currently extending my RouteQA slowly around Northrhine-Westfalia in Germany. I now extend to areas where mappers extensively mapped lanes=1 instead of lane_markings=no which breaks routing in a lot of subtle little ways at least for OSRM.

lanes=1 means it is not possible for two way traffic to pass each other without going to the curbs or shoulder. This causes the default OSRM car profile to assume half the average speed of the maxspeed.

So a road with maxspeed=50 and lanes=1 without any oneway tagging is assumed to have a max average speed of no more than 25km/h. Thats a pretty good assumption if its really too narrow.

Now if you have a tertiary or better road in city limits with a maxspeed of 50, and a parallel road with 30km/h the smaller side roads suddenly is faster because 30km/h is better than 25km/h.

So please stop tagging lanes=1 for roads which are wide enough for passing traffic without getting into each others way. The correct tag is lane_markings=no

In the default OSRM profile lane_markings=no has no penalty at all which IMO also needs fixing which why i opened an issue for the OSRM backend

Nevertheless - be careful with lanes=1 - its a hefty penalty for routing.

This is an example of broken routing in Borken near the Dutch border from my QGis view on the RouteQA.

As one can see the Butenwall is used but also the parallel Wallstraße. The Wallstraße would be used in ALL cases if it would not be a oneway.

The Butenwall as a secondary should be MUCH better - but it (was) tagged with lanes=1 as there are no lane markings. As a secondary it is wide even for trucks to pass each other without issues.

When putting in barriers like this barrier=bollard you might want to go back and check the routing.

In this case at least we as OpenStreetmap using OSRM send through traffic through this farmyard.