secondary_entrance in JOSM und im Wiki?

+1. Passend, ausreichend, hinreichend, suffizient und perfekt …

Wo kommt denn das noch häufigere und auch undokumentierte main_entrance her?

Scheinbar auch von iD.

Ich habe mal einen bug report bei iD hinterlassen. (https://github.com/openstreetmap/iD/issues/7174)

Die berufen sich auf TagInfo - das sie offensichtlich selbst manipulieren.

Ich bin dafür, dass:

  • Ein Value für Nebeneingang eingeführt und im wiki dokumentiert wird. secondary erscheint mir passend.
  • die Sache per Massenedit zu bereinigen: secondary_entrance wird zu entrance=secondary, main_entrance wird zu entrance=main.

ich sehe es auch so, entrance=yes für Nebeneingänge, entrance=main für Haupteingänge

Also das (edit: deutsche) Wiki bei entrance=yes entsprechend anpassen?
Edit2: Und bei =service dann auch?

Hallo,

die Bedeutung eines key nachträglich ändern verursacht oft Folgeprobleme. ich würde yes für ‘nicht näher spzifiziert’ belassen und einen Nebeneingang ergänzend aufnehmen.

NEIN
(=yes ist ein (beliebiger/unbekannter) Eingang)
(
=service ist ein Eingang für Lieferung/Service)
=secondary ist ein (oder mehrere) Nebeneingänge → WIKI
(
=main ist einHaupteingang)

Würde ich befürworten - sehe aber das iD das nicht so sieht und sich nicht “belehren” lässt - wie schon seit Anfang an.

Die Entwickler von iD haben sich nochmal gemeldet und sie würden das schon anpassen. Ich da jetzt mal vorgeschlagen, anstelle von main_entrance und secondary_entrance nur entrance=main und =secondary anzubieten.

Die iD-Edits mit main_entrance und secondary_entrance muß man halt nacharbeiten.

Servus Wolfgang

Hallo,

ich habe da nochmal nachgeforscht:

iD reklamiert ja für sich, sie würden die taginfo-Werte nutzen und da halt die häufigsten Treffer im Menu anbieten. Eine overpass-Abfrage zeigt einen ausgeprägten Schwerpunkt in Cambridge (http://overpass-turbo.eu/s/PhI ), dort wurde dieser Tag-Value von User davidearl in den Jahren 2011 und 2012 zum mappen benutzt.

Sonst gibt es für entrance eigentlich nur yes/main/staircase und home (https://taginfo.openstreetmap.org/keys/entrance#values). Mittels der Auswahl in iD geht nun die Benutzung dieses Tag secondary_entrance (quasi über Bande der Neunutzer) langsam nach oben. Leider komplett ohne wiki, ohne Kenntnis der Renderer und anderen Edittools.

Was kann man daraus lernen:

  • secondary wird offensichtlich als value benötigt, sonst würden es die Nutzer nicht klicken.
  • Man muß iD klarmachen, dann man nicht einfach ‘über Bande’ seltene Tagwerte faktisch zu Norm macht, hier müßte iD eine Prüfung vorlagern (z.B. ob ein wiki-Eintrag vorliegt).

Wie kann man das noch einfangen?

  • man müßte secondary_entrance und secondary vereinheitlichen - ohne die Punkte jeweils einzeln anzusehen, wäre das ein mechanical edit. Die obigen Beiträge habe ich so verstanden, dass Übereinstimmung bei entrance=secondary zu finden ist.

Vorschlag fürs Wiki:

entrance secondary

Zusatzeingang eines Gebäudes oder eines umschlossenen Geländes. Der Eingang wird zusätzlich zum Haupteingang z.B. bei großem Besucherandrang benutzt.

Hallo opendcc, danke dass Du das Thema hier mal zur Sprache gebracht hast.

Du hast hier* nun im Deutschen wiki das “entrance=secondary” in der Tabelle hinzugefügt. Finde ich okay, aber ist das jetzt ein lokaler spezieller Erfassungsstil, oder eher global und sollte daher auch ins Englische wiki?

Bezüglich entrance=main_entrance vs. entrance=main habe ich eben mal paar rote Boxen in die wiki hinzugefügt, siehe:
https://wiki.openstreetmap.org/w/index.php?title=Key:entrance&diff=1938998&oldid=1907056
https://wiki.openstreetmap.org/w/index.php?title=DE:Key:entrance&diff=1938999&oldid=1938972
Falls das jemand überflüssig findet, dürfen diese Änderungen auch gerne wieder rückgängig gemacht werden.

Hallo,

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.

bei reinen Ausgängen finde ich den entrance-Schlüssel grundsätzlich unpassend. Exit wird schon über 16000 mal verwendet, https://taginfo.openstreetmap.org/search?q=exit

M.M.: ein Ausgang ist meist eine Tür - wie beim Eingang - und ein Ausgang kann im “Notfall” (entrance=exit) auch ein Eingang sein.

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.

Hallo,

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.

Hallo,

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.

ACK.

Wegen shop: Ich habe mal overpass gefragt: shop hat 1530 Treffer, Stichproben zeigen das oben skizzierte Bild: home/shop am gleichen Building.

Servus Wolfgang