Hausnummer und Shop in einen Node?

Moin!

Wie macht ihr das, wenn sowohl Adresse von einem Haus bekannt ist (addr:housnumber=) und in dem Gebäude ein Shop (shop=) ist und wenn das Gebäude bisher noch nicht als Fläche, sondern nur als Node erfasst ist.

Kommen die beiden genannten Tags in einen Node? Würde für mich mehr Sinn machen, ist schließlich das selbe Gebäude.

Oder macht man das in zwei Nodes, einen für die Adresse, einen für den Shop. So habe ich es schon oft gesehen und mich gefragt, warum nicht in einem Node.

Gruß
Leif

Wenn das komplette Gebäude vom Shop belegt ist, ergibt ein node imho durchaus Sinn. Wenn der shop aber (wie häufig anzutreffen) beispielsweise nur das Erdgeschoss belegt und im Rest des Hauses Wohnungen sind, spricht vieles für 2 nodes.

Die komplette Adressinformation gehört (auch) in den Node des Geschäftes, ebenso wie die Artikelkategorie, Telefonnummer, evtl. Website. Bei POIs ist das jedenfalls angebracht.

Grüße
Mario

Dann wird die Hausnummer 2x gerendert, was nicht im Sinne des Erfinders sein kann…

Ich finde, eine elegante, “einzig richtige” Lösung gibt es hier nicht. Ich erfasse die Hausnummer meistens dort, wo sie vor Ort angebracht ist, das ist bei gemischter Gebäudenutzung oft am Eingang zur Wohnhaus-Stiege. Dieser Ansatz verträgt sich auch am besten mit der Tatsache, dass ein Gebäude mehrere äuquivalente Anschriften haben kann, weil es an mehrere Gassen grenzt.

Die Frage ist, wofür erfassen wir diese Adressen? Wollen wir damit eine Datenbank schaffen, die man für Postwurfsendungen verwerten kann, oder wollen wir Landkarten und Stadtpläne schaffen? In letzterem Fall scheint es mir nicht nötig, jedem Shop eine komplette Postanschrift zu verpassen.

moin moin,
die Adressen werden für ein Routing “bis zur Haustür” verwendet (werden).
Also nicht für Briefe sondern für Personen.

lg
Walter

Dafür braucht man die Anschrift nicht im selben Node. Es genügt, wenn ich als Anwender der Routingsoftware mein Ziel eindeutig angeben kann (d.h. wenn sie das Ziel in Koordinaten umschlüsseln kann), z.B. indem ich nur die Adresse angebe, ohne Firmenname. Oder auch umgekehrt, wenn es nicht mehrere Firmen mit dem selben Namen gibt. Im einen Fall werde ich vielleicht vor den Eingang der Wohnstiege geroutet, im anderen Fall 5m weiter vor den Eingang des Shops, was macht das für einen Unterschied? In der Praxis muss man sowieso 200m weiter fahren um einen Parkplatz zu finden.

wenn du zu einem shop willst, der als solches irgendwie dem gebäude zugeortnet ist (“der shop xyz ist hier”) und du kennst den Namen, hast du recht. Den findet jedes gute navi

aber um bei deinem Beispiel zu bleiben:

WAS gibst du denn hier deinem Navi zum Fressen? “Berlin, Kurfürstendamm”?

Kurzfassung: klopf die Nummer rein, wenn du sie kennst. ist 1000x besser als Mein Navi “raten” zu lassen.

Ein bisschen Redundanz schadet der Datenbank nicht; daher ruhig auch alle POIs mit kompletten Adress-Informationen taggen. Für einen POI die richtige Adresse finden ist ansonsten nämlich schwierig bis nicht-lösbar.

Berlin, Kurfürstendamm 123
Es geht ja um den Fall, dass die Adresse (d.h. Straße+Hausnummer) schon in einem anderen Node im selben Gebäude erfasst ist, weil der Shop nur einen Teil des Gebäudes ausmacht. Andernfalls (wenn Shop=Gebäude) gibt es eh nichts zu diskutieren.

Doch, denn Redundanz heißt, dass erstens die Daten aufgebläht werden (jeder Download wird größer), und zweitens muss jede Änderung bei allen redundanten Daten mitgezogen werden, was fehleranfällig ist. Es wird dann fast immer auf einen Teil der Daten vergessen. Hausnummern ändern sich zwar nicht so oft, aber in Ungarn z.B. wurden nach dem Fall des Kommunismus fast alle Straßen umbenannt…

Außerdem: Gefällt es dir, wenn eine Hausnummer 5x auf der Karte steht, weil es in dem Haus 5 Shops gibt?

