[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”

Hauke Stieler mail at hauke-stieler.de
Tue Mar 30 22:07:09 UTC 2021


Hi,

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


1.)
I really share the thoughts of Roland Olbricht [0] 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.

2.)
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 
far.

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 [1]: A restriction of this freedom is in direct conflict of what OSM is 
all about and must be avoided.

3.)
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.


Hauke


[0] https://lists.openstreetmap.org/pipermail/talk/2021-March/086327.html
[1] 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...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20210331/6d329d86/attachment-0001.sig>


More information about the talk mailing list