Relation:associatedStreet

Dimanche · 2014-02-23 14:51:23

Bei mir im Dörfchen trägt ein Mapper Häuser und Adressen in einer Relation ein. Dadurch neugierig geworden habe ich mal nachgesehen was das Wiki dazu sagt. Unter anderem: „Prinzipiell sind diese jedoch für Software leichter und weniger fehleranfällig auszuwerten.“ Was mir auch schlüssig erschien und habe daher selber eine Straße, nachträglich, in die Relation gepackt.
Etwas Später habe ich dann, an anderer Stelle gelesen: „ DE:Relation:associatedStreet - Relation zur Erfassung von Hausnummern. Auf die Relation sollte verzichtet werden und statt dessen die Nummern unmittelbar den Elementen hinzugefügt werden: Karlsruhe-Schema und addr “

Wie den nun? Entweder Relation oder nicht? Für mich sind diese beiden Aussagen ein Widerspruch.

Wie seht ihr das? Oder habe ich da grundsätzlich was nicht verstanden?

VlG

wambacher · 2014-02-23 15:07:50

Dimanche wrote:

Wie den nun? Entweder Relation oder nicht? Für mich sind diese beiden Aussagen ein Widerspruch.
Wie seht ihr das? Oder habe ich da grundsätzlich was nicht verstanden?

Da wirst du - wie so oft - mehrere Antworten bekommen. Meine:

- associatedStreet ist tot und sollte nicht verwendet oder gar erweitert werden.
- das "Karsruher Schema" ist "State of the Art", also etabliert und sollte bevorzugt werden.

Zum Karsruher Schema ist noch zu bemerken, daß in gut "vergrenzten" Gebieten - also dort wo die Grenzen komplett und sauber sind, addr:country und addr:city nicht mehr unbedingt benötigt werden. addr:street steht derzeit "auf der Kippe" und addr:postcode wird langsam auch angezweifelt.

Gruss
walter

Thomas8122 · 2014-02-23 15:23:31

wambacher wrote:

addr:street steht derzeit "auf der Kippe"

Ich glaube mit der Meinung bist du in der Minderheit.

wambacher · 2014-02-23 16:10:49

Thomas8122 wrote:

wambacher wrote:
addr:street steht derzeit "auf der Kippe"
Ich glaube mit der Meinung bist du in der Minderheit.

naja, Kippe ist etwas heftig - aber drüber diskutiert wird ab und zu schon mal.

Last edited by wambacher (2014-02-23 16:12:59)

seichter · 2014-02-23 17:32:57

wambacher wrote:

addr:street steht derzeit "auf der Kippe" und addr:postcode wird langsam auch angezweifelt

Auf addr:street wird man an Straßenkreuzungen wohl nie verzichten können, wenn man nicht aus Nachbarhausnummern extrapolieren will, was in Städten ziemlich verzwickt werden kann.
Bei addr:postcode bin ich bei der Überarbeitung der PLZ-Grenzen immer noch froh, wenn da wenigstens ein paar Einträge stehen. Gelegentlich gibt es nur ein, zwei "Irrläufer", die auf kilometerlange falsche Zuordnung einer Straßenseite hinweisen.

rayquaza · 2014-02-23 17:42:07

seichter wrote:

Auf addr:street wird man an Straßenkreuzungen wohl nie verzichten können, wenn man nicht aus Nachbarhausnummern extrapolieren will, was in Städten ziemlich verzwickt werden kann.

Sehe ich auch so: Ich lasse teilweise die Strassenangabe (egal ob mit "addr:street"=* oder associatedStreet) weg, weil ich nicht sicher sagen kann zu welcher Strasse ein Haus gehört. Da dürfte die Fehlerquote auch bei besseren Implementierungen nicht so toll sein.

Ich halte associatedStreet für die schönere der beiden Lösungen (weil weniger Redundanz) und nutze daher das, wenn ich eine Strasse zu einem grossen Teil mit Hausnummern versehe.

Basstoelpel · 2014-02-23 17:59:11

rayquaza wrote:

