How to tag barriers for all routing engines?

Hi,

Summary: different routing engines do different things with barrier=yes.

I commented on an edit I thought was low-quality:

The organised editing team (Amazon? Mapbox?) have made some changes, which in my opinion improve things. The barrier is a node tagged barrier=yes.

But it doesn’t route very well. Some routers think a barrier=yes is closed, some think it is open.

Logic table:
Bicycle (Graphopper) open
Bicycle (OSRM) closed
Bicycle (Valhalla) open

Car (Graphopper) open
Car (OSRM) closed
Car (Valhalla) closed

Foot (Graphopper) open
Foot (OSRM) closed
Foot (Valhalla) open

(see for yourself here)

I’m planning to suggest to the editors that based on the information they have, that they should tag the node

barrier=yes
motor_vehicle=no

That is all the information they have.

Will this route consistently? Or should they also be advised to add access=yes as a third tag? This is the suggestion on the wiki here, but I’m still not sure if that would solve this “different engine, different routes” problem.

Thoughts? And is there anywhere we can read the policies of different routing engines?

Thanks.

First: barrier=yes is incorrect mapping, have a look a Key:barrier and see that the possible values differ greatly.

For nodes, taginfo for example gives as of now 1 033 710 kerbs and 634 826 bollards.

The wiki says:

A barrier which nature cannot be determined; typically only used in mapping using aerial imagery. Should be replaced by a specific value.

I would argue that in that case you better not map the barrier at all, unless you use access tag to make clear the access.

motor_vehicle also including things like moped’s and mofa’s and strictly speaking also 25 km/h electric bikes.

1 Like

No, as it is unclear what kind of barrier it is. It could be a bollard, it could be a closed gate.

With motor_vehicle=no on it I would expect car routing to be blocked and it may make sense to open an issue if it is not. But bicycle and foot routing still must purely guess as OSM data has not enough info.

Some publish source code at least.

Why? It at least gives hint for people that survey would be useful.

incomplete, not wrong

2 Likes

Amazon.

Agreed - however I suspect that what has happened here is that an Amazon editor got a report from one of their drivers that a road was inaccessible to their vehicle. They didn’t have any local knowledge (and at first glance imagery seems unclear) and so did the least change possible to resolve the issue for their use case and added a note. If you’re familiar with the area I’d suggest updating the barrier with details of what it actually is. If not, leave the note and the node for someone who is.

The example routers on osm.org are basically just general “proof of concept” examples - adjusting tagging to match their results would be often wrong.

2 Likes

Thanks for all comments.

Maybe I’ve been guilty of over-correction here, but not sure about that yet.

The initial edit by aepunavy replaced a short stretch of road with a cycle path. This seems to be a common way of dealing with this situation by Amazon (see also here and here, among other examples I’ve seen).

This seems not to follow the on-the-ground rule, and does more than the “least change possible”. Reading from OS Open Local it does look like the road has been removed, but the aerial shows that in fact it’s simply a barrier of some sort.

In this case I think I missed that the driver (apparently; if only we could see their feedback!) notified the mapping team that this was passable by bicycle. Very often (and I think I jumped to the conclusion that this was the case here) we just see “driver reported they couldn’t access” + edit to insert cycle / foot path.

To me it seems the correct approach for these situations in general (here’s another, by mapbox I guess, which was a note for a long time) would be:

  1. Road unchanged.
  2. barrier=yes (assuming no further info)
  3. access=yes (that is, as the road was before the barrier; or if road is not access=yes, its own restrictions will prevail for the router anyway)
  4. motor_vehicle=no (because all Amazon seems to have learned is “our driver couldn’t pass”)

In response to my comment on the note, deepikja removed the miniature cycle-path added by aepunavy: see here.

Thoughts on my approach and her response?

I’m minded anyway to re-engage with deepikja and find out exactly what they get from their drivers in these cases. Unless that’s already been established somewhere else in OSM-world?

Thanks.

in case of such bollards/planters breaking road in two and leaving bicycle bypass tagging it as a short cycleway may be reasonable…

Though not convinced that it is superior

1 Like

Each OSRM profile maintains its own whitelist and blacklist of barrier types that are passable or impassable by default. These defaults can be overridden by the usual access tags.

For example, here’s the whitelist for the car profile that comes with OSRM:

