Pedestrian street with vehicles allowed not routable by car profile

[Michael Krog]

Describe the bug
A small island in Denmark is only accessible by car via a very short pedestrian street that allows vehicles. All routes to most of the island is blocked because graphhopper does not allow vehicle routes through this pedestrian street,

Examples:
Graphhopper (fails to route)
Google maps
OSRM

To Reproduce

Steps to reproduce the behavior. For examples:

1. Go to https://graphhopper.com/maps/?point=55.175706%2C11.648719&point=55.175757%2C11.649549&profile=car&layer=Omniscale
2. Confirm that it cannot create a full route between locations.
3. Go to https://www.openstreetmap.org/way/977919745.
4. Confirm that vehicles are allowed

Expected behavior
I expect vehicles are allowed when it is marked as such in OSRM data.

System Information

Public graphhopper

Screenshots & Logs

[Andi]

Shouldn't this rather be tagged as living_street?

[otbutz]

The translation of Gågade zone is literally pedestrian zone: https://www.deepl.com/translator#da/en/g%C3%A5gade%20zone

It's even listed in the OSM tagging examples(last one): https://wiki.openstreetmap.org/wiki/Tag:highway=pedestrian?uselang=en

[otbutz]

Seems to be pretty common: https://overpass-turbo.eu/s/1BFa

[Andi]

Maybe exclude area=yes, but it's true there seem to be quite a few pedestrian highways using vehicle=yes (https://overpass-turbo.eu/s/1BFq)

[otbutz]

And a bit more if we also take different values like destination into account: https://overpass-turbo.eu/s/1BFr

[otbutz]

This has also implications for bike routing. If cyclists are explicitly allowed to enter, we shouldn't treat it as a pushing section.

[Michael Krog]

I wouldn't mind giving this a shot as my first contribution.

Any pointers for me where to start?

Leaving a links here with info about the specific tags:

• vehicle:destination
• vehicle:yes
• area:yes

[Andi]

It would be nice to see a few more real-world examples where accepting the pedestrian roads is necessary. I know the overpass query returns lots of ways with this tag combination, but looking for some actual examples where this is an issue would make it clear that we really need to change this and we do not break more cases than we fix.

Once this is clear it should be a matter of leaving out pedestrian from import.osm.ignored_highways (it is currently included in config-example.yml and also in the hosted car profile) (this will impact the performance of the OSM import as well as the resulting graph size) and adding pedestrian to highwayValues in CarAccessParser.java (and possibly a few other access parsers).

[Michael Krog]

Ok.

I can dig up some more examples from Denmark. It is a pretty common thing here to have pedestrian areas that allows vehicles - also for drive throughs.

Normally it isn't an issue I guess, because driving around is often more optimal because of the low max speed.

But for deliveries in the pedestrian zone and drive throughs to reach an "island", it is difficult to do without.

[Andi]

It is a pretty common thing here to have pedestrian areas that allows vehicles - also for drive throughs.

Are they allowed to drive through for anyone or only for delivery vehicles and such?

and drive throughs to reach an "island", it is difficult to do without.

Yes, of course excluding an entire island because of such a pedestrian road is bad.

[otbutz]

It would be nice to see a few more real-world examples where accepting the pedestrian roads is necessary.

Here's an example from the OSM wiki:

"Gågade" Pedestrian street with "Kørsel tilladt" vehicles allowed. Driving is allowed here, but (tourist)pedestrians are prioritized higher, so motorists basically can't expect to move faster than the pedestrian in front of them.

[Michael Krog]

Adding a few examples here.

1: Korsør, Denmark

Ground truth (signs says "driving allowed" and "one way")

Graphhopper maps route

2: Korsør, Denmark

Ground truth (signs says "driving allowed")

Destination is parking spots in Pedestrian zone

Graphhopper maps route

3: Slagelse, Denmark (bicycles allowed)

This was remove as it was an issue with a missing tag on the node. (Fixed in open street map data now)

4: Slagelse, Denmark (tricky one, this one)

Ground truth
Signs say (in order):

• Errand driving allowed to church. Cycling allowed.
• goods traffic allowed 0-11
• taxis allowed
• Resident driving allowed

Graphhopper maps (by van)

[Michael Krog]

This has also implications for bike routing. If cyclists are explicitly allowed to enter, we shouldn't treat it as a pushing section.

What do you mean by "pushing section"? To me it seems that it works for bikes when they are allowed in pedestrian zones.

[otbutz]

Seems like we handle this case already properly for bike routing:

https://graphhopper.com/maps/?point=55.403963%2C11.35298&point=55.402384%2C11.354302&profile=bike&layer=OpenStreetMap

• highway=pedestrian + bicycle=yes: https://www.openstreetmap.org/way/333794059 -> driving allowed
• highway=pedestrian : https://www.openstreetmap.org/way/10710648#map=19/55.40315/11.35446 -> pushing section

[Michael Krog]

Oh. Literally a section for pushing bicycles. 😀 I thought pushing section was a technical term in Gaphhopper I didn't know of. I get it now.

[Michael Krog]

@easbar

this will impact the performance of the OSM import as well as the resulting graph size

Would it make any sense to introduce a tag filter (if none exists already), allowing fx. the car profile to include pedestrian only if it also has specific tags?

[Andi]

Yes, we need to allow highway=pedestrian for car only if it is explicitly allowed by other tags. The import performance is probably not too critical since there aren't so many ways tagged as highway=pedestrian overall.

[Michael Krog]

Okay. What I meant was filtering by tags already during the import process to only process a minimum highway=pedestrian.

I tried to se the difference in nodes/ways for with and without a filter on tags with a bbox just for Denmark.

way["highway"="pedestrian"][~"^(vehicle|motor_vehicle|motorcar)$"~"^(yes|destination)$"]["area"!~"yes"]({{bbox}});
Nodes: 1424
Ways: 371

way["highway"="pedestrian"]({{bbox}})
Nodes: 20236
Ways: 2898

So as I understand it, only about a tenth is applicable to a car profile (for Denmark at least - but maybe somewhere in the samme ballpark for other parts o the world)

[Andi]

So as I understand it, only about a tenth is applicable to a car profile

Yes, this way the number of additional edges would be reduced, but really the overall number of pedestrian edges will be small compared to the rest either way (less than 1% of all OSM highways are pedestrian).

The first place where OSM ways are filtered is in OSMParsers.java#acceptWay. Everything that passes here will produces some edges. If we wanted to apply the optimization you have in mind it would be here, but like I said maybe that's not even necessary.

We then need to make sure that in CarAccessParser.java#handleWayTags the access of these edges is false unless there is some tag like vehicle=car.

[Michael Krog]

@easbar I am gonna take a look at the issue with routing to/through pedestrian streets.

But... Isn't it gonna cause issues in big city centers where routing through pedestrian streets will often be the shortest route?

It is quite common (in Denmark at least) for pedestrian streets to not have a tag for max speed, although common knowledge here is that pedestrians streets have a low advised max speed (15kmh). Some pedestrian streets are =destination which would hinder route through, but not all pedestrian streets has that and it requires correct tagging.

I am afraid that allowing routing through pedestrian streets will cause unwanted routes in many city centers with poor tagging. 🤔

Edit
I see that destination and conditionals for opening-hours are open issues. Together with specific legal_default_speeds for pedestrian I think it will work fine.

I have added a PR for my current progress on this.
#2940