<div dir='auto'><div><br><div class="gmail_extra"><br><div class="gmail_quote">On 31 Mar 2021 12:07 am, Hauke Stieler <mail@hauke-stieler.de> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi,
<br>
<br>
I have three points I want to talk about:
<br>
<br>
1. Multiple tags meaning the same is not a problem for software developers
<br>
2. OSM is not a pure database
<br>
3. Perfect databases do not and will never exist
<br>
<br>
<br>
1.)
<br>
I really share the thoughts of Roland Olbricht [0] about the fact that
<br>
multiple possible keys are one of the least difficult situations a programmer
<br>
will experience. In fact inconsistencies and deprecated things are the most
<br>
natural things we'll encounter, as he pointed out by interpreting the CAP
<br>
theorem on OSM.
<br>
<br>
Especially if someone uses OSM data, a software developer would probably first
<br>
do some filtering and transformation on the data before using them. This is
<br>
very common in the concept of data warehouses and is called an ETL process:
<br>
Extract from OSM -> Transform to consistent and desired schema -> Load into
<br>
your local DB.
<br>
The transformation step for example would merge "phone" with "contact:phone"
<br>
tags and is no rocket science at all.</p></blockquote></div></div></div><div dir="auto">That's right. Developers & Data Customers will likely also want to do it for infinity. But that reason is not the only one why we should minimize tagging fragmentation. We want newbies to contribute and to have a barrier-less entry. So they need it to be simple (luckily we have the iD editor) and a tool in the first place which gives newbies a template to hand to</div><div dir="auto">a) understand how data can be entered into the database in the format we specified and told them,</div><div dir="auto">b) they don't need to fiddle with correct tag finding and don't need to deep into the technical things behind OSM in the first place and</div><div dir="auto">c) last but not least templating is a way to bring the Mainstream to contribute (which is what Google does with business owners).</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
<br>
<br>
2.)
<br>
How I understand your viewpoint is, and please correct me if I'm wrong, that
<br>
you see OSM as a pure technical database that either is correct or wrong. And
<br>
we do in deed always say "OSM is a database" but I think that's only one half
<br>
of the truth.</p></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">You can speak about OSM in diverse ways. To say "OSM is a database (project)" is the half of truth as you pointed out.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
<br>
<br>
OSM is the whole project consisting of people, the wiki, our official
<br>
communication infrastructure, the servers and yes also the database. And
<br>
because we are not just one development team of six people, but a worldwide
<br>
community of six million people, there will never ever be complete
<br>
consistency. Neither in what we want to have as best-practices, or "standards"
<br>
if you will, nor in what we actually do.</p></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">But we should strike to standardize as good as possible to make data as useable as possible without abandoning the wonderful diversity of the world. Interestingly some more o less powerful OSM community members tend to turn against OSM African community. I see rejections from the community, Map Tile vendors and developers when it comes to supporting their tags they needed to invent because no existing one fit the definition there. Especially in the healthcare facility sector. So if we want diversity, let it come through us. It is possible to make data consistent without abandoning diversity. In many places OSM is already a good example in that field. It is easy to reflect cultural difference in OSM and data consistency must not confront that in any way.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
<br>
<br>
This leads to a database, a wiki, an infrastructure that grows organically
<br>
because there's not the one central authority who defines tagging schemes and
<br>
who bans/punishes people who do not stick to that official scheme. I think
<br>
none of us wants this central authority and I also think our proposal process
<br>
and discussion culture is pretty good. Not perfect but good and it works so
<br>
far.</p></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">It "would" work if we listen to more diverse opinions and expertise. Mappers could listen more to developers, database developers, scientists, UX/UI designers etc. and of course vice versa. But currently mappers tend to think that they are the "king", are "experts" in all these fields, don't need to listen to others because they think that is "their" projects, "their" house and don't need to bother about diverse opinions.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
<br>
<br>
And that's the point: This heterogeneous, decentralized, unsupervised and
<br>
democratic community will never ever completely and perfectly stick to the
<br>
approved and best-practice tags. There will always be someone who tags a thing
<br>
not using an approved tag (or maybe even using a deprecated one).
<br>
<br>
Of course it's not a good idea to not stick to the mainstream approved best-
<br>
practice tags, but that's how OSM works. That's why we are an open community
<br>
and not a company with managers, supervisors, payment bonuses, consultants,
<br>
etc.: We are free in what we do. Furthermore every single one of us is free in
<br>
what she/he does.
<br>
<br>
IMHO [1]: A restriction of this freedom is in direct conflict of what OSM is
<br>
all about and must be avoided.</p></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I love freedom but we need rules and we have already rules like "map the ground truth". Total freedom is also surreal and would lead to nothing successful.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
<br>
<br>
3.)
<br>
This directly leads me to the point that perfect databases don't exist and
<br>
will never ever exist. Not even companies have perfect databases. Whenever I
<br>
hear stories of my working colleagues about databases, all of them are horror
<br>
stories. I myself already saw a lot of bad databases out there (also bad geo-
<br>
databases). So even a more strict and centralized organization is not capable
<br>
of creating perfect (or nearly perfect) databases.</p></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I never spoke about wanting to have a "perfect database" and never intended to have such a surreal thing. In my database/programming lessons the first thing I learnt was "try to transfer the real world/thing/subject to a virtual representation of it as good as possible with reasonable amount of work (think economically) but don't try to make the 'perfect scheme' because you'll never make it then".</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
<br>
<br>
Even the databases of the projects I work in aren't perfect. Maybe good or
<br>
"okay" but not perfect at all. Why? Because of the same reason as above:
<br>
Databases and the data in them grow organically. The scheme of the database
<br>
and the data changes over time resulting in deprecated values, obsolete naming
<br>
conventions, missing data, etc. Also there are always workmates with different
<br>
opinions about the perfect/ideal database.
<br>
<br>
Yes, there are best practices and widely used successful techniques, okay. But
<br>
sometimes, based on the situation and/or experience of a developer, there are
<br>
good arguments against these best practices leading to different opinions
<br>
about them. Therefore saying that a certain approach, an argument, an opinion
<br>
or a preference is "wrong" is in turn wrong and should IMHO be avoided.
<br>
<br>
Hence building a perfect database/tag/schema/... without imperfections and
<br>
being happy until eternity is simply an impossibility, sorry.
<br>
<br>
<br>
<br>
Probably the best way how a community should approach the problems of
<br>
deprecated tags is to do more QA (quality assurance), then contact the user
<br>
who added the deprecated tag, teach the user about the deprecation and of
<br>
course present alternative tags. I know that not everybody reacts to changeset
<br>
comments or messages on osm.org, but if the message is nice and friendly most
<br>
people will answer (my experience so far). And as far as I see the diaper tag
<br>
situation, a non-restrictive approach worked quite well, didn't it?</p></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I and others do exactly that already and will continue to do that also in future independent from the success/failure of this proposal.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
<br>
<br>
That's my opinion about all this.
<br>
<br>
<br>
Hauke
<br>
<br>
<br>
[0] https://lists.openstreetmap.org/pipermail/talk/2021-March/086327.html
<br>
[1] IMHO: in my humble opinion
<br>
</p></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I never wanted to restrict others in what they tag but entering unusable data into the database won't help anybody. Unsuable data turns out when someone</div><div dir="auto">- use a deprecated tag no one knows about and won't interpret/understand</div><div dir="auto">- use an undocumented tag no one knows what it is for and therefore cannot interpret/understand/use it and</div><div dir="auto">- and don't stick to the "way of tagging a certain thing" we agreed on. E.g. I saw not less people tagging unofficial Facebook pages (Facebook flagged them as such).</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>
<br>
Am Montag, 15. März 2021, 14:58:06 CEST schrieb Sören Reinecke via talk:
<br>
> Hello all,
<br>
>
<br>
> I see on the wiki sometimes the following message above wiki pages
<br>
> describing deprecated tags/keys:
<br>
>
<br>
>
<br>
> This feature has been labeled as deprecated. The recommended replacement is:
<br>
> changing_table=*. The reason is documented in Deprecated features. You are
<br>
> still free to continue to use or interpret this tag as you see fit since
<br>
> OpenStreetMap does not have “banned features”. Under no circumstances
<br>
> should you (semi-)automatically change “deprecated” tags to something else
<br>
> in the database on a large scale without conforming to the Automated Edits
<br>
> code of conduct. Any such change will be reverted.
<br>
>
<br>
>
<br>
>
<br>
> I have objections on the part that OSM does not have a banned feature.
<br>
> OSM is a database and when it comes to that, there are rules.One of these
<br>
> rules is preventing data reluctance. In the example of deprecation of
<br>
> Key:diaper in order to push the much much better Key:changing_table forward
<br>
> we recommend mappers not to use the first key but the last key. In the same
<br>
> box we also see that the mapper can also use the old Key:diaper tag. Well,
<br>
> did you thought about the nonsense? Because developers will only support
<br>
> Key:changing_table and not the Key:diaper because we stick to standards and
<br>
> all others who do not will fail. It would be complete nonsense to map
<br>
> Key:diaper because no data customer will process that key, nor will convert
<br>
> it to something usable. So that entry ends up in the database for nothing
<br>
> and no other mapper will understand what the key is all about.
<br>
>
<br>
> Refering to "Deprecated features" wiki page (to cover Key:contact:phone vs
<br>
> Key:phone example): "Often expressed opinion is that in case of two tags
<br>
> with exactly the same meaning deprecating one and retagging objects is
<br>
> waste of time and energy and disturbs mapping for no benefit." - This
<br>
> opinion wrong and probably come from those not understanding databases.
<br>
> Deprecation in case two tags have exactly the same meaning is good and is
<br>
> an improvement to the database. And it is also clearer for newbies to
<br>
> decide whether to use tag A or B. For data customers it is also easier
<br>
> because they don't need to support two schemes meaning exactly the same. An
<br>
> example: Key:contact:phone and Key:phone where I had discussions with
<br>
> people not understanding databases and ignoring my expertise. I study these
<br>
> things btw. "Often expressed opinion is that in such case of tags with the
<br>
> same meaning one should be quickly deprecated"- The word "quickly"
<br>
> shouldn't be used here. Also deprecation of a duplicate tag should be done
<br>
> with care. Quick might be your wrong partner there. So people saying that,
<br>
> please reconsider your way of thinking. A "banned feature" would be useful
<br>
> here (in case of the phone thing) since two keys in use at the same time
<br>
> meaning exactly the same. We then could ban the use of Key:phone or
<br>
> Key:contact:phone and doing a duty to our database.
<br>
>
<br>
>
<br>
> So yes, we should ban certain features in favor of newer and better schemes
<br>
> and where possible automatically/manually convert these to the newer ones
<br>
> to keep the database clean and the information conveyed in these deprecated
<br>
> keys being useful still. Cheers
<br>
> Sören Reinecke alias Valor Naram</p>
</blockquote></div><br></div></div></div>