seichter wrote:
Auf addr:street wird man an Straßenkreuzungen wohl nie verzichten können, wenn man nicht aus Nachbarhausnummern extrapolieren will, was in Städten ziemlich verzwickt werden kann.
Sehe ich auch so: Ich lasse teilweise die Strassenangabe (egal ob mit "addr:street"=* oder associatedStreet) weg, weil ich nicht sicher sagen kann zu welcher Strasse ein Haus gehört. Da dürfte die Fehlerquote auch bei besseren Implementierungen nicht so toll sein.
Ich halte associatedStreet für die schönere der beiden Lösungen (weil weniger Redundanz) und nutze daher das, wenn ich eine Strasse zu einem grossen Teil mit Hausnummern versehe.

associatedStreet ist kein approved Feature.

Baßtölpel

wambacher · 2014-02-23 18:27:32

seichter wrote:

wambacher wrote:
addr:street steht derzeit "auf der Kippe" und addr:postcode wird langsam auch angezweifelt
Auf addr:street wird man an Straßenkreuzungen wohl nie verzichten können, wenn man nicht aus Nachbarhausnummern extrapolieren will, was in Städten ziemlich verzwickt werden kann.

Klar, da geht es wirklich nicht ohne addr:street.

Bei addr:postcode bin ich bei der Überarbeitung der PLZ-Grenzen immer noch froh, wenn da wenigstens ein paar Einträge stehen. Gelegentlich gibt es nur ein, zwei "Irrläufer", die auf kilometerlange falsche Zuordnung einer Straßenseite hinweisen.

da bin ich auch froh drüber, dass es die gibt.

Gruss
walter

Tordanik · 2014-02-23 18:37:34

Dimanche wrote:

Dadurch neugierig geworden habe ich mal nachgesehen was das Wiki dazu sagt. Unter anderem: „Prinzipiell sind diese jedoch für Software leichter und weniger fehleranfällig auszuwerten.“

Das ist kompletter Bullshit, für Software im Allgemeinen bringt das überhaupt nichts. Für manche Anwendungen ist es sogar praktischer, alle Informationen an einem Objekt zu haben (also eben gerade keine Relationen auswerten zu müssen).

Hat jemand überhaupt ein Beispiel für eine existierende Software, die von der Verwendung von associatedStreet statt addr:street profitiert?

Last edited by Tordanik (2014-02-23 18:38:08)

wegavision · 2014-02-23 18:42:12

Ein neuer Krieg der Relationen möge beginnen.

Ganz kurz die Argumente:
Adr:tags einfach, übersichtlich aber redundant, besonders wennjemand immer noch Stand-Land-Fluss hinzu fügt. (Auf Adr:street kann man schon ob der Übersichtlichkeit nicht verzichten, da an Ecken oft gleiche Hausnummern liegen)
Relation, genial weil man allen Elementen leicht Werte zuordnet, leider wird da aber kaum gemacht, sodass die Relation nur das übliche Stadt-Land-Fluss- Schema ergänzt und damit macht diese sich überflüssig. Andererseits stören die Relationen auch nicht, und man kann durch diese gut den Verlauf der Straße nachvollziehen und erkennen, ob man eine Hausnummer vergessen hat.

Gehrke · 2014-02-23 18:50:28

Ich bin da zerissen. Generell finde ich Relationen gut: weniger Redundanz, weniger Fehler. Ohne guten Tool-Support für die Eingabe und Auswertung bringt das hier jedoch wenig. Aber wenn man z.B. im Editor beim Hinzufügen einer Adresse die umliegenden Straßen als Auswahlbox angezeigt bekommt, könnte automatisch das Tagging per Relation passieren. Entweder eine neue Relation oder Hinzufügen zu bestehender. Na ja, passiert wohl nicht so bald.

EDIT: Kontroverse OT-Aussage entfernt.

Last edited by Gehrke (2014-02-23 19:16:26)

okilimu · 2014-02-23 19:52:02

Hallo,

