Hey Christoph - You make some really interesting points in your email. Rather than replying point by point, I’m going to pick out a few phrases that stood out.
It sounds like I need to do a better job of explaining... 👨🏫 “How a tag becomes a preset in iD” First - and this is something that a lot of people seem misinformed about - I mostly don’t add the presets to iD. Check out the iD changelog going back several releases and you can see all the preset work that we’ve done: https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#whats-new <https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#whats-new> We are very proud of the changelog. I try to make this document the sort of thing that anybody can read. When new releases of iD are pushed out, users can even see a small 🎁 icon in the corner of iD that links to our changelog. iD is an open source project that anybody can follow, but I make it a point to share our successes, and give shoutouts to our contributors. (If an item does not have a “thanks”, it means I did it.) Each new release in the changelog has a section for “Presets”. And almost all of those items have links to GitHub issues and pull requests which close them. You should click through and read some - some things that may surprise you: 1. Most of the people proposing the presets are not me. 2. Most of the people implementing the presets are also not me. 3. I mostly just accept anything that anybody asks for. 4. Every month we add or improve between a handful and a few dozen presets. A lot of people contribute presets to iD. It’s actually really easy to do (just add some .json files), and a great task for a first time open source contributor. So you said... > This is IMO - no matter who has this control - in > conflict with the fundamental ideas of OSM, that mappers mapping things > decide on how to tag things, not the developers of tools used for > mapping. As I see it, the users of iD and the community are deciding which presets get included. I might recommend a change in what the display name should be, or what icon it should have, but I almost never tell someone that they can’t add a preset or field (some examples coming up next). > If i read you correctly you are unwilling to.. > * establish verifiable principles for decisions about tagging presets in > iD that limit use of presets to push subjectively preferred tagging > ideas against existing widely accepted practice. Great segue! 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. 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. 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. Related to being understood everywhere, I try to make sure every preset has a short description (that fits in about 300px) and a nice icon. It should also have a decent page on the OSM wiki, because we pull help content from there. 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. 5. Don’t put too many fields on a preset. We run into this with `amenity=bar` preset but several others too. People want fields for the kind of beers there, and whether they have outdoor seating, and whether they offer takeout, and what the wifi password is, and so on. So sometimes we have to just cut it off and say “there are too many fields”. We have an issue <https://github.com/openstreetmap/iD/issues/4871> for changing how we specify extra fields, and we will probably soon add the ability for each preset to have its own “More fields” list. 6. Don’t add a preset for an extremely rare thing. Seems self explanatory - this is why I said in my previous email that I probably wouldn’t add a preset for the “office building where lifeguard paperwork happens”. However a rarely used tag for a common real world feature (like "actual locations where lifeguards are") is probably worth adding a preset, even if the tag hasn’t caught on yet. 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. - This also happened with a recent power proposal <https://github.com/openstreetmap/iD/issues/4441> where they wanted `power=pole + switch=*` to mean “a pole with a switch on it” and `power=switch` to mean “a switch without a pole”. Technically we really can’t use the `switch` tag as both a standalone tag and a subtag on something else (without making a new preset like “Pole With A Switch”), so I had to say “no” to that part of the proposal (we still implemented most of it). - Relations are hard in iD. They all require special support in the code (more than just what a preset can provide) - Sometimes we have to say no to presets like `transit:lanes` because the tag itself is just easily breakable (plenty of discussion in other emails about this one). If it sounds like a lot of rules, it’s really just about balancing the needs of the first time user who doesn’t know anything, and the expert mapper who wants to add a lot of whatever interests them. (In general, I think people should be allowed to add almost whatever they want to OpenStreetMap). > * 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). > * 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. We could start an entirely separate thread about designing tags. This message already went pretty deep into how we decide which tags become editor presets, so it doesn’t make sense to dig deep into the tagging here. Thanks for listening! Bryan
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
