I wholeheartedly agree with these sentiments.
While I appreciate the proposal for it’s intention and the thought that went into it, cycleway without side postfix is widely used.
For one, the statistics that the proposal refers to, actually present a skewed image, because they don’t look at the total tag-usage but only at individual values. Taginfo has 1 509 580 for cycleway:both= and 1 073 903 for cycleway=, that’s nothing to spit at and gives a much better idea of how they compare than the split graph.
Besides that, those numbers might actually be an argument against, in my book. Based on the discussion here, accepting the hypothesis that cycleway:both= is primarily used/added/popular among StreetComplete-users. If that’s indeed true, it’s a good thing to remember that those by definition don’t add the tag by hand (but tap an answer in their quest), as opposed to users of other editors (let’s, for neutrality sake, say JOSM) who do.
And if that’s indeed the case, it’s actually a compelling argument to let both exist. Not deminished by the fact that cycleway with postfix is more complicated, in other words: more error prone and in general less accessible to new mappers. And, as has been pointed out:
It indeed allow for a granular level of control/detail. Same as adding sidewalk=left/right/both is a very low level, easy and accessible way for people to indicate that a side walk is indeed there, without having to get into the nitty gritty details about it if they’re not ready to, the same logic applies to cycleway to some extend - especially some of the basic values such as cycleway=no. So again, it’s just a more accessible tagging scheme that allow new mappers to “ease” into mapping.
This leaves mappers and data consumers in a situation where the definition of cycleway=* (no side subkey) is unclear:
- It could mean “a cycleway somewhere on the way.”
- It could mean “a cycleway on the primary direction of the way” (e.g., on the right in many countries or when used on a dual carriageway).
- It could mean “a cycleway on both sides of the way.”
While I did read this in the proposal, that doesn’t make it fact. I’m actually quite curious what the factual basis for this is? Where can information that support these statements be found? Are there renderers or routers that get confused by the lack :side postfix? Because if not, it might be more like a perceived problem then a factual one - but I’m open to learning that it is actually confusing in a significant way.
To illustrate, personally I thought that adding cycleway=shared or soon probably cycleway=no would add in case of, say, a highway=residential as it shows that I’ve been there, and confirmed that no cycle-infrastructure is present (as per the definition of both). However, it was recently explained to me by someone that this is an assumed default just as much as oneway=no or bicycle=yes for this road-type and therefore has no actual added value. No renderer or router will treat the road different for it.
The same seems to apply for - say, as an example, given your other proposal and RFC - cycleway=no vs cycleway:both=no.
And if that’s the case, the same logic that actually is the basis for the Proposal:Deprecate cycleway=shared - OpenStreetMap Wiki applies here too (emphasis mine):
(…) suggest replacing it with more accurate tagging or removing it when it provides no additional information.
So, pending the factual basis for the presumed confusion that is the basis for this proposal, I think there is added value in letting the simplified scheme exist side-by-side to the more detailed one, both to encourage new mappers that don’t use an editor which selects the tag for them, and as a convenient shorthand for more experienced mappers.