Pedestrian access on national roads (four-lane 90/120 km/h roads)

This weekend, I hiked in the Sambreville/Farciennes neighbourhood and OSMand gave me a shortest path using the N90 road, similar to this route.

The road looks like this, extremely hostile for pedestrians, especially it was already nearing dusk. I would not walk here and I’m used to doing stuff that others call dangerous.

Legally it is allowed to walk and bike here (as far as I know). There is currently no “do not walk” tagging here, although the three online routers seem to avoid this route if an alternative is available, probably due to the highway=trunk.

In Marking roads on which pedestrian access in dangerous I saw the discussion of foot=discouraged, a subjective and, according to the wiki, controversial tag.

Do you think we should map roads like this with no shoulder with foot=discouraged?

A little eastward, there is at least some sort of pavement to the right of a gutter, clearly meant as a combination pedestrians/cycle/emergency hard shoulder. I would walk here during daylight.

My first suggestion would be to add sidewalk=no tags where appropriate

Edit: also lit=no if appropriate. Both are not tagged on Way: ‪Route de la Basse Sambre‬ (‪58731364‬) | OpenStreetMap. These are objective, verifiable tags that might help routers give better routes

3 Likes

I would add sidewalk:both=no + cycleway:both=no + shoulder:both=no to make it explicitly clear that there are no safe (or even semi-safe) paths for non-vehicular travel.
I would not use *=discouraged unless it is signed.

3 Likes

As an occasional cyclotourist in Belgium, I would want every possible tag to discourage routers from leading me there, short of claiming a legal restriction if one doesn’t exist.

Does Belgium have some policy on the use of expressway=yes ? I believe motorroad is tied to a specific traffic sign, but expressway seems to also be used, and (without explicit tags promising bike infrastructure) that could work as discouragement?

In this case, the road is a separated carriageway. Would you add sidewalk:both=no or is sidewalk=no sufficient (only adding sidewalk=right if there is one at the right)?

And in the example I showed earlier, there is no explicit sidewalk or cycleway, it’s one combined stretch of pavement right of the gutter, how to tag that?

Does shoulder=yes imply any fitness for foot/bike travel? The wiki seems to imply so.

Also, I don’t own a car and it’s very hard to check on sidewalk/shoulder presence without using Google Street View, and my computer hates Mapillary… So I’ll fill in the stretches that I know.

Would you add sidewalk:both=no or is sidewalk=no sufficient (only adding sidewalk=right if there is one at the right)?

“Sided” suffixes (*:left, *:right, *:both) are better than the “unsided” versions, as they remove all ambiguity. However, I would not consider the unsided tags to be wrong, just suboptimal.

note

Well, *:both is not really ideal, and I’d rather everyone just used *:left and *:right with the editor UI making the translation of *:both split into *:left and *:right with identical values, but that’s besides the point. *:both is still better than “unsided”, and is established enough that I have to just accept doing the translation on the data consumer side. Oh well.

Does shoulder=yes imply any fitness for foot/bike travel?

Yes. It’s suboptimal compared to an available dedicated feature if one exists (like a bike lane, sidewalk, cycleway, etc.) but it’s common - especially in rural environments - for these unofficial paths like shoulders (both paved and unpaved) that this is the only possible way for non-drivers to travel.

The road looks like this, extremely hostile for pedestrians


Source: Google Maps

sidewalk:both=no + shoulder:both=no + cycleway:both=no applies to both highway=* ways.

For the other examples, I am not familiar enough with your region to confidently advise how that shared-use path should be tagged, so I will defer to your fellow local mappers.

1 Like

No. =discouraged is for when there is formal signage discouraging (but not forbidding) certain classes of user from the road.

4 Likes

I might add verge:both=no just to make it clear you can’t even walk next to the road.

It’s not a commonly used tag, and I don’t think many pedestrian routers look at it, but for a pedestrian it can make a huge difference whether there’s a walkable verge or not, so I hope it will become more commonly known.

3 Likes

Key:class:bicycle - OpenStreetMap Wiki might be worth adding, but also disputable.

Not mentioned yet, but I think foot/bicycle routers should already flag this kind of roads as “not usable” based on the maxspeed which is for the stretch of road is 90 km/h.

