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.
2018-06-21 4:39 GMT+02:00 Bryan Housel <bhou...@gmail.com>: > > We should list out the *“principles for decisions about tagging presets > in iD"* > > *1. It should be something that an untrained user can figure out.* > *This is really the most important rule* - it's why I said “no" > <https://github.com/openstreetmap/iD/pull/3600> 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 also said “no” > <https://github.com/openstreetmap/iD/issues/4057> to adding `bic` field > to the Bank preset, and said “no” > <https://github.com/openstreetmap/iD/issues/3439> to `ref:vatin` for > businesses. > 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. https://taginfo.openstreetmap.org/keys/species%3Aen This is a tag with 117.000 uses, not a rare specialist tag. 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. Clearly, you need training to understand traffic signs? We must be careful when assuming what is "common knowledge" and what is not, because this completely depends on the cultural context. https://i.imgur.com/tn5zKKP.jpg 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. > > *2. There should be ideally only one preset for a thing.* > 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. > 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". > > *3. Presets should be mostly understood everywhere.* > 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. > 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. 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! The search should be just the first step, but would be followed by domain specific questions. To give an example (adhoc, probably not thought through): user types in "church", the questions would go: 1. is it an active church (-> add place of worship or not) 2. what is the denomination (drop down list + free form field) 3. do you know the opening hours and service times? (-> convenient, simple, specialized sub-editor for selecting the hours) 4. what is the type of building (chapel / church / cathedral / no building / part of a building) or 4a. is it: part of a building / an entire building / no building 4b. (if it is an entire building): select church / catherdral / (maybe also chapel). Generally, the shortest definition (e.g. "description" from the wiki tag templates) should be shown for the tags, not just one word. > *4. Don’t overwhelm with too many options.* > There are 100s of kinds of vending machines but we only have dedicated > presets for about the 20 most popular kinds. > again, this could be solved by having a guided procedure, which narrows the list of options down by asking a few domain specific questions. ... > *7. There are some technical limitations…* > This is the item that people probably hate on me the most. > - If a tag is used for different things, it can cause problems. This was an > issue <https://github.com/openstreetmap/iD/issues/5008> with `service=*` > being used for both a kind of a road, and a detail about auto services. > it is also used for railway line types, so the conflict is there nonetheless. How did you solve it for railway/highway? * modify iD to allow for more diversity in tagging presets used by > mappers (for example by offering presets available in JOSM as an > alternative). > > > 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 open issue > <https://github.com/openstreetmap/iD/issues/5049> 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). > 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. > * refrain from connecting tagging discussions you start here to iD > preset decisions - including use of your decision power as leverage in > discourse, like with > > > I actually think being *more* 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. > +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). Cheers, Martin
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
