What do access tags on barriers mean?

Thanks that is something we agree on :wink:

It is interesting to see that in this sentence you “give” the access rights to the bollards but somehow still think it should be on the road.

I do not agree, check Google Maps I would say, you can use coordinate 51.9808518, 4.4681873

Where I am, we have entire uniquely-named streets not much longer than that :smile:

:mag_right: I see here a traffic sign for holders of exemptions without a time limit/restriction. From this I conclude that it is a remote-controlled bollard that can be lowered by the driver if necessary - if you have a permit. So the bollard should have an access=yes and motor_vehicle=permit.

The roads on both sides offer no restrictions for vehicles, i.e. free access. So: the implicit access=yes without any further restriction.

Do you agree :question:

edit: as reply to @emvee No. 24 :innocent:

Yes, I had already updated the bollard.

access=yes is to my opinion unneeded because by default pedestrians, bicycles, mofa’s and moped (and likely horses and motorcycles) can physically pass the bollard .

1 Like

By the way, do we know if all the major routing profiles make this assumption? There isn’t an LLM-based routing engine yet – yet – so one can assume that any sentence on the wiki beginning with “by default” will be roundly ignored by the routers people actually depend on. Maybe the documentation is right by coincidence though.

Not sure what car routing against an one-way street has to do with bollards, the distance between the two points is with 26 meter way longer than 3 meter and not sure why osrm can not dream up a route.

Back to residential bollards, something to visit during the weekend?

I would like to give routers and mappers a clear set of assumptions and because that I started the original topic. routers so they know what to implement, mappers so they know what to add (if anything) on top of the set of assumptions.

I would tag this motorcar=private and not add access=yes as I see it implicit for bollards, but some people prefer interpreting any barrier as access=no and so in this interpretation you always tag positive access.

The situation is “private” if the required permit is given on an individual basis and not to everyone.

1 Like

It was a joke - do I need to use a bigger smiley or something?

I already did that 9 years ago :smiley:

I don’t think that anyone bothered to add access tags to the bollard because it’s the road that the access signs apply to. The bollard is just an enforcement mechanism.

(drifting somewhat offftopic)

The more challenging example would be the complicated anti-terrorist moving bollards such as here (not fully mapped in OSM yet). For an entirely fair and balanced discussion of them with absolutely no hyperbole see here. There’s also a video and a picture of a dalek.

1 Like

I can think of a few places where there’s a bollard between two residential roads, installed to prevent through traffic. There aren’t any signs anywhere that would legally prohibit going past. Riding past on a bicycle or motorcycle is practically possible (and I see no reason it should be illegal), driving past in a car is practically impossible (and the question whether it is legally allowed is a purely theoretical one).

When this is a stretch of road, even a short one, it can be split off and tagged as cycleway or pedestrian. When you can drive up to the bollard from both sides, a simple barrier=bollard node does the job just fine, doesn’t it? OSM-based routers will generally route pedestrians and bicycles past a barrier=bollard node that doesn’t have any access tags, and they won’t route cars past it.

Mappers then seem to sometimes add access tags like foot=no or vehicle=yes if they want to override this default routing behaviour. That doesn’t have much to do any more with actual legal access.

This is why I find it confusing when the Wiki asserts that barrier=bollard “implies” a legal access restriction.

I’m all for documenting mapper consensus and default assumptions that routers make, but there must be better ways of doing this. For example a Wiki page “routability of barriers” where we document how various open-source routers treat various barriers when they do not have access tags.

4 Likes

Thanks for once more writing up what is the concern, using access tag on barrier nodes.

I know Key:access has (currently):

Access values describe legal permissions/restrictions and should follow ground truth; e.g., signage or legal ruling and not introduce guesswork. It does not describe common or typical use, even if signage is generally ignored.

But I know more than enough examples that are not following this. Only looking at nodes:

  • What do you think on bicycle=yes/no as “access-tag” on a highway=crossing? I (still) think it is a bad idea but some people think that if things are mapped for a small percentage, it is something that should be documented.
  • While for highway=crossing only 0.17% of the nodes has bicycle=no (taginfo), for barrier=bollard about a quarter has foot/bicycle= (taginfo), are we going to remove all these?
  • information=guidepost uses “access-tags” to indicate for what type of traffic the guidepost is
  • information=map uses the “access-tags” to indicate for what type of traffic the map is
  • amenity=charging_station uses the “access-tags” to indicate what types of traffic the charger supports
  • highway=traffic_signals uses the “access-tags” to indicate for what type of traffic the traffic light is

The list is a lot longer:

nodes with at least 100 times bicycle=* mapped
> ./nodes_with_bicycles.py
barrier=gate                   - 228191
highway=crossing               - 208139
barrier=bollard                - 158036
information=guidepost          - 90966
barrier=lift_gate              - 78165
barrier=cycle_barrier          - 37804
barrier=block                  - 32760
barrier=swing_gate             - 18910
information=route_marker       - 16074
barrier=entrance               - 14304
amenity=charging_station       - 12276
information=map                - 11743
highway=traffic_signals        -  8648
no_main_key                    -  7502
barrier=cattle_grid            -  7301
barrier=kerb                   -  5538
barrier=kissing_gate           -  5340
barrier=stile                  -  4815
barrier=chain                  -  3408
ford=yes                       -  2812
railway=crossing               -  2623
entrance=yes                   -  2611
highway=elevator               -  2076
barrier=turnstile              -  1693
barrier=hampshire_gate         -  1660
barrier=no                     -  1613
barrier=border_control         -  1583
barrier=sally_port             -  1375
barrier=bump_gate              -  1343
amenity=motorcycle_parking     -  1299
barrier=toll_booth             -  1200
railway=tram_crossing          -   959
barrier=yes                    -   913
railway=subway_entrance        -   769
highway=street_lamp            -   690
entrance=main                  -   597
barrier=log                    -   536
barrier=full                   -   504
highway=emergency_access_point -   442
barrier=planter                -   440
barrier=jersey_barrier         -   437
amenity=parking_entrance       -   399
information=board              -   327
highway=trailhead              -   322
barrier=wicket_gate            -   313
traffic_sign=GB:1057           -   310
barrier=full-height_turnstile  -   273
barrier=sump_buster            -   258
amenity=bicycle_parking        -   250
barrier=fence                  -   247
highway=motorway_junction      -   239
amenity=ferry_terminal         -   206
barrier=debris                 -   196
highway=give_way               -   191
railway=level_crossing         -   186
highway=turning_circle         -   181
barrier=motorcycle_barrier     -   170
barrier=sliding_beam           -   158
barrier=height_restrictor      -   149
barrier=bus_trap               -   132
highway=bus_stop               -   131
highway=stop                   -   126
traffic_sign=DE:254            -   123
traffic_sign=gb:1057           -   123
amenity=compressed_air         -   111
barrier=footgate               -   108
highway=toll_gantry            -   104

