Connect tower nodes of highways tagged as area=yes

[easbar]

This PR shall add support for some simple cases of routing through pedestrian areas.

In OSM there are currently around 390k ways tagged as area=yes that carry a highway tag. There are another around 19k relations tagged as area=yes that carry a highway tag.

The textbook example for such an area we'd like to route through would be something like Glücksburger Platz in Hamburg, Germany:

This is a closed-ring way tagged as area=yes;highway=pedestrian that shares some nodes with adjacent roads/footways. As long as we treat it as a normal way tagged as highway=pedestrian, ignoring the area=yes tag, the route will simply go along the edge of the area, like this:

... which is of course not ideal. Note that the dashed line crossing the area is an administration boundary not a footway in this example.

Because GraphHopper is not the only router that doesn't offer support for area=yes, mappers often add artificial ways, even though some consider mapping for routers bad practice. Take a look at Gerhart-Hauptmann-Platz in Hamburg:

Satellite	OSM

In this case GraphHopper uses these extra ways to route across the plaza of course:

But obviously for many pedestrian areas such ways are missing and as far as I know it is not even the consensus among mappers that they should be mapped, or some might be even against mapping them.

So the question here is what we, as a routing engine, can do to support routing through such areas.

The examples I showed above are very simple, because (a) the corresponding areas are convex, i.e. all points of the area boundary can be connected with a straight line without leaving the area (at least this is true for all points on the boundary that connect the area with adjacent roads), and (b) there are only a few such points that are clearly separated from each other. In this case we can simply connect the points to add extra edges to the routing graph and the area will become 'routeable'. This is done in this PR. In case of the first example (Glücksburger Platz) it looks like this:

The grey lines represent routing graph edges, while the red arrows point to the six artificial edges we added to connect the four points of the area that are connected to adjacent roads/footways.

This results in a much more realistic route that no longer goes along the edge of the area:

For the second example (Gerhart-Hauptmann-Platz) the situation is already more complicated:

Here we added edges to connect the entry nodes of the area again, but since OSM already contained some extra ways that mappers added to make the area routeable the routing network becomes rather messy. Due to the way we snap coordinates to the route network this can lead to strange routes like this:

To fix this we would have to create extra nodes at points where these edges intersect, recognize areas for which there are such extra ways already and either ignore them or do not add more edges, or change our snapping approach. Unfortunately none of these solutions would be easy or even feasible for us.

Another problem is that many areas aren't convex, like Harald-Stender Platz:

In such cases the present simple approach might add too few extra edges. I think it would be feasible to apply some more sophisticated logic and create edges that follow shortest paths without leaving the area, even when the area is not convex. However, the bigger issue seems to be that often too many edges would be added and lead to a similar problem as the one mentioned above.

Even the simple approach might add too many edges. Take for example this pedestrian area, which does not really represent a 'plaza', but rather some kind of pedestrian 'lane':

In this case the routing graph will look like this (with this PR):

and quite obviously this dense net of edges leads to strange routes when we snap inside the area (for the same reasons mentioned above):

The situation becomes even worse when there are not only many tower nodes along the area border, but when areas share a common border. In this case basically every node becomes a tower node (because it belongs to two or more ways).

For example here there are many little pedestrian areas with complicated shapes that share common ways:

When we apply the simple logic in this PR we get a super dense routing graph with very many crossing edges:

In summary there seem to be:

• areas that could easily be made routeable using the simple approach represented here
• areas where adding more edges is unnecessary and even can result in too many crossed edges because mappers already added extra ways to make the area routeable
• areas that are not convex where a more sophisticated approach would be needed to connect the different roads adjacent to the area
• areas where even with the simple/conservative approach here we would add too many edges

The good news is that with this PR the total edge count only increases by around 0.5% (tested for Germany). As it stands it can lead to strange routes like the ones shown above, though. Overall, I am not really convinced this is a real improvement yet.

To reduce the number of extra edges and avoid the strange routes I mentioned we would probably need a (much) more sophisticated approach that only adds a small number of 'useful' edges and/or another snapping algorithm?

[easbar]

I think an important observation is that in OSM area=yes&highway=pedestrian/footway can both mean we are dealing with some kind of 'pedestrian lane/area' or a 'plaza':

In the screenshot we see area=yes ways highlighted in blue. Some encircle blocks of houses, while others (the one in the top right) represent a 'plaza'. We probably only want to add edges for the latter kind.

[karussell]

Do you still have the links for those areas on GH Maps?

Overall, I am not really convinced this is a real improvement yet.

I still really like it :D ... seems to be one part of a solution for #82 :)

that only adds a small number of 'useful' edges

Instead of connecting all tower nodes would it be possible to differentiate between useful towernodes where OSM ways "enter" or "leave" those areas from the unuseful towernodes that only exist due to the border of the area?

quite obviously this dense net of edges leads to strange routes when we snap inside the area (for the same reasons mentioned above)

Would this really happen that often in real world?

For example here there are many little pedestrian areas with complicated shapes that share common ways:

Maybe this is not really properly mapped and instead a single enclosing area should be used?

We probably only want to add edges for the latter kind

👍

[easbar]

Do you still have the links for those areas on GH Maps?

The screenshots should be clickable/provide links to the areas.

Would this really happen that often in real world?

I think it happens whenever we start or end a route within such an area (or both). We simply snap to the next edge and this might lead us into the wrong direction (make a detour that seems not plausible).

Maybe this is not really properly mapped and instead a single enclosing area should be used?

It looks like they used separate areas to map different surfaces or something?

[otbutz]

Could we try to compute some kind of minimum network of support points for an area? At least for convex area polygons, routing through the centre of mass seems like a good place to start.

[otbutz]

https://stackoverflow.com/questions/62645727/how-can-i-get-center-line-of-a-complex-shaped-polygon#comment110828520_62651638

[otbutz]

https://en.wikipedia.org/wiki/Straight_skeleton