Hausnummer und Shop in einen Node?

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

Garmin-User wrote:

Die komplette Adressinformation gehört (auch) in den Node des Geschäftes

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.

fkv wrote:

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

wambacher wrote:

fkv wrote:

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

wambacher wrote:

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

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.

fkv wrote:

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)

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:

z.B. indem ich nur die Adresse angebe, ohne Firmenname

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.

wambacher wrote:

aber um bei deinem Beispiel zu bleiben:

z.B. indem ich nur die Adresse angebe, ohne Firmenname

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

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.

t-i wrote:

Ein bisschen Redundanz schadet der Datenbank nicht

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?

t-i wrote:

daher ruhig auch alle POIs mit kompletten Adress-Informationen taggen

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.

fkv wrote:

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.

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

fkv wrote:

t-i wrote:

Ein bisschen Redundanz schadet der Datenbank nicht

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?

t-i wrote:

daher ruhig auch alle POIs mit kompletten Adress-Informationen taggen

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.

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..

wambacher wrote:

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.

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.

t-i wrote:

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.

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.

Allerdings muss man auch hier eine Kosten/Nutzen-Rechnung(*) machen.

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

da auf Ortsebene viele Grenzen (noch) gar nicht vorhanden sind

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

Wie häufig entstehen neue Länder? Wie oft werden PLZs abgeändert?

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.

Solche Sachen lassen sich im Bedarfsfall auch 'relativ einfach' per Bot/Script in einer einmaligen Aktion ändern.

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.

fkv wrote:

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

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

fkv wrote:

wambacher wrote:

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.

Das funktioniert aber nicht, wenn das Gebäude mehrere gleichwertige Anschriften hat.

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

de_muur wrote:

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.

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(N*ldN), während er sonst O(N*M) ist, mit N=Nodes und M=Rechtecke.

fkv wrote:

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.

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.

fkv wrote:

Allerdings muss man auch hier eine Kosten/Nutzen-Rechnung(*) machen.

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

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.

fkv wrote:

da auf Ortsebene viele Grenzen (noch) gar nicht vorhanden sind

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

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.

fkv wrote:

Wie häufig entstehen neue Länder? Wie oft werden PLZs abgeändert?

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.

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..

fkv wrote:

Solche Sachen lassen sich im Bedarfsfall auch 'relativ einfach' per Bot/Script in einer einmaligen Aktion ändern.

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.

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.

t-i wrote:

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

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...

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?)

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.

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.

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

Die Welt ist grösser als nur AT und DE.

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

Zudem sind die PLZ-Grenzen oft unterschiedlich zu den Gemeinde-Grenzen.

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

Die Postleitzahlen in AT ändern sich höchstens 1x pro Monat, nämlich am 1. :->

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.

Und welche neuen Staaten ausser Kosovo, Montenegro und Ost-Timor fallen mir (bzw. Wikipedia) keine ein..

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

Wenn alle Adressen komplett getagged sind, dann braucht es keine Grenzen für die Umstellung.

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

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.

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

fkv wrote:

Garmin-User wrote:

Die komplette Adressinformation gehört (auch) in den Node des Geschäftes

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

Doch das ist es aber, siehe http://wiki.openstreetmap.org/wiki/Tagg … e_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.

@fkv:
Eigentlich sind wir mehr oder weniger einer Meinung. :-)

Solange es keine PLZ-Grenzen und zuverlässige Scripts zur Bestimmung gibt und im JOSM (fast) kein Mehraufwand ist, neben der Hausnummer auch noch Strasse, PLZ, Ort und Land zu erfassen, solange mache ich das. Und hoffe dabei, dass es möglichst viele andere mir gleich tun. (Obwohl ich selber nich mal Routing-Programme benutze.)

@neue Länder: da wollte ich eigentlich noch "seit 1995" hinschreiben.

@AT-PLZ: Na gut, ich hatte die Excel-Liste der österreichischen Post nicht komplett angeschaut; der letzte Wechsel, der nicht Anfangs Monat stattfand, ist allerdings schon fast zwei Jahre her.. 😉

Fabi2 wrote:

fkv wrote:

Garmin-User wrote:

Die komplette Adressinformation gehört (auch) in den Node des Geschäftes

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

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.

ich bin jetzt auch mal in den genuss gekommen eine shopping mall taggen zu dürfen. bei der mall existieren drei adressen: die mall selber hat eine adresse "A" zugewiesen, die shops im gebäude haben aber entweder adresse "B" oder adresse "C". wie soll jetzt eine logische verknüpfung hergestellt werden welcher shop unter welcher adresse erreichbar ist, wenn ich nicht nach dem gebäudeumriss gehen darf? momentan haben die shops bei mir gar keine adresse bekommen und die adressen "B" und "C" sind als nodes in der nähe der betreffenden straße angelegt.

mit der steigenden komplexität der abzubildenden daten werden wir, meiner meinung nach, über kurz oder lang die "ease of use" für neueinsteiger opfern müssen. dann wird es vermutlich einen abgespeckten editor für neueinsteiger geben wo sie nur POIs per drag and drop auf die map werfen können und second level mapper, die das ganze mit mehr knowhow sauber in die karte nachträglich einarbeiten. quasi so wie die gesichteten versionen bei wikipedia.