Relation:associatedStreet

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

wambacher wrote:

addr:street steht derzeit "auf der Kippe"

Ich glaube mit der Meinung bist du in der Minderheit.

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.

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.

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.

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

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

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?

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.

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

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

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

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

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.

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.

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

VlG Günther

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

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.

Dann fehlt die "komplette" Adresse:

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

und zum Einbinden auf der Website:

<iframe width="420" height="350" frameborder="0" scrolling="no" marginheight="0" marginwidth="0" src="http://www.openlinkmap.org/embed.php?id=2473398678&type=node" style="border: 1px solid black"></iframe>

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.

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?

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.

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.

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.

Es gibt aber sicherlich noch andere Tools, die das schon machen, z.B. https://github.com/britiger/osm_address_db (nicht ausprobiert, gerade nur einen FOSSGIS Talk auf YouTube gefunden).

Dafür, dass dieser Relationstyp tot ist, macht ihr euch wirklich (zu) viele Gedanken.

Gruss
walter

Entweder der Gazetter funktioniert nicht in die gewünsche Richtung oder ich muß noch am Aufruf was ändern...

Das hier https://www.openstreetmap.org/way/387992297 ist ein Member von https://www.openstreetmap.org/relation/5781148.

Der Extrakt wurde mit

osm2pgsql␣--create␣--unlogged␣--prefix␣gazetteer_regbez_freiburg␣--hstore␣--latlong␣-d␣gis␣-P␣5433␣--output␣gazetteer␣freiburg-regbez-latest.osm.pbf

importiert.

SELECT␣osm_id,␣osm_type,␣class,␣type,␣name,␣admin_level,␣address,␣extratags
FROM␣public.place
WHERE␣osm_id␣IN␣(/*member␣house*/␣387992297,␣/*␣relation␣*/␣5781148,␣/*member␣street␣*/␣300804148);

300804148;W;highway;residential;"name"=>"Mühlewiesweg";15;<NULL>;<NULL>
387992297;W;building;yes;<NULL>;15;"housenumber"=>"1";<NULL>

Wie man sieht, sieht man unerwartetes - auch hier gibt es keinerlei Verbindung von der Relation zu den Members. Ich hätte jetzt erwartet, dass der Gazetter beim zweiten Record (387992297) die relevanten vorhandenen tags aus der Relation ergänzt:

<relation␣id="5781148"␣version="2"␣timestamp="2015-12-27T07:46:08Z">
<member␣type="way"␣ref="300804148"␣role="street"/>
<member␣type="way"␣ref="387992297"␣role="house"/>
...
<member␣type="way"␣ref="387809106"␣role="house"/>
<tag␣k="name"␣v="Mühlewiesweg"/>
<tag␣k="type"␣v="associatedStreet"/>
<tag␣k="addr:city"␣v="Emmingen"/>
<tag␣k="addr:country"␣v="DE"/>
<tag␣k="addr:postcode"␣v="78576"/>
</relation>

Damit hätte man für das Gebäude eine komplette Adresse statt nur die Hausnummer.

Aber egal, ich werde die Relationen manuell importieren und schauen, wieviel Objekte überhaupt ergänzt werden müssen und können, erstmal mit dem kleinen Extrakt, damit ich abschätzen kann, ob sich das für Gesamt-Deutschland auch lohnt...

wambacher wrote:

Dafür, dass dieser Relationstyp tot ist, macht ihr euch wirklich (zu) viele Gedanken.

Er ist nicht tot, leider. Ich schätzte, dass wir deutschlandweit mehrere 100.000 Adressen haben, die nur aus Hausnummern bestehen und der Rest der Adresse superumständlich aus der Relation zu ermitteln ist.
Auflösen tut die ja auch keiner, wenn ich mir so manchen timestamp anschaue:

<relation␣id="49853"␣version="11"␣timestamp="2018-08-22T12:54:01Z">

Allein im Regierungsbezirk Freiburg haben wir aktuell 5.158 associatedStreets-Relationen mit 87.056 house-Members. Rechne das auf Deutschland hoch...

Edit: Vielleicht wäre das ein Anlass für eine konzentrierte Aktion, diese "toten" Relationen so langsam loszuwerden 😄

dooley wrote:

Allein im Regierungsbezirk Freiburg haben wir aktuell 5.158 associatedStreets-Relationen mit 87.056 house-Members. Rechne das auf Deutschland hoch...

Nach meiner Erfahrung gibt es nur einige isolierte Inseln, in denen associatedStreet besonders verbreitet ist - neben Südbaden nach meiner Erinnerung noch der Vogelsberg in Hessen.

dooley wrote:

Edit: Vielleicht wäre das ein Anlass für eine konzentrierte Aktion, diese "toten" Relationen so langsam loszuwerden

Die Idee gab's schon vor 4 Jahren: https://wiki.openstreetmap.org/wiki/Tal … atedStreet

Jedesmal tauchen dann irgendwelche Datenbank-Normalisierungs-Verfechter auf, und blockieren die Aktion. Dass diese Relationen praktisch unwartbar und oft unvollständig sind, spielt dabei eine eher untergeordnete Rolle.

Bei den Nachbarn in Frankreich sind die Dinger auch recht beliebt, allerdings stammen die zum großen Teil aus irgendwelchen automatisierten Importen. Freiwillig würde sich das sonst wohl kaum jemand antun.

Prince Kassad wrote:

Nach meiner Erfahrung gibt es nur einige isolierte Inseln, in denen associatedStreet besonders verbreitet is

der Ostberliner Raum hat auch noch einige... http://tools.geofabrik.de/osmi/?view=ar … _tags,ways

Sven

mmd wrote:

Jedesmal tauchen dann irgendwelche Datenbank-Normalisierungs-Verfechter auf, und blockieren die Aktion. Dass diese Relationen praktisch unwartbar und oft unvollständig sind, spielt dabei eine eher untergeordnete Rolle.

Man kann die Tags doch von Hand redundant auf die Hausadressen verteilen, dann sind sie für die Auswerter bequem erreichbar.
Die Relationen muss man nicht zwingend löschen, sie werden halt veralternder Datenschrott, der irgendwann (je nach Gegend) widerstandslos entsorgt werden kann.
Die Stadt Freiburg ist übrigens eine aS-Hochburg.

seichter wrote:

Die Relationen muss man nicht zwingend löschen, sie werden halt veralternder Datenschrott, der irgendwann (je nach Gegend) widerstandslos entsorgt werden kann.

Widerspruch: Konvertieren ja - aber bitte den alten Schrott dann sofort löschen.

Gruss
walter

wambacher wrote:

Widerspruch: Konvertieren ja - aber bitte den alten Schrott dann sofort löschen.
walter

+1
Ich habe das vor Jahren auch mal für mkgmap programmtechnisch auseinandergedröselt. Es gibt leider diverse Varianten, wo in der Relation ein Straßenname drinsteht und in den Members irgendwelche Varianten davon. Ist dann das reine Kaffeesatzlesen, wenn man keine CS Infos hat. Also wenn auflösen, dann auch Rel entfernen.