Either way, as a supplement to a barrier there are access tags that define access through the barrier, so you can do barrier =cycle_barrier + bicycle=yes, kinda like you can do building=church + amenity=stripclub.
It just starts things off in the wrong direction, and then you need extra tags to make a u-turn, and hope everyone reads all the other tags.
You’re missing cycle_barrier=single, cycle_barrier:installation=openable, and maxwidth:physical=* Tho I’m not 100% sure I would call this a cycle barrier, because the purpose is clearly not to slow down bicyclists, but to ward of dual track vehicles
I think you have a slightly wrong conception of what tags in OSM actually are. The tag value itself doesn’t contain the information, it’s just a consistent identifier for concepts defined by convention, proposals, common agreement about their meaning etc…
You’re free to make up your own tags, but don’t be surprised if no one uses them or someone changes it to an established tagging scheme.
Were you thinking of motor_vehicle_barrier? I didn’t invent it.
If enough people use it, perhaps it will gain the traction it needs to be recognized. The quality of the tagging certainly isn’t diminished compared to tagging with cycle_barrier
barrier=cycle_barrier has a established meaning while nobody knows what a barrier=motor_vehicle_barrier is supposed to be.
Just going by what the tag value evokes, anything could be a barrier for motor vehicles. (Single track motorcycles are also motor vehicles by the way…)
barrier=cycle_barrier has several meanings, one of which is correct and one of which is completely the opposite of what the barrier does.
If you ever encounter barrier=cycle_barrier as a data consumer, you don’t know if this barrier is the correct one or the incorrect one, and so you can’t infer anything from the tag other than barrier=whatever. You need to look at access tags to use it for something meaningful.
If people see the tag motor_vehicle_barrier, they will know that motor vehicles are not meant/allowed to pass. It’s literally in the name. The fact that people might not be looking for/at the tag is something else entirely.
You wrote “this string of characters” previously. I don’t believe that a tag value – or a tag name – is simply a string of characters. It conveys a default meaning in itself. A cycle barrier is a barrier for cycles. It’s not any random barrier, not is it a specific arrangement of steel bars. A trunk road isn’t any random road – it’s a particular type of road. trunk isn’t a string of characters, it’s the correct name of a concept.
If I tag highway=trunk on a residential road just because I think this residential road looks like other trunk roads, I’d be corrected quite quickly. People could think I was not very well aware of the world, and perhaps had applied the wrong pattern based on limited observations.
A cycle barrier can take make forms, as can a motor vehicle barrier. Multiple examples of real cycle barriers are pictured on the wiki. To insist that one of them is named a cycle barrier, and hence any similar objects must be tagged cycle barrier, resembles willful ignorance.
See Duck tagging - OpenStreetMap Wiki for a more thorough reasoning on why it’s a bad idea to tag something as what it isn’t, or as something meaningless, and then require several more tags to make the tagging useful.
The barrier=* tag is supposed to specify the physical structure of the barrier, not the access values. Those can be either inferred from the barrier type or are set with separate access tags.
What you are suggesting amounts to simply barrier=yes + motor_vehicle=no.
Don’t confuse ‘ideally should’ with ‘actually does’.
Using highway=trunk as an example is particularly ironic since its use and meaning is notoriously inconsistent across the world.
It’s not directly equivalent to the situation with buildings, but this separation kind of exists for barriers as well: The barrier value describes the form, the access tags describe the function.
To drive the point home, then, the staggered steel fences, the non-staggered, double or single, swinging steel gates, the slanted steel posts, and whatever physical structure a cycle barrier or a motor vehicle barrier would take, isn’t physically accurately described by the phrase “cycle barrier”.
Do you think it initially it could have been a slaughterhouse, grocery store or chemical plant? Does it look like an apartment building? Who else could have used this kind of architecture? A courthouse? Library? not really, maybe it could be a post office.
As if to underscore this point, a proposal being voted on is currently failing in part over concern about using an underscore instead of a hyphen. One of the hardest problems in computer science is naming, after all.
Historically, churches were usually built in a very distinctive style (as other places of worship often are), which tends to make them easily recognised and interesting to look at. Marking a church on a map may be useful to people in three ways:
They want to attend mass or otherwise use the church for worship
They want to admire the architecture
They aren’t particularly interested in the church, but it serves as a navigational aid (e.g. they can see that they need to turn left at the church)
To serve all these needs, it makes sense to mark both the historic building and the functional church, while also treating them as distinct types unless the functional church is occupying the historic building.