Was meinst du mit kompletten Adress-Informationen? Bei POIs braucht man nicht mehr als Straße und Hausnummer. Ort und Land ergeben sich automatisch aus deren Grenzen. Wenn Gemeinden zusammengelegt werden oder sich ein Land unabhängig erklärt, müsste man sonst Myriaden von Objekten ändern. Das gleiche gilt für Postleitzahlen. Hier in Österreich ändern sich immer wieder welche. Aber ich brauche euch nichts erzählen, ihr habt schon die Umstellung von 4- auf 5-stellig erlebt.

aha, so langsam klärt sich die Sache
ich mache das so wie auch bei den Relationen:

was für mehrere Sachen identisch ist - in diesem Fall die Anschrift - rutscht nach “oben”. d.h die Adresse “wandert” vom shop-node zum building. Die shop-tags (wer wann was verkauft…) bleibt beim shop.

steigerung: mehre Gebäude auf einem Gelände mit gemeinsamer Anschrift (shopping-center?) → Anschrift “wandert” zur site.

so macht es für mich Sinn - wenn die Programme vernünftig geschrieben sind, “vererben” sie die tags von “oben” nach “unten” wie bei modernen Programmiersprachen.

lg
walter

Der Konsens ist nunmal, die Adresse jeweils komplett (inkl. PLZ, Ort und Land) anzugeben. In Europa haben z.B. 70% der Elemente mit addr:housenumber auch ein addr:city. (Quelle)

Aus reiner IT-Sicht bin ich sogar mit Dir einverstanden und persönlich-theoretisch würde ich Adress-Relationen gegenüber dem Taggen einzelner Nodes bevorzugen. Allerdings muss man auch hier eine Kosten/Nutzen-Rechnung(*) machen. Das komplette Taggen einer Adresse (inkl. PLZ, Ort und Land) vereinfacht viele Anwendungen (z.B. OpenLinkMap mit Adress-Popup), insbesondere da auf Ortsebene viele Grenzen (noch) gar nicht vorhanden sind. Wie häufig entstehen neue Länder? Wie oft werden PLZs abgeändert? Solche Sachen lassen sich im Bedarfsfall auch ‘relativ einfach’ per Bot/Script in einer einmaligen Aktion ändern.

(*) Falls jemand mal ein Script schreibt, welches beim Import in die eigene Datenbank jeden Node automatisch und zuverlässig mit der kompletten Adresse ergänzt, mag die ganze Sache wieder anders aussehen…

Das funktioniert aber nicht, wenn das Gebäude mehrere gleichwertige Anschriften hat. Ich meine die Dupel Straße+Hausnummer, wenn das Gebäude an mehrere Gassen grenzt - was eigentlich der Normalfall ist. Dann gibt es keine andere Möglichkeit, als mindestens einen der Dupel als Node zu erfassen - außer man nimmt einen Informationsverlust hin.

Zudem sind in dicht bebautem Gebiet die Gebäude meist zu Häuserblocks verbunden, wo man weder beim Vorbeigehen noch am Satellitenbild klar erkennen kann, wo der Geltungsbereich einer Hausnummer aufhört und die nächste anfängt. Ich erfasse Häuserblocks als building=yes daher immer im Ganzen. Natürlich könnte man von amtlichen Karten abzeichnen, wo die Aufteilung nach Hausnummern verzeichnet ist. Aber das ist ja verboten.

Ist es dadurch ein Konsens? Mir scheint das eher auf automatisierte Imports hinzudeuten. Der Wiki-Eintrag zu key:addr sagt dezidiert, dass alles außer der Hausnummer optional ist.

Dann vergleiche mal den Zeitaufwand beim manuellen Taggen von Millionen Nodes mit dem Zeitaufwand, in eine Anwendung reinzuprogrammieren, dass sie die Gemeindegrenzen berücksichtigt.

In Österreich sind sie m.W. komplett erfasst, und in Deutschland kann das auch nur eine Frage der Zeit sein.

Ein neues Land entsteht vielleicht 1-2x/Jahr. Postleitzahlenänderungen gibt es in Österreich im Schntt etwa alle 2 Wochen, von anderen Ländern weiß ich nichts.

Woher soll der Bot wissen, welche Nodes mit Land=X oder PLZ=X er ändern soll und welche nicht? Er muss dann erst wieder nach Grenzen gehen. Also entweder ist die Berücksichtigung der Grenzen ein schwerwiegendes Problem, dann wird auch der Bot daran scheitern. Oder der Bot kann das, dann sollten auch die Anwendungen das können.

