Vào lúc 03:26 2022-11-06,
m...@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
--
m...@nguyen.cincinnati.oh.us
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