Without any positive sidewalk/cycleway tags such a 90 km/h road should be get a huge penalty, even with a positive sidewalk/cycleway tag it should get a major penalty.

It’ll always be a balance. OSRM gives a route avoiding the trunk and it’s 4.4 km, 41 minutes. So does Valhalla. That’s a large tradeoff over the 2.8 km route including the 1 km trunk stretch that GraphHopper prefers.

Ultimately what would really help is better display of route tradeoffs and bad parts, and giving user alternatives - that will require implementation work on osm.org as well.

In this case it is a limitation that GraphHopper uses the trunk although it shouldn’t be allowed in this country for foot. We currently work on it.

Ultimately what would really help is better display of route tradeoffs and bad parts

I’m all for this :slight_smile:

Adding certain “route hints” would be already a nice step forward (issue was not even suggested by me :wink: ). And I do not think this is just a gimmick or osm.org should link to external routing engines like suggested in the issue. In fact these route hints could give a very simple way to explore different OSM tags along the route, so it should be also enabled on the API level.

Also note that if you slightly avoid trunk highways a bit more for GraphHopper then you are presented with good alternative routes.

In terms of routing, I think the main problem is differentiating between ”completely avoid a death trap road” and ”avoid some parts of death trap road by crossing it multiple times and paying more attention to turn cues than the traffic”.

(Pictured road has a 100kmh speed limit with 0 to 10cm shoulders, but no concrete walls trapping victims.)

Edit. Link by request. In cycling mode it takes a lengthy detour to completely avoid the red road, which still ends up including a long bit of a road that’s essentially similar, just with a lower speed limit (did not check what’s tagged).

Most competent bicycle routers will judge that among many other factors to find a good route. Speed limit alone is not really a lot of use - see, for example, this road which has a 97 km/h limit (well, 60mph) but is an absolutely delightful cycling road.

Unfortunately, the state of the art for pedestrian routing with OSM tends to lag behind bike routing.

Yes, agreed traffic volume is also important in this aspect and while we do not map that it roughly correlates with road classification.

Looks to me that still for roads not being highway=unclassified maxspeed is still the way to filter out roads without a positive sidewalk/cycleway tag that are outside the built up area and are bad to walk/cycle and those within city limits that are still doable.

At the same time within cities there are alternative roads that are better used so unlike I wrote earlier, using maxspeed is not an easy way to improve routing.

Country-specific access rules are now implemented for bike and foot too according to the wiki. (See the example route above and this pull request for more details)

1 Like

In Belgium the relevant legal rule is that you cannot walk on motorroad=yes. The national defaults table on the wiki is filled in based on the assumption that all highway=trunk are motorroad=yes. However, in absence of a precise consensus on when to use highway=trunk, this assumption isn’t always correct.

On a dual-carriageway road with two lanes per direction without any traffic signs, you are allowed to walk, and cars are allowed to drive 120 km/h, and the road is reasonably likely to be tagged highway=trunk.

Why not fix the wiki and make this differentiation like it is done for several other countries :slight_smile: ?

However, the discussed trunk way would be accessible for foot again (which GraphHopper tries to avoid but not at all costs). Or is this the problem you are referring to? But then I would still suggest to fix the wiki and additionally fix the involved trunk roads like the discussed ones.

Yes, this way being accessible for foot traffic was probably correct in theory, it just seems to get insufficient penalties. Somebody might correctly add foot=yes and then the problem is back.

I had previously clarified this very issue in the wiki table for the Netherlands (where I mostly map). I’m not sure what the correct/desirable usage for highway=trunk in Belgium is and also unsure which assumption a data consumer should make to minimise errors.

highway=trunk is difficult in Belgium, because it intuitively maps to our “express roads”, which are “fake motorways” which we built a lot in the seventies/eighties when we ran out of money to build proper freeways. But the exact definition of those is a bit vague. Then we also have “slightly upgraded two lane roads” that are often marked with a motorroad sign. But many of these “nicer two lane roads” don’t have that sign, and on the other hand governments sometimes put those signs on the craziest places, like just on a short bridge (because they like the underlying implications of that sign for that specific bridge"). So in all that mess, it’s pretty hard to come up with something that is not subjective to the degree that different mappers will come to different conclusions…

1 Like