[Tagging] iD presets

Martin Koppenhoefer dieterdreist at gmail.com
Fri Jun 22 11:44:25 UTC 2018


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 <bhousel at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180622/e2bfbcbf/attachment.html>


More information about the Tagging mailing list