Adressangaben am Eingang - oder?

Wenn ich den dort Wohnenden besuchen will führt mich das bei der Adresse am Hausumriss bei allen Routern an eine eventuell falsche Stelle - auch wenn entrance vorhanden ist, da die Adresse als Punkt in der Fläche errechnet wird. So war es bis vor einiger Zeit z.B. hier:

http://www.openstreetmap.org/directions?engine=osrm_car&route=50.95376%2C13.96261%3B50.95271%2C13.95950#map=19/50.95238/13.96016

Als Besucher möchte ich dort hin, wo man mir Einlass gewährt - entrance=main. Ist dieser (Punkt eingetragen) mit der Adresse versehen kommt man auch an:

http://www.openstreetmap.org/directions?engine=osrm_car&route=50.95376%2C13.96261%3B50.95278%2C13.95952#map=18/50.95317/13.96107

Auch bin ich der Meinung ich verbiege damit keine Daten, wenn ich “einfache Daten” auch “einfach auswertbar” eintrage ohne diese erst aus Berechnungen ermitteln zu müssen. Denn überall ist gefordert die Hausnummer gut sichtbar in der Nähe des Zuganges anzubringen und die Hausnummer ist Bestandteil der Adresse.

Erfolgreiches 2018 …

Was man natürlich ehrlich gesagt auch bei der ganzen Adresse an Eingang taggen nicht unterschlagen dürfen ist die Tatsache, dass das erst dann richtig Sinn macht, wenn man auch entsprechende highway=path/footway was auch immer bis zu dieser Stelle führt, erst dann nämlich ist (zumindest bei Fuss) ein Haustür zu Haustür Routing überhaupt möglich.

Ganz wichtig: Der Knoten mit der Adresse muss exakt dahin wo das Täfelchen ist! Und nicht 1 Meter links über die Haustüre! Wenn schon “on the ground” dann richtig. :stuck_out_tongue: …und auch nicht dahin wo der Briefkasten ist! Den soll der Postbote schon selber suchen… :laughing:

Ich will an der Stelle einfach nochmals für Adresse auf Gebäude werben und dann die Eingänge mit passenden Infos zu versehen.

  • Es gibt Gebäude (auch laut Kataster nur ein Gebäude) die tatsächlich mehrere Eingänge/Hausnummern haben. Da gibt es keine andere Möglichkeit als die Adresse auf die Knoten zu legen.

  • *building:part… Das zu benutzen, da vor kann ich nur warnen! * Das wird hauptsächlich für das 3D-Gebäude-Mapping benutzt. Und wenn ich mich nicht täusche ist es auch nur dafür gemacht. Einen Zusammenhang mit irgend welchen Hausnummern gibt es da nicht. Völlig ungeeignet, Finger weg.

  • @Simon Poole: Es soll ja hier nicht darum gehen wo das Täfelchen angebracht ist! Es muss sinnvoll sein was das auch immer in anderen Ländern bedeutet…

  • Die Argumentation, die Nummer dorthin zu machen wo der Postbote hin muss ist mappen für den Renderer. Der Briefkasten muss nicht dort sein, wo die Hausnummer steht usw….

  • Die meisten Router schicken einem so nahe wie möglich zur “Adresse/Hausnummer”. Ist Hausnummer ein Knoten sehr nahe an der Straße dann funktioniert das sehr zuverlässig. Es gibt auch Häuser deren Haupteingang auf der Rückseite vom Gebäude ist… In jedem Fall ist das Mappen für den Router!

  • Von stupiden umtaggen von Vorhandenem… Haben sonst nichts mehr zu tun? Immerhin ist dort schon eine Adresse vorhanden. Lieber sich um den Rest kümmern!

Ich nutze da unterschiedliche Mapping-Varianten, je nach Situation:

  1. Die Hausnummer gilt für das gesamte Gebäude (Beispiel). In solchen Fällen packe ich die Adress-Tags an den Gebäude-Umriss, zeichne den Eingang (bzw. die Eingänge) ein und kennzeichne diese mit entrance=yes/main/delivery/pipapo.

  2. Das Gebäude hat mehrere Hausnummern.

2a) In einem Gebäude mit mehreren Hausnummern hat jede Hausnummer genau einen Eingang, und es gibt keine weiteren POIs im Gebäude. (Beispiel). In solchen Fällen packe ich die Adress-Tags an die Eingänge und kennzeichne diese zusätzlich mit entrance=yes/main/delivery/pipapo.