Du vergisst dabei, dass die Adressinformationen durschnittlich 1,000irgendwas mal eingetragen bzw. aktualisisert werden. Die Anwendungen aktualisieren sich allerdings regelmaessig (bei Routern/Karten gibt es oft taegliche oder woechentliche Updates) aus der Datenbank. Wenn du also die Arbeit in die Anwendung verlagerst, darsft du nicht nur den Programmieraufwand berücksichtigen sondern musst auch an den enormen Rechenaufwand denken, der bei jeder Aktualisiserung der Karte zwangslaeufig mit anfaellt.

Gruss
Torsten

hab ich ja auch nie “gefordert”. lies den obigen satz doch nochmal genau durch: WAS für mehrere Sachen IDENTISCH IST, in diesem Falle die Anschrift, RUSCHT NACH OBEN. Dein Kommentar beschreibt eine völlig andere Situation, wo das natürlich nicht gemacht werden kann/soll.
Du vergleichst hier Äpfel mit Birnen.
walter

Das eine ist ein manueller Aufwand, das andere ein Rechenaufwand fürn Computer. Das macht einen großen Unterschied! Vor allem weil es bequemer ist, den Blechtrottel arbeiten zu lassen, aber auch weil Computer keine Tippfehler machen und weil sie immer schneller werden.

Ich glaube nicht, dass der Rechenaufwand so enorm ist. Ich weiß nicht, nach welchen Algorithmen die Renderers und Routers vorgehen, aber naheliegend scheint mir folgender Algorithmus: Erst werden die administrativen Einheiten in Rechtecke zerlegt, wovon manche komplett einer administrativen Einheit zugeordnet sind, während die übrigen in der Diagonale geteilt sind. Diesen Aufwand hat man sowieso, unabhängig wie viele Nodes ohne komplette Adresse es gibt. Der nächste Schritt ist es, alle Rechtecke durchzugehen und pro Rechteck alle noch nicht zugeordneten Nodes - oder auch andersrum. Das ist bei einer vorgegebenen Anzahl Rechtecke ein linearer Aufwand (proportional zur Anzahl der Nodes). Ich finde das nicht so schlimm, da die Kordinaten nur auf größer/kleiner verglichen werden müssen; bzw. bei diagonal geteilten Rechtecken muss man noch prüfen, in welcher Hälfte der Node liegt, was auch nicht kompliziert ist (Division) und nur für die Rechtecke gemacht werden muss, denen der Node schon zugeordnet wurde.

Man könnte evtl. noch weiter optimieren, indem man die Rechtecke und/oder Nodes vorher sortiert. Wenn ich mich nicht irre, ist der Aufwand dann O(NldN), während er sonst O(NM) ist, mit N=Nodes und M=Rechtecke.

Momentan duerfte unsere OSM Datenbank schneller an Groesse zulegen als die Computer an Rechengeschwindigkeit. Z.Z. ist der zip-komprimierte Europaauschnitt aus der Datenbank 4.7GB gross. Du kannst dir also leicht vorstellen, welche Datenmengen da zusammen kommen. Selbst wenn die Operationen selber nicht sonderlich aufwendig sind, so ergibt sich allein aus der Groesse schon ein enormer Aufwand. Ich schaetze, dass man da bei einem aktuellen PC mit einigen Stunden fuer Europa rechnen muss. Zum Vergleich: Alleine die Europadatei zu entpacken und daraus mit dem mkgmap-splitter knapp 200 rechteckige Kacheln auszuschneiden, braucht auf meiner 3 Prozessormaschine deutlich ueber eine Stunde.

Und diesen Aufwand muss dann also jede Anwendung bei jeder Aktualisiserung neu betreiben. Da ist es wesentlich sinnvoller, wenn man das gleich ordentlich in der Datenbank ablegt, am einfachsten indem es die Mapper händisch eintragen, und bei Bedarf indem man ab und an mal einen Bot rueber laufen laesst, der verbliebene Probleme korregiert.

Gruss
Torsten

Die letzte Diskussion über Hausnummern war auf der Mailingliste: Erster Post.

zusätzlicher manueller Aufwand bei Import: gering.
zusätzlicher Manueller Aufwand im JOSM: gering (Adresse, PLZ, Ort und Land werden automatisch von der letzten Adresse übernommen)

Aufwand, ein Script zu programmieren, welches zuverlässig alle addr:housenumber-Nodes mit den restlichen Angaben füllt: bisher keine praktikable Lösung. (Hast Du Nominatim schon mal lokal installiert?)

Bei der Kosten/Nutzen-Rechnung geht es auch darum, was wie oft benötigt wird. Wenn viele von einem Node wissen möchten, welche PLZ er hat, dann “lohnt” es sich, die Berechnung bereits in die Datenbank zu schreiben und nicht jeden Abfrager alles selber ausrechnen zu lassen.