ich unterstütze in meiner OSM-Hausnummernauswertung zwar praktisch die associatedStreet Zuordnungen von Hausnummernobjekten. Aber diese Relationsart wird in der osm2pgsql, die fürs rendern optimiert ist, nicht berücksichtigt. Nur sehr umständlich und inperformant können diese trotzdem ausgewertet werden. Da kann gerne gesagt werden, eine andere DB-Struktur wäre besser, aber auch die haben ihre Nachteile.

Die associatedStreet Relation ist nicht erforderlich, weil es das Karlsruhe Schema gibt. Ich persönlich finde den Einsatz von Relationen dann sinnvoll, wenn andere Arten nicht oder nur sehr schwierig gehen, also z.B. bei Multipolygonen, Verkehrsrouten oder Abbiegebeschränkungen.

"addr:street" habe ich bisher noch nirgendwo infrage gestellt gesehen. Ich unterstütze ein Hausnummerobjekt ohne addr:street nicht. Das Argument, die nächstgelegene Straße zu ermitteln, zählt für mich nicht als Argument. Eine auswertende Software hat wirklich einiges zu tun, aber auch noch das zu verlangen, finde ich nicht ok. Vom Aufwand abgesehen, ist die Ermittlung auch ggfs. nicht eindeutig und eine eindeutige Aussage nach dem Motto, bitte immer addr:housenumber und addr:street zu setzen, ist einfacher für alle Mapper, als zu differenzieren, wann evtl. addr:street auch entfallen könnte.

viele Grüße

Dietmar aka okilimu

Basstoelpel · 2014-02-23 19:59:03

Gestern oder heute erst gesehen: ein Gebäude, dreimal Hausnummer 1, aber drei unterschiedliche Straßen. Viel Glück, die alle richtig zuzuordnen. Mindestens zwei verschiedene Postleitzahlen waren's auch noch, sonst wäre es mir nicht aufgefallen.

Baßtölpel

Dimanche · 2014-02-23 21:59:03

Wen ich für mich das hier geschriebene zusammenfasse, komme ich zu dem Ergebnis:
Ein Relation stört nicht, aber Mappen nach dem Karlsruher Schema ist die bessere Variante.
Hier dann möglichst nur

addr:housenumber
addr:street
addr:postcode

nutzen.
addr:city und country nicht mehr.

Aber warum city und country nicht mehr? Gibt es hierzu vll. etwas im Wiki (möglichst deutsch, englisch kann ich nicht ), oder einen Thread hier? Zur Info und damit das Thema (city/country) hier nicht noch mal durchgekaut werden muss bzw. wird.

Danke

VlG

Gehrke · 2014-02-23 22:08:54

Dimanche wrote:

Aber warum city und country nicht mehr? Gibt es hierzu vll. etwas im Wiki

Im Wiki steht sowieso nicht, dass man diese Infos taggen muss. Was jedoch sinnvoll/wünschenswert ist, darüber gehen die Meinungen auseinander.
Ein Argument ist: Land, Gemeinde und auch PLZ kann man in DE weitgehend aus den Relationen für die Grenzen durch eine räumliche Abfrage ableiten.
Außerdem sollte durch den Kontext der Verwendung mindestens das Land meistens klar sein.
Das Gegenargument: Nicht immer steht die Möglichkeit einer räumlichen Abfrage zur Verfügung bzw. bei lokalen Exktrakten fehlen die Relationsdaten evetuell.

Bei lokalen Extrakten sind Land und Gemeinde meistens aus dem Kontext gegeben. Die PLZ, insb. in Großstädten, vielleicht nicht.

Last edited by Gehrke (2014-02-23 22:09:37)

JohnDoe23 · 2014-02-23 22:16:56

Dimanche wrote:

Aber warum city und country nicht mehr? Gibt es hierzu vll. etwas im Wiki (möglichst deutsch, englisch kann ich nicht ), oder einen Thread hier? Zur Info und damit das Thema (city/country) hier nicht noch mal durchgekaut werden muss bzw. wird.