Also good that have a look at the Wiki, Key:bicycle, what links here. There are 86 Tag:key=value pages that link here.

My conclusion is that the text on Key:access is no longer valid the “access-tags” are used widespread for things that are not legal but more for designate use.

I am not against such a page but for a complete solution there needs to be also a way to tag exceptions, if the “maxwidth:physical” is wide enough for a car or too small for a typical bicycle how is that going to be tagged?

I also think the use of the “access-tags” outside legal use is too widespread to “clean it up” or are there volunteers to do so?

1 Like

Indeed, the first example that comes to mind for me is highway=path. This tagging scheme uses the foot, bicycle, and horse access keys to indicate what the path is designed for, with the original intention of consolidating highway=footway, highway=cycleway, and highway=bridleway.

I agree that the idea of limiting the access keys to legal restrictions is a bit aspirational. It might still make sense as a rule of thumb, for situations in which legal restrictions would be apparent. However well-intentioned the focus on legal restrictions, applying that focus to many of these miscellaneous situations would result in hypotheticals that aren’t as relevant to a mapping project.

I suppose we have some more entries to add to the wiki’s lists of skunked tags and homonymous keys

3 Likes

Uck no.

If you want a new tag to express whether something is physically passable, create that new tag. It wouldn’t be a bad idea at all. accessible:bicycle=no - sure, why not.

But do not, repeat, do not break a well understood existing tag to communicate that. This is why consuming OSM data is so hard - because people are intent on redefining things that were settled fifteen years ago.

Changing the definition of access tagging doesn’t make life easier in any circumstance, it just means we no longer have a way to determine whether pedestrians or cyclists or motorists or whatever are allowed on a path.

2 Likes

At this rate, we would need two namespaces to fully resolve the ambiguity from these skunked tags: one for reachability (can I?) and another for permission (may I?). Sticking to a purely legalistic interpretation of access across all kinds of features would be a lost cause at this point.

Practically speaking, an access key actually represents the combination of reachability and permission. A pathway must be both reachable and permissible in order to consider it a yes. A value like private would make no sense if we were only concerned with reachability. It’s not as though a car automatically gets stuck because it doesn’t have the right papers. On the other hand, we need not wait for the authorities to post a legally binding Road Closed sign in order to finally tag a partially collapsed bridge with access=no. If a daredevil stunt performer needs a routing engine, they can do their own research.

Anyways, I’m not confident that we actually have a systemic problem here. In the grand scheme of things, edge cases like this one bollard shouldn’t determine how we tag more routine situations. If in doubt, err on the side of caution and leave a note for anyone who wants to push the boundaries.

4 Likes

I guess you mean “bicycle=yes” or “mtb=yes”? Mind you, it is not “foot=yes” but “hiking=yes” instead. Key “bicycle” has access meaning too, maybe rather tag “cycling=yes” instead? Key “mtb” is like “wheelchair” as far as I observe. No access meaning at all.

See “nodes with at least 100 times bicycle=* mapped” in my earlier message, information=guidepost is mapped with icycle= 90966 times, cycling=yes is never used in combination with information=guidepost, check taginfo.

Mind you, it is not “foot=yes” but “hiking=yes” instead.

:+1:

I do not have the desire to use another tag then the “access tags” to indicate something is physically passable but I would urge people that think otherwise to make a RFC for something like accessible:bicycle=no so at least there is an accepted alternative.

We do not have to change the definition of access tagging as it is now we just have to limit it to paths and roads (Key:highway) and that is I think what most people care about. There is one notable exception that I already documented in one of my earlier posts.

For everything other then Key:highway, the “access tags” are very widespread used, not for legal access but more as “designated”, for a list see my earlier post.

Does anybody feel the desire to “cut down” the usage for the non-highway use of the “access-tags”. If so what alternatives are present?

Mind you, it is people mapping using what is available in the tagging nomenclatura. Making sense of that algorithmically, certainly @Richard know their stuff. I am a human, I can tally the intricacies.

The proposal for bollards was appoved more than 15 years ago.

3 Likes

Not sure I understand what you are trying to say with this.

Are you saying that cycling=yes is never used in combination with information=guidepost because it is never documented that way? If so that make sense, the page indicates to use to use “bicycle=yes”

Note that is why is was urging people to make a RFC for something like accessible:bicycle=no if they think the “access tags” should not be use for barrier=bollard.

See, its people, people can make sense out of anything :slight_smile: Accessibility can mean: by law, by power. I’d say, these are not the same. So separate terms perhaps warranted: Aiding in reproducibility of what is in term. As of now, consumers are tasked to decide case by case.