Die Welt ist grösser als nur AT und DE. Zudem sind die PLZ-Grenzen oft unterschiedlich zu den Gemeinde-Grenzen.

Wenn die PLZ-Grenzen einmal (nahezu) komplett vorhanden sieht die Sache vielleicht wieder anders aus. Andererseits sind die zusätzlichen Angaben offenbar gut komprimierbar und fallen daher fast nicht zur Last.

Die Postleitzahlen in AT ändern sich höchstens 1x pro Monat, nämlich am 1. :-> Und welche neuen Staaten ausser Kosovo, Montenegro und Ost-Timor fallen mir (bzw. Wikipedia) keine ein…

Wenn alle Adressen komplett getagged sind, dann braucht es keine Grenzen für die Umstellung. Zudem spielt hier obige Kosten/Nutzen wieder mit: die OSMF hat mehr Rechenpower zur Verfügung als der einzelne Nutzer der Daten. Es kann daher sinnvoll sein, ‘grosse’ Aufgaben nach oben abzugeben.

Edith meint:
Wie gesagt, dass muss alles nicht für immer so sein. Aber momentan ist es meistens am praktischsten, die Adressen komplett zu taggen und damit die Auswertung massiv zu vereinfachen.

Edith 2 sagt:
Ich beziehe mich vorallem auf POIs (Shops, Restaurants, …), welche öfters auch getrennt von der Datenbank genutzt werden. Bei Adressen von ‘einfachen’ Wohnhäusern welche hauptsächlich fürs Routing verwendet mag die Lage schon wieder anders aussehen, da die Routingkarten-Erstell-Programme anders aufgebaut sind.

Wenn du ihn gering empfindest, dann nur zu, erfasse diese Tags. Ich werde es nicht tun, denn einen nutzlosen Aufwand tue ich mir nicht an, egal ob groß oder klein.

Es ist wie mit dem Mappen von Kanaldeckeln: Es ist keiner gezwungen, das zu machen; aber wer Lust hat…

Ich hatte noch keinen Bedarf dafür. Vielleicht könnte ich ein Script schreiben, aber ich denke, das könnten viele, nur hat es noch keinen interessiert.

Auf jeden Fall sollte es zentral passieren, damit idente Berechnungen nicht millionenmal durchgeführt werden müssen, sondern nur 1x auf einem Server.

Stimmt, und beim Mappen von anderen Ländern mag es vielleicht sinnvoll sein, Adressen komplett zu erfassen.

Das ist ein natürlich ein Problem. Man müsste ebenso wie die Gemeinde- auch die PLZ-Grenzen erfassen.

Ich habe jahrelang die PLZ in unserer DB gewartet und dafür den PLZ-Newsletter der Post bezogen. Du kannst mir glauben, dass sich Postleitzahlen öfter ändern.

Der Zerfall der Sowjetunion ist nicht so lang her. Oder werde ich alt?

Es werden NIE alle komplett getaggt sein, d.h. man wird sowieso ein Script brauchen, das die Tags automatisch ermittelt.

Da bin ich mit dir einer Meinung, s.o.

Doch das ist es aber, siehe http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer und http://wiki.openstreetmap.org/wiki/Good_practice

Der Renderer kann feststellen, das der POI in der Gebäudefläche liegt (gehe hier davon aus das nicht das ganze Gebäude zum Shop, etc. gehört) und die genaueren Hausnummern der POIs rendern, oder aber er rendert beides, einfach weil es sich z.B. um ein Einkaufszentrum mit einem Hausnummernbereich handelt, von denen das einelne Geschäft natürlich nur eine Haunummer hat.

Ach ja, es ist ja auch ein Unterschied ob ich mich für das Gelände (ja, auch das hat ja ein Adresse), die Häuser darauf, die Shops im Haus, oder für alles zusammen interessiere und danach filtere, weglassen kann man immer, aber woher soll ich wissen welche Hausnummer der Shop hat, wenn ich da auch noch die landuse-Daten auswerten muß, die mich nicht interessieren, wenn ich z.B. eine Liste der Tankstellen oder was auch immer erstellen will.

Zu den Adressdaten, da solle man aus meiner Sicht zumindest Straße, Hausnummer und Postleitzahl (es gibt spezielle Postfach- und Großkunden-Postleitzahlen) taggen, der Rest läßt sich ja auch aus den Bereichsdaten genau genug ermitteln und als zusätzliche Sicherheit kann man an der adminstrativen Grenze mit der Postleitzahl der angrenzenden Gebiete vergleichen.