<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">I really welcome this discussion about these procedures, and the participation of Bryan. It is clear that any more rules or policies mean more work and less time for the fun things, and a slow down in development in general, but I feel it is important to have many eyes on this process, because it is at the core of our project (tags are everything when it comes to the meaning of things in the database). To keep it short, I have not commented on everything.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">2018-06-21 4:39 GMT+02:00 Bryan Housel <span dir="ltr"><<a href="mailto:bhousel@gmail.com" target="_blank">bhousel@gmail.com</a>></span>:<br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div><br><div></div><div>We should list out the <i>“principles for decisions about tagging presets in iD"</i></div><div><br></div><div><b>1. It should be something that an untrained user can figure out.</b></div><div><i>This is really the most important rule</i> - it's why<a href="https://github.com/openstreetmap/iD/pull/3600" target="_blank"> I said “no"</a> to biology fields like `taxon` or `genus` to the Tree presets.  You'd need to be a botanist to fill these correctly, so having these fields in iD would more likely lead to people inputting bad data than good data.  Same reason I <a href="https://github.com/openstreetmap/iD/issues/4057" target="_blank">also said “no”</a> to adding `bic` field to the Bank preset, and <a href="https://github.com/openstreetmap/iD/issues/3439" target="_blank">said “no”</a> to `ref:vatin` for businesses.</div></div></div></div></blockquote><div><br></div><div><br></div><div>for trees, there is the possibility to add localized taxons, e.g. species:en=oak (which is not a species actually, but it works, if you prefer, you can use taxon:en=oak). You do not need to be a botanist to recognize an oak.</div><div><a href="https://taginfo.openstreetmap.org/keys/species%3Aen">https://taginfo.openstreetmap.org/keys/species%3Aen</a> This is a tag with 117.000 uses, not a rare specialist tag.</div><div>ref:vatin is a tag that everybody can enter, who can read a receipt at a shop (although the tag name sounds hostile and like a specialist tag, admittedly), I would expect it more difficult to for people to recognize a motorroad or a turn restriction, especially if they do not have a driving license.</div><div>Clearly, you need training to understand traffic signs? <br></div><div><br></div><div>We must be careful when assuming what is "common knowledge" and what is not, because this completely depends on the cultural context.</div><div><a href="https://i.imgur.com/tn5zKKP.jpg">https://i.imgur.com/tn5zKKP.jpg</a><br></div><div><br></div><div>IMHO this boils down to a subjective criterion where things can be dismissed as "an untrained user cannot figure it out" when it suits personal preferences, while other "same complexity / specificity" things are in the presets for years.<br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div><div><br></div><div><b>2. There should be ideally only one preset for a thing.</b></div><div>It happens sometimes that there are two ways to tag something (`natural=wood` vs `landcover=trees`?)  In this case we would probably just go with the most common one.  Sometimes we go with a newer less established tag if it is possible to also put the legacy tag alongside the new tag (this is the case with most of the PTv2 or healthcare presets).  Users get very confused by the difference between `amenity=place_of_worship` and `building=place_of_worship`.  We try to give them cues in the rendering (all buildings render a certain way) and the preset text.</div></div></div></div></blockquote><div><br></div><div><br></div><div><br></div><div>there are no such things as "a thing", it is all about interpretation. The same "thing" can be one thing, part of a thing, or lots of things. It all depends on your perspective. It is the tags that define what is a "thing".<br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div><div><br></div><div><b>3. Presets should be mostly understood everywhere.</b></div><div>This is because iD is used everywhere and translated into dozens of languages.  There are a few things that don’t translate well, and these tend to be more hyper specific kinds of tags.  For example, we didn’t add a preset for `memorial=stolperstein`, since this is not a concept that is everywhere.  Instead we added that word to the existing `historical=memorial` preset as a search term, and we provided a dropdown field so that users can easily add these.  </div></div></div></div></blockquote><div><br></div><div><br></div><div><br></div><div>I believe translations are among the most crucial aspects when it comes to deciding the right tags. It is already near impossible to convey the sometimes subtle differences of different tags in English, even more in those dozens of languages. <br></div><div><br></div><div><br></div><div>Ideally, applying tags in an editor like iD, which aims to make things simple and without the mapper having to bother about the meaning and definitions of tags, should be a guided procedure. It is impossible to do it right with just one word!</div><div><br></div><div>The search should be just the first step, but would be followed by domain specific questions.</div><div><br></div><div>To give an example (adhoc, probably not thought through): <br></div><div>user types in "church", the questions would go:</div><div>1. is it an active church (-> add place of worship or not)</div><div>2. what is the denomination (drop down list + free form field)</div><div>3. do you know the opening hours and service times? (-> convenient, simple, specialized sub-editor for selecting the hours)<br></div><div>4. what is the type of building (chapel / church / cathedral / no building / part of a building)</div><div>or</div><div>4a. is it: part of a building / an entire building / no building</div><div>4b. (if it is an entire building): select church / catherdral / (maybe also chapel).<br></div><div></div><div><br></div><div><br></div><div>Generally, the shortest definition (e.g. "description" from the wiki tag templates) should be shown for the tags, not just one word.</div><div><br></div><div><br></div><div><br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div><div><br></div><div><b>4. Don’t overwhelm with too many options.</b></div><div>There are 100s of kinds of vending machines but we only have dedicated presets for about the 20 most popular kinds.</div></div></div></div></blockquote><div><br></div><div><br></div><div><br></div><div>again, this could be solved by having a guided procedure, which narrows the list of options down by asking a few domain specific questions. <br></div><div><br></div>...</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div><div><br></div><div><div><b>7. There are some technical limitations…</b></div><div>This is the item that people probably hate on me the most.  </div><div>- If a tag is used for different things, it can cause problems.  This was <a href="https://github.com/openstreetmap/iD/issues/5008" target="_blank">an issue</a> with `service=*` being used for both a kind of a road, and a detail about auto services.  </div></div></div></div></div></blockquote><div><br></div><div><br></div><div>it is also used for railway line types, so the conflict is there nonetheless. How did you solve it for railway/highway?<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div><span class="gmail-"><div></div><blockquote type="cite"><div><div>* modify iD to allow for more diversity in tagging presets used by <br>mappers (for example by offering presets available in JOSM as an <br>alternative).<br></div></div></blockquote><div><br></div></span><div>Good news - iD already allows anyone to replace the presets.  You could make an iD that contains just presets for HOT mapping, for example.  People are doing this already, but it requires making a copy of iD and hosting it somewhere.  This will change soon:  we have an <a href="https://github.com/openstreetmap/iD/issues/5049" target="_blank">open issue</a> to allow preset replacement at runtime via a .json file (an request that came out of our recent OSM-US hackathon, and HOT wants this too).</div></div></div></div></blockquote><div><br></div><div><br></div><div>while this is great in principle, I believe it should be way easier. Yes, iD is open software and everybody can re-use it, but we are discussing the situation for the official, OSMF deployed, iD instance to which you get by default when you click "edit" on the OSM map. This is the editor a lot of people use, especially those that contribute occassionally, and that are not interested in or looking at tags. Experienced mappers can already use the "all tags" sections and control and modify tags as the like.<br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div><span class="gmail-"><div></div><div></div><blockquote type="cite"><div>* refrain from connecting tagging discussions you start here to iD <br>preset decisions - including use of your decision power as leverage in <br>discourse, like with</div></blockquote><div><br></div></span><div>I actually think being <b><i>more</i></b> involved in tagging discussions here is probably the solution to educating mappers about how to design tags in a way that is easier for software (and users) to work with.</div></div></div></div></blockquote><div><br></div><div><br></div><div>+1, to both of you, educating mappers to invent good tags is important, refraining from leveraging the iD maintainer power to influence tagging discussions is fundamental (or people will dismiss this as fake openness, in the end, why contribute to a discussion, if the decision has already been made).<br></div><div><br></div><div><br></div><div>Cheers,</div><div>Martin<br></div><div><br></div><div><br></div><div><br></div></div></div></div>