2b) In einem Gebäude mit mehreren Hausnummern gibt es mehrere Eingänge pro Hausnummer und / oder die Hausnummern gelten auch für Geschäfte oder andere POIs im Gebäude (Beispiel). Um ein mehrfaches Tagging derselben Hausnummer zu vermeiden, packe ich in solchen Fällen die Adress-Tags an einen separaten Node, den ich ins Gebäude pflanze. Ich zeichne sämtliche Eingänge ein und kennzeichne diese mit entrance=yes/main/delivery/pipapo, außerdem zeichne ich natürlich auch alle anderen POIs im Gebäude ein.

Ich sehe es wie Streckenkundler (#25), Gppes (#39) und der-martin (#43); es gibt Fälle, in denen die Adresse als Punkt am Gebäudeumriß besser ist und andere, bei denen es gut und ausreichend ist, die Adresse ans ganze Gebäude zu taggen, wie in den genannten Beiträgen beschrieben. Ich kenne auch einige Fälle, in denen die Tiefgarageneinfahrt eine eigene Hausnummer hat. Da geht es gar nicht anders als sie als Punkt auf die betreffende Stelle des Gebäudeumrisses zu setzen.

Und bitte auch die deutsche Brille mal beiseite legen. In Portugal z.B. hat oft jeder Hauseingang eines Hauses eine eigene Hausnummer; der Laden im Erdgeschoß eine, der Eingang zur Erdgeschoßwohnung eine und der extra Eingang zum Treppenhaus für die oberen Wohnungen wieder eine Hausnummer. Das kann man nur mit Punkten am Gebäudeumriß abbilden.

Ich wende beide Methoden an, je nachdem, was besser paßt. Was aber meiner Meinung nach gar nicht gut ist, ist Umtaggen von Punkt-Adressen am Eingang aufs ganze Gebäude und Löschung des Adreßpunktes. Dem gebührt ja wohl mindestens noch das entrance-Tag. Es ist schließlich eine von einem Mapper erfaßte Information, die nicht einfach gelöscht werden sollte.
Es fehlen doch noch genug Hausnummern in D und es macht mehr Sinn rauszugehen und Adressen zu erfassen als bestehende an die eigenen Vorlieben anzupassen.

Und dann gibt es da noch die mit associated-street-Relationen erfaßten Adressen, die ich persönlich nicht so mag, aber auch bestehen lasse, wenn ich ihnen begegne.

– Rainer

associatedStreet ist ein Krebsgeschwür, das man eigentlich schon längst hätte loswerden müssen. Keine Anwendung unterstützt das, der Aufwand zur Instandhaltung der Relationen ist jenseits von Gut und Böse und die Argumente, mit denen das damals im Wiki nicht als veraltet gekennzeichnet wurde (zwei- oder mehrsprachige Gebiete) überzeugen nicht wirklich, das kriegt man auch mit normalen Tags hin (addr:street:ru und addr:street:uk z. B.)

Es wurde schon vieles geschrieben, trotzdem möchte ich noch auf zwei Dinge eingehen:

  1. OSM ist nichts anderes als eine Datenbank (geht bei vielen offenbar vergessen). Diese sollten vorzugsweise Redundanzen vermeiden (Spezialfälle [z.B. Performancegründen] ausgenommen). Deshalb gibt es für mich schonmal Augenkrebs, wenn ich ein und dieselbe Adresse auf mehreren Elementen hinterlegt sehe. Auch ist es überhaupt nicht wartungsfreundlich. Stelle immer wieder fest, dass dadurch Änderungen nicht an allen Elementen übernommen werden (häufig z.B. bei übersehenen Relationen). Dies lässt sich mit einem redundanzlosen Tagging sehr einfach vermeiden. Noch dazu spart es eine Menge an Speicherplatz/Ressourcen/Zeit.

  2. Auch wenn viele der Ansicht sind, dass jeder so mappen soll wie er es für sinnvoll hält bzw. es die lokale Art und Weise darstellt, finde ich persönlich genau dies das grösste Problem für den Erfolg von OSM. Denn: grundsätzlich sammeln wir Daten, um sie zur weiteren Verwendungen zu benutzen. Diese Weiterverwendung geht aber nur dann sinnvoll, wenn die Daten eine gewisse Struktur aufweisen. Sprich, das Gleiche auch gleich abgelegt/verknüpft wurde. Das Ziel sollte also sein, möglichst genau EINE Lösung für ein und dasselbe “Irgendetwas” zu haben. Ansonsten muss der jeweilige Nutzer der Daten (z.B. eine Routingengine) alle möglichen Spezialfälle miteinbeziehen, was unmengen an Ressourcen bei der Programmierung, sowie auch beim Berechnen selbst erfordert. Nicht zuletzt fördert es auch Fehler, wenn etwas nicht immer gleich gehandhabt wird.

Aus dieser Sicht muss ich sagen, dass ein Mapping am Gebäudeumriss ganz klare Vorteile bringt. So lässt sie sich doch super mit den POIs innerhalb des Umrisses verknüpfen und müssen nicht extra hinterlegt werden (Vermeidung von Redundanzen). Für das Anliegen der Tür-zu-Tür-Navigation sehe ich im entrance Tag die wunderbare Lösung. Auch um die jeweilige Art des Eingangs zu mappen. Spezialfälle wie z.B. die wirkliche Hauseingangsbezogene Adresse in anderen Ländern können natürlich beachtet werden.

Die bessere Variante aus Redundanzensicht wäre natürlich die associatedStreet-Relation gewesen. Jedoch ist diese nicht Einsteigertauglich und hat sich somit auch nicht durchgesetzt (zu Recht, da Relationen für Gelegenheitsmapper zu kompliziert sind)

Bezüglich dem zweiten Punkt bin ich deshalb der Meinung, dass wir möglichst ein klares und eindeutiges Mapping für alle “Probleme” haben sollten. Auch wenn es nicht immer die Beste ist (wie z.B. das Beispiel associatedStreet-Relation). Es gibt noch unzählige andere Bereiche, in denen Mappingwars und unnötigen Programmieraufwand die Realität darstellen. Z.B. highway=path vs. footway vs. cycleway, sideway als Tag vs. footway, ÖPNV-Tagging, landuse gemäss Realität vs. verknüpft mit z.B. einer Strasse, etc., etc., etc.

Die verschiedenen Mappingarten hindern schlussendlich den Erfolg des “Features” und fördern stattdessen unnötige Mappingwars. Ich würde es demnach begrüssen, wenn man endlich eine Einigung bezüglich empfohlenem Adresstagging hätte (würde mich selbstverständlich gerne auch anpassen!).

Sorry, wurde ein wenig ausführlicher…

Hab ich was von Täfelchen gesagt? Die Frage ist nur (da Hausnummern de facto durch ein Verwaltungsakt vergeben werden) wie das im jeweiligen Gebiet administrativ gehandhabt wird und eben nicht irgendwelche andere Überlegungen.

Wenn ich auf der gruenen Wiese mappe habe ich zwar eine Praeferenz fuer eine Taggingvariante, verwende andere Varianten aber auch wenn sie passender erscheinen.

Am wichtigsten finde ich, und da scheint grosse Einigkeit zu herrschen, dass man nicht umtaggt, bloss weil man die andere Variante lieber hat.

Was mich nun noch interessiert, ist der Aspekt der Einheitlichkeit, den ich ebenfalls wichtig finde. Ich fuehle mich naemlich motiviert in dem Fall doch umzutaggen, wenn ein ganzes Dorf in einem Schema erfasst ist, bis auf ein paar ganz wenige Haeusser, bloss weil die von jemand anderem erfasst worden sind (nicht etwa weil in diesen Faellen das andere Schema sinnvoller waere, sondern nur weil der es lieber anders macht). Wenn ich in Doerfern mit bereits gemappten Adressen weitere hinzufuege, dann tue ich das im dort vorherrschenden Schema, weil ich finde, dass Einheitlichkeit auch ein Wert ist. Es ist ja so, wenn alle Adressen in einem Schema sind, nur ein paar wenige anders, dann ist die natuerliche Reaktion darauf, sich zu fragen was an denen anders ist. Vom einheitlichen Rest abzuweichen erzeugt Aufmerksamkeit und Aufmerksamkeit sollte nur dann erweckt werde, wenn sie begruendet ist. Wenn aber alles normal und wie zu erwarten ist, dann sollte keine Aufmerksamkeit erzeugt werden. Diesem Gedankengang folgend frage ich mich eben, ob es dann sinnvoll ist, die Abweichler anzugeglichen.

Ich wuerde mich ueber Meinungen freuen.

Meine Interpretation, man bessere mich aus, wenn ich da was technisch falsch verstanden habe:
Adressen koennen auf jeden Fall auf Nodes (POIs, Gebaeude ist insgesamt nur als Node erfasst), Ways (Gebaeudeumriss) oder Relationen (Gebaeude mit Innenhoefen) eingetragen sein.

Kann mir jemand ein einziges technisch schlagkraeftiges Argument liefern, warum fuer jegliches auswertendes Programm diese “Variationsvielfalt” ein Problem darstellen koennte?

Gegenbeispiel (ich will KEINESFALLS :wink: Offtopic werden): Gehsteige an die Strasse als Tag oder als extra way: Hier tun sich Auswerter z.B. schwer, den Gehsteig zur Strasse zuzuordnen, fuer beide Varianten gibt es die viel diskutierten Vor- und Nachteile.

Bei der Adressdiskussion sehe ich das noch nicht, alles ist technisch gleichwertig, manchmal mag die eine oder andere Variante leichte Vorteile haben, es gibt keinen Grund fuer Vereinheitlichung und keinen Grund fuer Umtaggung (auch wenn alle Haeuser in einem Dorf bis auf eines gleich getaggt waeren).

Ich formuliere es mal kurz provokant: Im Vergleich zu vielen anderen Diskussionen hier ist das Adresstaggingschema eigentlich sehr einheitlich!

Ja, es stimmt dass in Italien die Hausnummern dort gemappt werden, wo sie anzutreffen sind. Das hat aber einen triftigen Grund: jeder Zugang und sogar potentielle Zugänge (z.B. Schaufensterscheiben) erhalten in der Regel Hausnummern, jedes größere Haus (in der Stadt) hat daher zig Nummern, weil jede Aussentür und viele Fenster eigene Nummern bekommen. Ohne Kenntnisse der internen Aufteilungen kann man oft gar nicht sagen, welche Nummer zu welcher Fläche gehört. Ausserdem haben gerade Erdgeschoss-flächen oft sehr viele Nummern (weil sie mehrere Eingänge haben bzw. haben könnten).
In Deutschland ist das hingegen Sache der Kommunen (AFAIK), Nummern zu vergeben, bzw. der Länder. Manche Länder haben Hausnummern, andere haben Grundstücksnummern. M.E. wäre es in diesem Fall am konsequentesten, die addr:housenumber tags auf Objekte zu machen, die dem Grundstück entsprechen, alternativ auf die Häuser, sofern es auf dem Grundstück keine weiteren Sachen gibt, die eine Adresse nötig hätten, bzw. sofern sich die Adresse wirklich auf ein Haus und nicht auf ein Grundstück bezieht. In anderen Fällen beziehen sich die Nummern auch in Deutschland auf Hintereingänge, Treppenaufgänge und ähnliches, und werden “bei Bedarf” zugeteilt (Berliner Nummerierungsverordnung, z.B.).
Grundsätzlich sieht man ja am tag “entrance”, ob das ein Eingang ist, mit Adressen hat es nicht so viel zu tun.

Ich hoffe, dass sich durch die ganze Diskussion und dem Beharren auf einem bestimmten Standpunkt nicht zu viele Mapper abschrecken lassen und deshalb überhaupt keine Adressen mehr erfassen. Der fehlende Datenbestand ist m.E. ein größeres Problem als die Frage, ob die Hausnummer nun an den Eingang oder die Eingänge gehört oder ins Gebäude. Dies sollte im Einzelfall mit logischem Menschenverstand entschieden werden. Wichtig ist mir, dass wir dem Renderer die Möglichkeit geben, eine gute Karte zu erstellen.
Bei einem Großteil der Adressen handelt es sich um Ein- oder Zweifamilienhäusern. Da spielt es meiner Ansicht nach keine Rolle, wo die Hausnummer steht, wichtiger ist, dass überhaupt eine vorhanden ist. Wegen der Einheitlichkeit würde ich mich den Vormappern anpassen, jedenfalls nicht ohne triftigen Grund die Angaben von anderen Mappern verändern.
Bei einem Gebäude in meiner Heimatstadt mit einer einzigen Hausnummer, jedoch mehreren Eingängen zu Geschäften im Erdgeschoss und einem weiteren Eingang für Wohnung in den oberen Etagen habe ich nicht an jeden Eingang dieselbe Hausnummer gesetzt, sondern so angebracht, dass sie einmal im Gebäude steht.
Bei einem weiteren Gebäude in meiner Heimatstadt, das von außen betrachtet nicht baulich abgetrennt ist, jedoch vier Hausnummern hat, davon eine zu einer anderen Straße gehörend, habe ich die Hausnummern deshalb den Eingängen zugeteilt.
Ich verfahre also nicht einheitlich, sondern entscheide je nach Objekt und hoffe, dass viele Mapper einfach weiter Adressen erfassen, da noch viele schwarze Flecken bestehen.

Ich kenne ein Gebäude in Deutschland, das hat zwei Hausnummern aber nur einen gemeinsamen Eingang für beide Hausnummern. Ist das Gebäude hier (Hausnummern 1 und 3 sind zusammen).

Übrigens bin ich heute beim survey auf einen Fall gestoßen, den wir noch nicht diskutiert haben. Dieses Grundstück hat zwar einen Briefkasten mit Hausnummer dran, ist aber ansonsten komplett unbebaut. Als ich vor Ort war, standen dort zahlreiche Fahrzeuge des Schaustellergewerbes, sodass ich daovn ausgehe dass dort eine entsprechende Familie “wohnt”. Ich hab den Node einfach mitten aufs Grundstück geklatscht, denn einen “Eingang” gibt es hier in dem Sinne überhaupt nicht. Oder hat jemand eine bessere Idee?

Ich denke das passt.

Ja, den Node da eintragen, wo der Briefkasten steht. Den Briefkasten könnte man dann noch mit amenity=letter_box codieren.
:wink:

Eine (hoffentlich letzte Frage):

Diese Fläche bezeichnet das Gymnasium Weierhof. Aktuell ist die Adressangabe (Am Hofwiesbach 1) auf der Fläche eingetragen. Das ist aber im hier vorliegenden Fall etwas suboptimal, da die Adresse “Am Hofwiesbach 1” eigentlich nur das Schulgebäude selbst bezeichnet. Daneben gibt es auf dem Gelände aber noch das Internat (An der Aula 1), mehrere Lehrerwohnungen (Am Hofwiesbach 2, 3, 4, 7, An der Aula 2 und 3) und die Aula selbst (An der Aula 4). Wenn ich jetzt aber die Adresse an das Schulgebäude verschiebe, dann ist die Fläche ohne Adresse und eine Suche nach dem Gymnasium gibt keine Adresse aus. Hat jemand eine Idee, wie man das besser machen könnte?

Wo musst man hin, wenn man als “Fremder” in die Schule (Sekretariat) möchte?

Dort würde ich alle Informationen zusammenfassen. Die Fläche würde ich “unbenamt” lassen.

EDIT:
https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=49.63356%2C8.03419%3B49.63541%2C8.02749#map=17/49.63426/8.03083

Nicht so kompliziert denken. Wenn die Schule hauptsächlich die Adresse nutzt: An der Fläche lassen. Zusätzlich eine an den Haupteingang - auch wenn das redundant sein mag.
So kann man ganz simpel (KISS) sowohl die Info über die Schule abfragen, als auch sofort zielgerichtet routen. Auch wenn so mancher meint, das soll der intelligente Auswerter alles ausrechenen. Das passiert vielleicht in zwanzig Jahren - oder nie. Nutzen möchte ich OSM aber zu meinen Lebzeiten :stuck_out_tongue:

Ich kann das nur unterstreichen, dass es ein einheitliches mapping geben sollte. Die Frage ist nur, warum es in OSM keine Rules (Regeln) gibt, die bestimmte Arten des mappings verhindern oder Hinweise geben, wie man ein Gebäude besser mappen kann.

Wenn wir den Ansatz verfolgen, dass die Adresse auf ein Gebäude gemapped wird, dann stellt sich die Frage, wie POIs auf die Hausnummern referenziert werden, wenn ein Haus mehrere Hausnummern hat. Aufgrund fehlender Referenzen zwischen POI (eines Ladens z.B.) und address-POI des Eingangs ist doch eine doppelte Erfassung der Adresse auf dem POI (des Ladens) unvermeidbar.

Das ist gängige Praxis und im Großen und Ganzen unstrittig - und auch unproblematisch.