Thanks that is something we agree on 
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 
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 
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 .
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.
It was a joke - do I need to use a bigger smiley or something?
I already did that 9 years ago 
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.
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.
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:
The list is a lot longer:
> ./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?
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âŠ
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.
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.
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.
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.
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 
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.