What do access tags on barriers mean?

General talk Tagging general discussion
, ,
1

_____________________________________________________________________
Moderator Edit:

This thread was split off from here at the request of the original creator. The new thread discusses the relationship between child and parent tags, particularly with regards to access tagging schemes.
_____________________________________________________________________

You didn’t include another option: Stop claiming that a bollard “implies” anything. What does that mean anyway?

I think we first need to sort out, and document, what access restrictions on a barrier are supposed to mean. Does “yes” mean “allowed”, does it mean “physically possible” or does it mean “allowed and physically possible”?

Is the answer different for different barrier types (e.g. bollards and gates)?

What’s currently documented on the wiki is that these tags are to be used for legal access restrictions only, and physical access is to be mapped with maxwidth:physical.

Therefore I think it would be really confusing, especially for new mappers, to document that a bollard “implies moped=yes”.

junction=roundabout implies oneway=yes, that means if I see a roundabout, I know I am only allowed to drive around it in one direction, even if it’s not explicitly tagged. So far, so good.

barrier=bollard implies moped=yes, that means if I see a bollard that means I am legally allowed to ride past it on my moped, even if it’s not explicitly tagged… ? Do you see what I am getting at? :slight_smile:

1 Like
2

In my point of view, legal access tags do not belong on physical barriers. Instead, the available width should be tagged using maxwidth:physical. This is closer to neutral data collection according to the OTG principle. Everything else is a lot of interpretation for me, which is not objective, as we do not have specific width limits for the individual users.

(translated with DeepL)

1 Like
3

Reading through the previous threads I understand where you are coming from.

In the Netherlands mopeds are allowed on many cycle lanes. When there’s a bollard on such a cycle lane, Osmose is asking people to add mofa=yes and moped=yes. Dutch mappers agree that this is nonsense: it should be obvious to a router that such a barrier=bollard node without any extra tags doesn’t prevent mopeds from going past. Therefore you are trying to define that globally, “bollard implies moped=yes”. Correct?

Why don’t you just report it as a bug in Osmose, and add to the Wiki:

In the Netherlands, where mopeds are allowed on many cycleways, the community does not tend to add an explicit moped=yes tag to bollards. Instead it is a reasonable assumption to make (e.g. for developers of routers) that bollards on cycleways can be passed by mopeds.

I think that would be much clearer than documenting that “bollard implies moped=yes” and trying to think of every vehicle type that can fit past a bollard, so it can be added to the “implies” list.

2 Likes
4

@osmuser63783 , @OSM_RogerWilco: Good point but a new concern to me.

When a Poll is made in discourse you no longer can add it without losing the votes so I would opt to split this off into a separate topic (meanwhile done so)

Based on a possible conclusion there we could in one step update the Template to no longer use “Implies” but use some other wording. The result of this poll can then still be used.

5

I don’t really think it’s right to say =yes for any of these as I would expect that to be inherited from the parent way.

Other than that it probably implies that anything two tracked is not allowed past that point, but it may be allowed up to that point from either direction depending on the context.

2 Likes
6

Yes, most often things are “inherited” from the parent way, see also my start post

32,9% of the bollards is mapped on highway=foot/pedestrian/cycleway and these access rights are more strict or matching these of barrier=bollard

Still there are bollards that are part of a highway=residential (4.6%) and for this is think it is good to give guidance on what is assumed can pass the bollard so that people do not start to map that pedestrians can pass the bollard but map it when somehow cars can/may pass the bollard.

1 Like
7

I’ve said before (very much tongue in cheek) that “Osmose is almost always wrong”. What it actually does is to identify things that you might want to check - not things that are actually errors. As the Osmose website itself says on its front page “In no case Osmose-QA should provide you the absolute right way to map”.

If someone is “fixing” every “bug” that Osmose finds then they are Doing It Wrong.

Whether its appropriate to ask Osmose to stop reporting things to check like this “mofa / bollard in the Netherlands” issue, I’m not sure - it sounds more like a feature request (for knowledge of Dutch law) rather than anything else.

To be clear, access tags such as bicycle=yes on a bollard describe the legal situation, not necessarily the physical one**. I can think of plenty of examples in the UK where legal access is allowed but physical access is restricted - such as narrow paths legally accessible by a horse and carriage, or very steep steps up which it is entirely legal to cycle.

Routers are interested in physical access as well as legal access, so if appropriate it makes sense to also map maxwidth or whatever.

** the exception is wheelchair which does describe physical access.

1 Like
8

But this is not what the wiki page says; it says:

By default access=no, foot=yes, bicycle=yes and similar like mofa=yes and moped=yes are implied. If something usually not blocked by bollards (cyclist, horse, etc) would be blocked then tag this explicitly. It is also useful to specify maxwidth:physical=* so that it is easier to determine who can pass the location

In the original proposal is was:

Access rights
By default, a barrier is considered to block all traffic on a way. Access restrictions can be used where necessary to allow certain types of traffic.
A bollard which allows bicycles and pedestrians:
barrier=bollard,bicycle=yes,foot=yes

