im englischen Wiki sollte das natürlich auch erscheinen, ich habe dort auch einen Update hinterlassen - bitte verbessern.
Die iD Leute haben sich nochmal gemeldet - sie würden eine redigierte Valueliste auch nutzen (machen sie wohl auch schon bei anderen Tags), muß man ihnen halt zuliefern. Und sie wiesen (zu Recht) darauf hin, dass zu statische Values OSM festfrieren lassen. Aber wie oben schon dargelegt, das aktuelle Verhalten von iD zerstört das Tagging.
Highlight bei entrance: iD bietet auch entrance=no an. Ich habe ein Beispiel gefunden, wo entrance=no, exit=yes, name=Ausgang getagged war. imho ist entrance=exit korrekt.
im Notfall kann alles mögliche passieren, so kann auch ein Kamin, ein Fenster oder eine andere Öffnung zum Eingang oder Ausgang werden. Es gibt aber auch Ausgänge die technisch so ausgebildet sind, dass man sie nur als Ausgänge nutzen kann. Ein Eingang oder Ausgang impliziert nicht grundsätzlich eine Tür, das kommt u.A. aufs Klima an.
entrance beschreibt, dass da ein Loch in der Wand ist. Sprachlich wird das aber oft mit Nummer oder Access verwurstelt: entrance=3b, entrance=private oder entrance=Lehrerzimmer. Und sobald iD da eine Häufung (und sei sie auch nur 0.03%) findet, bietet iD das im Menu an. Und so breitet sich das fehlerhafte Mapping aus.
Taginfo liefert über 800 verscheidene Werte für entrance, wir sollten versuchen, dass etwas zu reduzieren.
Eine mögliche Auswahl:
yes | main | secondary | staircase | home | service | delivery | garage | emergency | exit | shop | fire_exit
Weniger Tagwerte würden den Auswertern helfen und auch Fragen von Einsteiger reduzieren: “ich habe main_entrance getaggt, warum sehe ich das nicht?”
Für “delivery” sollte das etablierte und dokumentierte “service” verwendet werden, für “fire_exit” aus denselben Gründen “emergency”.
Abgesehen davon sollte der Wert von entrance nicht dazu verwendet werden, zu mappen, wohin der Eingang führt – wie unterscheidet man sonst Haupt- und Nebeneingang eines Ladens? Daher sollten die Werte shop und garage (und eigentlich auch home, aber das steht im Wiki) nicht empfohlen werden.
ich hätte schon einen Unterschied zwischen delivery (also z.B. der Anliefereingang einer Küche / einer Fertigung) und Service (z.B. Personaleingang) gesehen. fire_exit und emergency halte ich auch für ident - und da es emergency schon gibt und beschrieben ist, sollte das empfohlen werden.
Da stimme ich prinzipiell zu, aber Stadthäuser haben oft unten einen Laden und darüber Wohnungen: das sind zwei Eingänge mit identischer Adresse an der Gebäudefront - der Wohnungseingang ist dann meist seitlich an der Hausfront.
Es wäre zwar genauso gut denkbar, hier getrennte Werte zu nutzen, aber service ist im Wiki ausdrücklich für beides gedacht (“for employees or for delivering”). Und da service in dieser Definition auch Teil des abgestimmten Proposals war, würde ich mich daran halten.
Für solche Fälle (im Gegensatz zu reinen Wohngebäuden) ist “home” schon sinnvoll, ein zusätzliches “shop” braucht es in der Werteliste aus meiner Sicht aber nicht.