Adressangaben am Eingang - oder?

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.

Weil wir tolerant sind :wink:
Und: weil es ein weltweites Projekt ist und sich nicht jedes Land an deutsche Gepflogenheiten hält (die auch nicht überall gleich sind). Beschäftige Dich doch einfach einmal mit der Definiton der Adresse in verschiedenen Ländern, dann wirst Du verstehen, dass es keine einfache Lösung geben kann.

Hallo zusammen,

mein erster Beitrag hier im Forum, obwohl ich schon einige Zeit tagge.

Ich habe hier den Beitrag komplett gelesen und gelernt, dass es aus verschiedenen Gründen zwei Methoden gibt eine Adresse zu taggen: Einerseits auf den Gebäudeumriss, andererseits per Entrance.
Allerdings finde ich bei mir in der Gegend auch noch eine dritte Methode, die über einen Adresspunkt geht. Ist das denn sinnvoll?
Konkreterweise habe ich das zB hier gefunden: https://www.openstreetmap.org/edit#map=18/49.45836/11.14575

Was haltet ihr hiervon?

BEsten Dank und Grüße
Creator

Das ist eine weitere Eingabemethode, die in manchen Gegenden sehr verbreitet ist. Sie ist gewissermaßen der Vorläufer des Taggings auf den Eingang, wenn dessen Lage (aus dem Luftbild) nicht zu erkennen ist.
Sie ist manchmal nicht zu vermeiden, wenn z.B. für ein Einkaufszentrum o.ä. mehrere Nachbarhäuser zu einem Gebäudekomplex umgebaut wurden und die Eingänge sich nicht mehr eindeutig einer festen Hausnummer zuordnen lassen und auch im Inneren die alten Grundrisse nicht mehr erkennbar sind.

Immer davon ausgehen: Ich möchte jemanden im Haus … 8c besuchen. Wo kann ich klingeln bzw, wo ist der Eingang? Genauso bei der Zufahrt zu einem Werksgelände. Manchmal gibt es noch verschiedenen Liefereingänge (Anschriften).

Bei einem Einfamilienhaus bietet es sich an, die Adresse der Einfachheit halber einfach bei der Gebäudefläche einzufügen. Dadurch wird auch die Hausnummer bei Kartendarstellungen gut lesbar mitten im Gebäudeumriss angezeigt.

Das Eintragn als Node an dem Punkt, an dem sich die Haupteingangstür befindet, hat dagegen den Vorteil, dass dies auch noch eine Aussage darüber trifft, wo man hin muss, wenn man dort klingeln möchte. Aber dies lässt sich auch bereits dadurch erreichen, dass man den Fußweg von der Grundstückszufahrt zur Haustür einzeichnet.

Sinvoll ist das Eintragen der Adresse als Punkt am Haupteingang bei großen Gebäuden, bei denen nicht klar ist, wo es denn reingeht oder bei Gebäuden mit mehreren Anschriften.

Das Eintragen als seperater Adresspunkt ist meines Erachtens in zwei Fällen sinnvoll:

  1. Das Haus ist noch nicht eingezeichnet (z.B. weil das Haus erst frisch erbaut wurde und noch kein passendes Luftbild vorhanden ist oder zwar die Anschrift schon bekannt ist, aber das Haus noch nicht steht) oder wenn sich schlichtweg noch niemand die Mühe gemacht hat, die Gebäude einzeln einzuzeichnen. Handelt es sich allein um eine bereits zugewiesene Anschrift, Gebäude noch nicht vorhandenl: Reiner Adresspunkt. Ist bereits ein Gebäude vorhanden, nur noch nicht eingezeichnet, dann Adresse mit dem Zusatz building=*

  2. In Geschäftshgebäuden gibt es oft mehrere Adressen. Bei einem Supermarkt, über dessen Haupteingang noch eine Postfiliale, eine Bächerfiliale, ein Friseur und eine Apotheke zu erreichen ist, kann es sinnvoll sein, die jeweiligen Objekte mit Adresse als Punkt dort zu platzieren, wo sie sich in der Gebäudefläche befinden. Die Information “aha, gleich rechts befindet sich die Bäckerfiliale, dahinter die Apotheke und links ist noch eine Postfiliale” ist ggf. in diesem Fall hilfreicher, als die, über welchen Eingang diese erreicht werden (weil sie wahrscheinlich alle über den gleichen Eingang zu erreichen sind). Und ich halte es immer sinnvoll, dass ein Punkt, der die Lage eines Geschäfts in einem Einkaufszentrum markiert, nicht nur Name und Art des Geschäfts wiedergibt (u.A. zfür die Kartendarstellung eines entsprechenden Symbols) sondern auch die Postanschrift, da sich diese nicht immer eindeutig aus der Lage ableiten lässt.