By contrast, the built-in bicycle profile has a very conservative blacklist:

FOSSGIS maintains the instance on osm.org. They’ve customized the bicycle profile to replace the blacklist with a more extensive whitelist:

Other routing engines also leave decisions about barrier passability up to individual profiles.

2 Likes

For a hint the notes system works much better.

Also this seems to an implicit assumption that, given a barrier=yes, would mean would be earlier updated than a new barier=<correct_value> which I do not think is correct. I think people map earlier a barrier that is not present then that they update a barrier=yes.

Did you read what I wrote earlier on motor_vehicle=no?

Some barriers defy classification. For example, I’ve encountered a trail closure that consisted of a ditch, a berm, a pile of fallen logs and branches, a strand of barbed wire strung across the trail at neck height with a “no trespassing” sign hanging from it, and some sharpened stakes set into the ground. How would you tag that, beyond barrier=keep_off_my_property?

Yes. In the UK, where this is, I know zero cases where motor-vehicle excludes the things you’ve mentioned. Here, “motor-vehicle” means “mechanically propelled”. So, at least from the point of view of road rights, an electric scooter and a family car are equivalent.

1 Like

I face a similar case in my area, which the barrier on two roads is a big pile of dirt. The closest documented value, seems to be barrier=debris (“A road is blocked by debris with or without ground. This might be for short or long time. Often used as first (temporary) step in blocking an abandoned road, or a road in construction.”).
It may not be the most proper in your case, but I think it’s the closest from the documented ones.

3 Likes

In this case we know there’s a barrier, and we know a driver of a van can’t pass it. As far as I can tell, in these situations Amazon doesn’t usually know more than that. I’m not sure why we wouldn’t tag barrier=yes here. In my experience, weird routing has often been a hint to me that a barrier needs refining.

1 Like

I know that, strictly speaking, it’s breaking the One Feature One Element rule, but you could add separate ways of:
Tag:barrier=ditch - OpenStreetMap Wiki + Tag:barrier=log - OpenStreetMap Wiki + Tag:barrier=spikes - OpenStreetMap Wiki + Tag:barrier=fence - OpenStreetMap Wiki, together with fence_type=barbed_wire

The fence will definitely render, & I think the ditch as well, so on the map, the track would be visibly shown as blocked.

1 Like

Are you saying that in the UK a mofa can not pass a barrier=bollard?

I have less problems with barrier=yes if it also has the appropriate access tags but checked all barrier=yes nodes and 89% are nodes with only “barrier=yes”

Your example clearly shows why I think it is better to no to map barrier=yes, with barrier=yes your routing would likely not be strange so you will not get that hint.

barrier=ditch barrier=log and barrier=barbed_wire and barrier=sharpened_stakes as separate nodes on path way ?

And I guess access=private (and police report if they have no right to block public access).

that is a good outcome - to have more usable map until more detail is added

though you can add barrier=yes with known access tags AND make a note linking it

Yes. Of course it’s physically possible, but it’s not legal, and so not tagged. (And we don’t really have mofas, I don’t know why not. Probably something legal, again.)

1 Like

The somewhat bizarre situation in the UK is that it’s not legal to use a privately owned electric scooter on public roads in the UK but it is legal to rent one from one of the rental schemes operating in many cities now, hence the “Of course it’s physically possible, but it’s not legal” answer lower down.

MOFA isn’t a thing in the UK, although bollards tend to have signs prohibiting motor vehicles to prevent use by motorbikes and mopeds

Okay, I was not aware that in the UK mofa’s are a hot debated subject, I searched for “scooters uk” but the only thing that was returned was information about e-scooters and a push to get things legalized.

So I understand mofa’s are some grey zone in the UK, instead let’s talk about these type of scooters, I assume you call that moped.

Are you also saying that although a moped can physically pass a bollard there is some UK rule that makes this illegal?

Yes. Details aside we have three basic divisions of highway:

  1. Travel on foot (and since you’re taking an interest in UK things, we sometimes call this Shanks’s Pony)
  2. Other glucose-powered travel (horse, bicycle)
  3. Petrochemical- or electric-powered travel

Generally if you can travel on a lower-numbered highway, you can also travel on a higher-numbered highway, but not the other way round.

That’s a long way of saying that scooters aren’t bicycles.