[OSM-talk] You are still free to continue to use or interpret this tag as you see fit since OpenStreetMap does not have “banned features”
mail at hauke-stieler.de
Tue Mar 30 22:07:09 UTC 2021
I have three points I want to talk about:
1. Multiple tags meaning the same is not a problem for software developers
2. OSM is not a pure database
3. Perfect databases do not and will never exist
I really share the thoughts of Roland Olbricht  about the fact that
multiple possible keys are one of the least difficult situations a programmer
will experience. In fact inconsistencies and deprecated things are the most
natural things we'll encounter, as he pointed out by interpreting the CAP
theorem on OSM.
Especially if someone uses OSM data, a software developer would probably first
do some filtering and transformation on the data before using them. This is
very common in the concept of data warehouses and is called an ETL process:
Extract from OSM -> Transform to consistent and desired schema -> Load into
your local DB.
The transformation step for example would merge "phone" with "contact:phone"
tags and is no rocket science at all.
How I understand your viewpoint is, and please correct me if I'm wrong, that
you see OSM as a pure technical database that either is correct or wrong. And
we do in deed always say "OSM is a database" but I think that's only one half
of the truth.
OSM is the whole project consisting of people, the wiki, our official
communication infrastructure, the servers and yes also the database. And
because we are not just one development team of six people, but a worldwide
community of six million people, there will never ever be complete
consistency. Neither in what we want to have as best-practices, or "standards"
if you will, nor in what we actually do.
This leads to a database, a wiki, an infrastructure that grows organically
because there's not the one central authority who defines tagging schemes and
who bans/punishes people who do not stick to that official scheme. I think
none of us wants this central authority and I also think our proposal process
and discussion culture is pretty good. Not perfect but good and it works so
And that's the point: This heterogeneous, decentralized, unsupervised and
democratic community will never ever completely and perfectly stick to the
approved and best-practice tags. There will always be someone who tags a thing
not using an approved tag (or maybe even using a deprecated one).
Of course it's not a good idea to not stick to the mainstream approved best-
practice tags, but that's how OSM works. That's why we are an open community
and not a company with managers, supervisors, payment bonuses, consultants,
etc.: We are free in what we do. Furthermore every single one of us is free in
what she/he does.
IMHO : A restriction of this freedom is in direct conflict of what OSM is
all about and must be avoided.
This directly leads me to the point that perfect databases don't exist and
will never ever exist. Not even companies have perfect databases. Whenever I
hear stories of my working colleagues about databases, all of them are horror
stories. I myself already saw a lot of bad databases out there (also bad geo-
databases). So even a more strict and centralized organization is not capable
of creating perfect (or nearly perfect) databases.
Even the databases of the projects I work in aren't perfect. Maybe good or
"okay" but not perfect at all. Why? Because of the same reason as above:
Databases and the data in them grow organically. The scheme of the database
and the data changes over time resulting in deprecated values, obsolete naming
conventions, missing data, etc. Also there are always workmates with different
opinions about the perfect/ideal database.
Yes, there are best practices and widely used successful techniques, okay. But
sometimes, based on the situation and/or experience of a developer, there are
good arguments against these best practices leading to different opinions
about them. Therefore saying that a certain approach, an argument, an opinion
or a preference is "wrong" is in turn wrong and should IMHO be avoided.
Hence building a perfect database/tag/schema/... without imperfections and
being happy until eternity is simply an impossibility, sorry.
Probably the best way how a community should approach the problems of
deprecated tags is to do more QA (quality assurance), then contact the user
who added the deprecated tag, teach the user about the deprecation and of
course present alternative tags. I know that not everybody reacts to changeset
comments or messages on osm.org, but if the message is nice and friendly most
people will answer (my experience so far). And as far as I see the diaper tag
situation, a non-restrictive approach worked quite well, didn't it?
That's my opinion about all this.
 IMHO: in my humble opinion
Am Montag, 15. März 2021, 14:58:06 CEST schrieb Sören Reinecke via talk:
> Hello all,
> I see on the wiki sometimes the following message above wiki pages
> describing deprecated tags/keys:
> This feature has been labeled as deprecated. The recommended replacement is:
> changing_table=*. The reason is documented in Deprecated features. You are
> still free to continue to use or interpret this tag as you see fit since
> OpenStreetMap does not have “banned features”. Under no circumstances
> should you (semi-)automatically change “deprecated” tags to something else
> in the database on a large scale without conforming to the Automated Edits
> code of conduct. Any such change will be reverted.
> I have objections on the part that OSM does not have a banned feature.
> OSM is a database and when it comes to that, there are rules.One of these
> rules is preventing data reluctance. In the example of deprecation of
> Key:diaper in order to push the much much better Key:changing_table forward
> we recommend mappers not to use the first key but the last key. In the same
> box we also see that the mapper can also use the old Key:diaper tag. Well,
> did you thought about the nonsense? Because developers will only support
> Key:changing_table and not the Key:diaper because we stick to standards and
> all others who do not will fail. It would be complete nonsense to map
> Key:diaper because no data customer will process that key, nor will convert
> it to something usable. So that entry ends up in the database for nothing
> and no other mapper will understand what the key is all about.
> Refering to "Deprecated features" wiki page (to cover Key:contact:phone vs
> Key:phone example): "Often expressed opinion is that in case of two tags
> with exactly the same meaning deprecating one and retagging objects is
> waste of time and energy and disturbs mapping for no benefit." - This
> opinion wrong and probably come from those not understanding databases.
> Deprecation in case two tags have exactly the same meaning is good and is
> an improvement to the database. And it is also clearer for newbies to
> decide whether to use tag A or B. For data customers it is also easier
> because they don't need to support two schemes meaning exactly the same. An
> example: Key:contact:phone and Key:phone where I had discussions with
> people not understanding databases and ignoring my expertise. I study these
> things btw. "Often expressed opinion is that in such case of tags with the
> same meaning one should be quickly deprecated"- The word "quickly"
> shouldn't be used here. Also deprecation of a duplicate tag should be done
> with care. Quick might be your wrong partner there. So people saying that,
> please reconsider your way of thinking. A "banned feature" would be useful
> here (in case of the phone thing) since two keys in use at the same time
> meaning exactly the same. We then could ban the use of Key:phone or
> Key:contact:phone and doing a duty to our database.
> So yes, we should ban certain features in favor of newer and better schemes
> and where possible automatically/manually convert these to the newer ones
> to keep the database clean and the information conveyed in these deprecated
> keys being useful still. Cheers
> Sören Reinecke alias Valor Naram
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the talk