I have always interpreted this to mean that the access tags should be used to indicate who is physically blocked or allowed past. It would be new to me that a bollard would legally block anything.

9

Indeed - but to be fair I wasn’t claiming that any particular tag page in the OSM wiki was “correct”, just how access tags in OSM work.

10

If it is not correct, I think it would be more important to correct it than to harmonize the infobox. But then we would also have to check the pages of the other types of barriers and possibly correct them. For example, wiki/Tag:barrier=log says:

You may also add further tags to more fully specify what kinds of vehicle or foot traffic have reasonably unhindered access, if this is the case, using access=*.

11

A search of the wiki for pages containing access finds 7,869. With barrier as well that drops to 1,282, but that would still be a lot of pages to proofead :smile:

12

For barriers it means for me mainly “physically possible” almost all access rights should be coming from the access tags the way the barrier is on. For stand-alone barriers (32.7% of all bollards) this is not a problem at all.

If there is a sign “no access” on a barrier is gate I can imagine that is mapped on the gate but it would make more sense to me to map it on the road “after” it.

The problem is with the a small percentage of bollards that for example are part of a highway=residential (4.6% of all bollards). Here the default access rights are not sufficient but mapping “motor_vehicle=no” on the way is also not correct to me.

I think everybody agrees that pedestrians can pass a bollard and most often (>95%) cars can not pass a bollard but I think we should document that assumption. This so mappers are not tempted to add motor_vehicle=no to every bollard. It becomes more interesting with “in-between” categories like horses and motorcycles.

On using the access tags for this. Not ideal but I do not see a better alternative.

Using maxwidth:physical is good but mapping that is not very easy and how many people do know from their head how wide their car or bicycle is.

2 Likes
13

Unfortunately this new thread has been split off from the parent so that the context (which was about the misinterpretation of access tags in some language variants in the wiki) has been lost.

in some places in the world there’s a “general right of access”, and some people there don’t think that it is important to tag what the legal access right actually is (which is what tags such as foot, bicycle etc. have historically done). In others (such as where I live) it is extremely important to record that, which is why it’s also important to record what physical access is possible separately to what is legally allowed.

It is of course entirely reasonable for a router to assume that if there is a e.g. barrier=block on a road that it should not route cars down there. That doesn’t imply that there isn’t legal motor vehicle access (the block may be illegal).

I would suggest that any barrier with access tags that disagree with the way that it is on is at best incompletely tagged - perhaps the stretch of road that the barrier is on should really be considered a cycleway (or have access tags to reflect cycle, but not motor vehicle, access is allowed.

1 Like
14

Frustrating that this has been split when it’s core to the point of: a barrier never implies =yes by itself (without a sign).

maxwidth:physical and bicycle:physical are both documented. Maybe we should explicitly extend this suffix to all other access? This would give a quick way for mappers to eyeball the impact of a barrier without a legal judgement.

15

I agree with you in general, except that often a bollard or other barrier only prevents passage from one side to another, but both sides remain accessible by way of other roads or paths. Such barriers are often installed in residential areas as traffic calming measures or to discourage overflow parking. I wouldn’t object to a QA tool flagging mismatches between barriers and the ways they’re on, but it goes back to your point that a validator is not infallible.

3 Likes
16

This was done on a request of me and me asking @osmuser63783 privately if he/she did agree and it should not be a surprise.

This discussion is not about if horse=yes should be on barrier=bollard nor if it is a not idea to harmonize things over the different language Wiki’s so I still think it is a good choice.

Like I wrote, most often this is the case, but a small percentage (4.6% of all bollards) is mapped on a highway=residential.

If I understand you correctly you would not map this as a highway=residential?

Screenshot_20240208_214204
Screenshot_20240208_2142041005×752 1.09 MB

See also Mapillary

17

That’s not a permanent barrier - it’s a rising bollard specifically to control motor vehicle access. I’d expect the bit of road with the bollard on it to have access rules for normal cars that evaluate to private or similar. I wouldn’t expect the access rules (if any) on the bollard to be different to that stretch of road.

18

I don’t agree in general, for the reason explained by Minh. The access tags of a barrier do not necessarily have to be the same as those of the roads on either side (if any). You can have a barrier that doesn’t let people (or things, e.g. wide vehicles) pass, e.g. a locked gate in a fence, a bollard, etc., although you can freely access both sides of the fence.

2 Likes
19

That’s absolutely not the case in the case of the posted picture. There’s a section of the “residential” road marked with extra kerbstones that is clearly not designed to be accessed by cars.

20

…and it’s barely 3 meters long:
https://www.mapillary.com/app/?pKey=4109980715733876&focus=photo&lat=51.980518888889&lng=4.4689058333333&z=17
…so it isn’t so “clearly” after all.

Having browsed the surroundings, I tend to agree with emvee that both surrounding roads are residential, and that the barrier was installed with the primary purpose of diverting motorized traffic around the quiet neighborhood.