[Tagging] Proposal process [was: healthcare]

[Minh Nguyen]

Vào lúc 03:26 2022-11-06, 
mail at marcos-martinez.net đã viết:
> Some time ago I asked Alexander Borsuk (Organic Maps). The context was 
> the debate on the "contact" controversy but it can be extended to other 
> less heated topics... (The conversation was in the open OM Telegram 
> channel and can be found by everyone, so I am not disclosing opinion, 
> subject to privacy)
> 
> The key sentences for me are:
> 
> "A bigger problem is different public transport schemes, where it’s way 
> harder to write a “converter” from one into another. For example, subway 
> map in Vienna was missing because local community decided that it’s ok 
> to have two different level platforms in one stop_area. That is really a 
> pain."
> 
> "...the proper way would be to merge into multiple values for one chosen 
> tag (and filter duplicate values, of course). That’s a bit of a hassle, 
> but it is solvable."
> 
> "Of course it is easier if all tags have the same scheme. Then we don’t 
> spend our time on the scheme differences, focusing on a better product 
> instead."
> 
> Let me ask you then: Can you provide evidence or a few examples in which 
> tag standardization is harmful or represents any disadvantage?

Data consumers aren't a monolith. Churn in our tagging schemes can break 
existing software and harm end users in the real world, unless we set up 
migration paths and raise awareness. Conversely, if we don't clean up 
our tagging schemes at all, then we make it harder for developers to 
adopt new kinds of OSM data effectively.

Fortunately, there aren't too many high-profile examples of tagging 
churn deliberately breaking data consumers. This community has been 
careful to preserve backwards compatibility -- you might say too 
careful. One example I'm aware of is that, for years, the definition of 
highway=trunk in the United States had differed from the global 
definition, focusing on physical characteristics, but since last year 
there has been an effort to harmonize the definition and shunt the 
physical characteristics over to expressway=yes. [1] This will require 
changes to some routers such as Valhalla that include highway=trunk in 
the "Avoid Highways" option, under the assumption that this tag 
consistently indicates an expressway.

Sometimes breakage happens unintentionally. Several years ago, I and 
other mappers in the U.S. and Canada started using 
restriction=no_left/right_turn_on_red to indicate a turn-on-red 
restriction, which up to that point had no established tagging. [2] This 
*_on_red suffix briefly broke OSRM, which had been relying on an obscure 
clause that someone inserted into the restriction=* page stating that 
data consumers could ignore everything after the no_* or only_* prefix. 
Since turn-on-red restrictions are very common in downtown areas, these 
restrictions effectively made it impossible to route through these 
areas. Whoever added this clause to the wiki had good intentions for 
making OSM easier and more elegant to use, but data consumers noticed it 
before mappers did. Ironically, it was a premature optimization: OSRM 
ultimately required nothing more than a one-line change. [3]

To the extent that we care about both new and existing data consumers, 
we should strive to balance their disparate needs. One reason that 
dual-tagging grace periods last so long is that we don't have a very 
clear understanding of who all is using OSM and how, but we know of 
plenty of software that's still in use but no longer maintained. 
Software engineers refer to Hyrum's law [4] as shorthand for the fact 
that churning an API will always break someone, even for the silliest of 
reasons. [5]

Breaking changes are sometimes unavoidable, but there should be a 
convincing reason for the breakage when the stakes are high. Otherwise, 
the impact to OSM's reputation would be higher than any upfront 
messiness, which we already mitigate by providing a critical mass of 
data that you can't find anywhere else. Sometimes a convincing reason 
could be that the old tag is getting in the way of mapping things we 
want to map but can't express using existing tags. The 
crossing:markings=* proposal didn't deprecate crossing=* [6], but I 
think future proposals could chip away at crossing=*, as we find that 
there are more crossing configurations that we can't express using that 
key alone.

[1] https://wiki.openstreetmap.org/wiki/United_States/Highway_classification
[2] https://wiki.openstreetmap.org/wiki/No_turn_on_red
[3] https://github.com/Project-OSRM/osrm-backend/pull/4811
[4] https://www.hyrumslaw.com/
[5] https://xkcd.com/1172/
[6] https://wiki.openstreetmap.org/wiki/Proposed_features/crossing:markings

-- 
minh at nguyen.cincinnati.oh.us