Ich versuche es mal leicht verständlich zu erklären: Die Grenzen von Ländern und Gemeinden in Deutschland sind schon ziemlich genau erfasst. Hier z.B. die von Deutschland: https://www.openstreetmap.org/relation/51477 Achtung: das Laden dauert etwas länger.

Aus diesen Grenzen kann man relativ einfach berechnen, in welcher Stadt/Land eine Adresse liegt. Man braucht daher city/country nicht mehr erfassen, da dies eine redundante Information wäre.

Die PLZ-Grenzen sind auch schon einigermaßen genau erfasst (Ausnahme: größere Städte mit mehreren PLZ), also muss man diese auch nicht mehr unbedingt eingeben. Besser wäre es, die PLZ-Grenze zu korrigieren, falls diese nicht stimmen sollte.

Last edited by JohnDoe23 (2014-02-24 02:00:13)

Dimanche · 2014-02-23 22:55:04

Danke für die Info, Gehrke und JohnDoe23. Man (ich) lernt immer noch was dazu.

VlG Günther

geri-oc · 2014-02-24 09:37:13

Dimanche wrote:

...
Aber warum city und country nicht mehr? Gibt es hierzu vll. etwas im Wiki (möglichst deutsch, englisch kann ich nicht ), oder einen Thread hier? Zur Info und damit das Thema (city/country) hier nicht noch mal durchgekaut werden muss bzw. wird.
...

Ich bin dafür an einen POI alle addr:* zu setzen.
Bei einer Suche wird es komplett angezeigt. Man sollte auch den "einfachen" Dingen ihren Bestand lassen!

Welche PLZ hat dieser Frisör?

Hier ist alles in "einem"

Und wieso wird auf einmal alles geändert -> addr:postcode=* und addr:country=* entfernt?

Dann sieht es z.B. so (ohne komplette Adresse) aus

Nadjita · 2014-02-24 11:15:35

geri-oc wrote:

Ich bin dafür an einen POI alle addr:* zu setzen.
Bei einer Suche wird es komplett angezeigt. Man sollte auch den "einfachen" Dingen ihren Bestand lassen!

Wird es auch ohne vollstädige addr:-Daten. Bei einer Suche nach „Bettinas Haarstudio, Erding“ ist das Resultat:

Frisör Bettina's Haarstudio, 20, Wendelsteinstraße, Altenerding, Erding, Landkreis Erding, Oberbayern, Bayern, 85435, Deutschland, Europäische Union

Präziser geht's doch gar nicht. Die Darstellung des Nodes selbst ist dann doch eher Geschmacksfrage und momentan stehen eben nur die explizit vergebenen Tags dran, was nicht heißt, dass man's nicht ändern könnte.

Entfernen würde ich addr:-Tags allerdings nur dann, wenn sie wirklich falsch sind, nicht, wenn ich sie für redundant halte.

geri-oc · 2014-02-24 15:12:20

Dann fehlt die "komplette" Adresse:

http://www.openlinkmap.org/?lat=48.2880 … &type=node

und zum Einbinden auf der Website:

Nadjita · 2014-02-24 19:09:30

Ja schon, aber es ist ja Sache des Renderers, dass er sie nicht darstellt. Nominatim zeigt ja, dass man sie bekommen kann.

Dieser Diskussionsstrang hat aber nichts mit dem eigentlichen Thema zu tun und sollte besser separat weitergeführt werden.

Last edited by Nadjita (2014-02-24 19:11:17)

dooley · 2018-12-22 12:23:31

Ich grab die Leiche aus Gründen mal aus...

okilimu wrote:

associatedStreet Zuordnungen von Hausnummernobjekten. Aber diese Relationsart wird in der osm2pgsql, die fürs rendern
optimiert ist, nicht berücksichtigt.

Diesbezüglich hat sich seither in osm2pgsql wohl nichts geändert? Zumindest im default.style mit output psql oder gazetter werden die Relationstags nicht auf die Objekte übertragen. Kann man den [osm2pgsql].style ändern, damit diese Relationen aufgelöst werden?

Wenn nicht, wie kommt man ausgehend vom Relationsmember https://www.openstreetmap.org/way/38402 … 44/8.85417 zu der Relation https://www.openstreetmap.org/relation/ … 83/8.85655, auf maschinellem Wege natürlich?

mmd · 2018-12-22 15:29:42

dooley wrote:

Kann man den [osm2pgsql].style ändern, damit diese Relationen aufgelöst werden?

Also im Lua-Teil ist nur eine Logik drin, die Tags vom Way auf die Relation überträgt, aber nicht umgekehrt. Scheint wohl nicht zu funktionieren.

dooley wrote:

auf maschinellem Wege

Wo und wie soll das denn erfolgen? SELECT mit INNER JOIN zwischen Way-Ids und Relation-Members mit Typ "Way" wäre wohl zu offensichtlich, um danach zu fragen. Nominatim macht sowas in der Richtung, am besten mal den den Sourcen nach "associatedStreet" suchen.

Last edited by mmd (2018-12-22 15:32:02)

dooley · 2018-12-22 16:53:40

mmd wrote:

Wo und wie soll das denn erfolgen? SELECT mit INNER JOIN zwischen Way-Ids und Relation-Members mit Typ "Way" wäre wohl zu offensichtlich, um danach zu fragen. Nominatim macht sowas in der Richtung, am besten mal den den Sourcen nach "associatedStreet" suchen.

Wenn man denn was zum joinen hätte. Leider werden die type=associatedStreet von osm2pgsql zumindest in Richtung Relation > Objekt nicht berücksichtigt, da landet kein Byte von der Relation in der Datenbank, d.h. ich muß die Relationen separat in die Datenbank bringen. Wenn osm2pgsql die Relationen auflösen würde, könnte ich miŕ das sparen.

mmd · 2018-12-22 17:05:05

Damit das mit Nominatim funktioniert, gibt's im Gazetteer backend von osm2pgsql noch eine eigene Logik für associatedStreet. Zum Rendern sind die aS-Relationen für das normale Backend ja eher uninteressant. Vielleicht hilft da etwas eigenes Coding mit libosmium/pyosmium oder so.

Last edited by mmd (2018-12-22 17:05:32)

Announcement

#1 2014-02-23 14:51:23

Relation:associatedStreet

#2 2014-02-23 15:07:50

Re: Relation:associatedStreet

#3 2014-02-23 15:23:31

Re: Relation:associatedStreet

#4 2014-02-23 16:10:49

Re: Relation:associatedStreet

#5 2014-02-23 17:32:57

Re: Relation:associatedStreet

#6 2014-02-23 17:42:07

Re: Relation:associatedStreet

#7 2014-02-23 17:59:11

Re: Relation:associatedStreet

#8 2014-02-23 18:27:32

Re: Relation:associatedStreet

#9 2014-02-23 18:37:34

Re: Relation:associatedStreet

#10 2014-02-23 18:42:12

Re: Relation:associatedStreet

#11 2014-02-23 18:50:28

Re: Relation:associatedStreet

#12 2014-02-23 19:52:02

Re: Relation:associatedStreet

#13 2014-02-23 19:59:03

Re: Relation:associatedStreet

#14 2014-02-23 21:59:03

Re: Relation:associatedStreet

#15 2014-02-23 22:08:54

Re: Relation:associatedStreet

#16 2014-02-23 22:16:56

Re: Relation:associatedStreet

#17 2014-02-23 22:55:04

Re: Relation:associatedStreet

#18 2014-02-24 09:37:13

Re: Relation:associatedStreet

#19 2014-02-24 11:15:35

Re: Relation:associatedStreet

#20 2014-02-24 15:12:20

Re: Relation:associatedStreet

#21 2014-02-24 19:09:30

Re: Relation:associatedStreet

#22 2018-12-22 12:23:31

Re: Relation:associatedStreet

#23 2018-12-22 15:29:42

Re: Relation:associatedStreet

#24 2018-12-22 16:53:40

Re: Relation:associatedStreet

#25 2018-12-22 17:05:05

Re: Relation:associatedStreet

Board footer