Überarbeitung der place-Nodes Deutschland

Das ist eine ganz hervorragende overpass-Abfrage, vielen Dank dafür!

Manche sind der Auffassung, dass sämtliche Ortschaften auch eine Grenze haben müssen, egal wie klein sie sind. Das führt dann zu fiktiven Grenzziehungen wie hier: https://www.openstreetmap.org/#map=13/51.8690/11.8647.
Wer hier Aufräum-Versuche unternimmt hat nicht nur enorm viel Arbeit, sondern muß sich hinterher auch noch für das von ihm verursachte Ortsteilgrenzen-Massensterben verantworten.

+1

Das ist ein sehr deutliches Beispiel fuer mein Empfinden zu diesem Thema! Hatte ich ja gar nicht geschrieben. Areas sind natuerlich immer wesentlich komplexer!

Lg, Gppes

PS.: Sorry mein Beispiel mit den Place-nodes:
http://www.openstreetmap.org/#map=16/48.8249/12.4054
sollte das hier sein, habe nur gleich eine Nominatim-Suche auf eine angrenzende Adresse getestet.

PPS.: Off topic (Areas, Ways, Nodes): Auch wegen der Komplexitaet predige ich fuer den Einsatz von “natural=tree_row” anstatt ein “natural=wood” oder “landuse=forest” um eine einzelne Baumreihe zu “wickeln”. Im Area-Fall kommen dann auch oft sehr interessante oder komplexe Gebilde raus!

Ja und? Wenn’s keine Bounderies gibt (weil nicht sinnvoll erstellbar) nimmt man halt place. Aber ich halte es für nicht sinnvoll place und boundaries gleichzeitig zu verwenden.

Ach so war das gemeint. Alles klar.

Ich habe auf nominatim einen Bugreport erstellt, weil manche Adressen mit address:place nicht gefunden werden. Als Loesung wurde mir unter anderem vorgeschlagen, eine 2D boundary zu machen. Deshalb die Detailfrage. Genau dort macht es aus meiner Sicht naemlich auch keinen Sinn.

Darum geht es ja jetzt eben nicht, aus place-Nodes place-Boundaries zu machen. Es geht darum, dass die place-Nodes einen key “is_in” haben, der durch geeignete Abfragen der umgebenden Grenzen praktisch überflüssig ist, sofern diese vorhanden sind. @mmd hat eine Overpass-Abfrage zur Verfügung gestellt, mit der man sehr schön nachschauen kann, ob is_in überflüssig ist oder nicht.

is_in hat keinerlei Aussagewert (zumindest für Ortsfremde), weil man nicht ohne weiteres feststellen kann, um was es sich bei den Buchstabenfolgen handelt. Beispiel Saladorf in Niederösterreich:


<tag k="is_in" v="Würmla,Tulln,Niederösterreich,Österreich,Europe"/>
<tag k="name" v="Saladorf"/>

Was sagt der Inhalt von is_in aus? Saladorf gehört anscheinend u.a. zu Würmla. Was aber ist Wümla? Ein Regierungsbezirk, eine Stadt, ein Stadtteil, ein Bundesland? Ich kann das nicht sagen, weil ich mich in Österreich nicht auskenne.

Mit einer spatialen Abfrage, z.B. https://overpass-turbo.eu/s/p6U (1) bekommt man Auskunft (aufgedröseltes is_in_boundaries):


administrativer Level 8: Gemeinde Würmla
administrativer Level 6: Bezirk Tulln
administrativer Level 4: Niederösterreich
administrativer Level 2: Österreich

Wenn ich jetzt noch weiß, was die einzelnen administrativen Level in dem jeweiligen Staat/Bundesland bedeuten, kann ich damit wirklich etwas anfangen. Mit der reinen Aufzählung von Namen in is_in nicht.

(1) overpass-Query von mmd erweitert, so das nur places mit is_in berüchsichtigt werden.

Danke fuer die Erklaerungen, der Link funktioniert bei mir nicht, ich kriege nur ein Beispiel mit Trinkwasserspendern in Rom!?

Puh… ist dachte schon bei mir ist was…

irgendwas ist bei overpass Turbo… die zuletzt eingegebene Abfrage wird ausgeführt… hhab es gerade manuell getestet… über wizard landuse=forest ausgeführt, Tab mit Overpass-Abfrage geschlossen, Link angeklickt, diese eben durchgeführte Abfrage kam wieder…

Sven

Hm, hab den Link eben nochmal aufgerufen, bei mir gehts… Sollte irgendwo westlich Wien rauskommen, das spielt aber auch keine Rolle. Die Karte an den gewünschten Ort schieben und die Abfrage ausführen, das sollte gehen?

node({{bbox}})[is_in][place];
  foreach(
    is_in->.a;
    area.a[name][boundary=administrative][admin_level~"^[2-8]$"] -> .a;
    convert node ::=::,
              ::id = id(),
              is_in_boundary =a.set("{" + t[admin_level] + ":" + t[name] + "}");
   
    out;
  );

Habt ihr zufällig NoScript installiert?

ja… hatte damit eigentlich nie Probleme…

Gibt es eine spezielle Regel? Die Seiten overpass.turbo.eu und overpass-api.de sind jedenfalls auf der Positiv-Liste.

Sven

Also seit ein paar Tagen habe ich auch massiv Probleme damit, ich weiß allerdings noch nicht genau was da los ist. Evtl schlägt die xss Protection da zu. Mit Chrome klappts aber.

anscheinend ja… habe den Haken bei “Anfragen bei Verdacht auf Cross-Site Scripting bereinigen” rausgenommen, nun kommt der Link in Niederösterreich raus…

Sven

place ist doch ganz sinnvoll um manuell das siedlungsortszentrum für den renderer festzulegen. stell dir vor, eine gemeinde besteht aus 3/4 wald und 1/4 siedlung, das aber nur ganz im östlichen gemeindegebiet angesiedelt ist. wo würde auf der karte der gemeindename auftauchen, mitten im wald natürlich.

hier ein anderes beispiel wo im nördlichen bereich nur landwirtschaft ist und ganz im süden die eigentliche siedlung worum es geht:
https://www.openstreetmap.org/relation/1665293#map=12/52.4887/8.4509

in dem fall wo gemeinde gleich ort ist, muss das place node mit der rolle=admin_centre in die admin-relation. wäre hier auch name=* überflüssig und kommt aus der relation? wo das place-node nur eine ortsbeschreibende funktion hat steht es selbstständig.

ich glaub ich weiche gerade ein bisschen aus dem redestrang ab und mehr zusammenfassend zu dem thema

Für mich bedeutet
wenn künftig eine einfache Objektabfrage auf OSM.org nicht mehr sämtliche Elemente

einer normalen vollständigen Postadresse

liefert, dass das zugleich das Ende von OSM als Kollaboratives Projekt mit sich bringt.

Wer unbedingt und mit aller Gewalt OpenStreetMap zerstören möchte, der kann dieser Initiaitive folgen.

Dafür gibt es ja auch die Rolle label in der boundary-Relation. Prinzipiell kann man das place-Node als eben dieses label in die Relation mit reinnehmen.

Was willst Du uns damit sagen ?

Was meinst du damit? In DE findet man mit Nominatim (sämtliche eingetragene) Adressen mit vollständiger Postadresse.
Bin der Meinung, die “is_in”-tags sollte man nicht anrühren. Im mindesten Fall dient der Tag immer noch dazu, auf einfache Weise Geoinformationen zu erhalten, wenn man sich ( in DE!) für einen kleinen Ort oder einen Weiler interessiert und diesen in OSM direkt lokalisiert. Natürlich sind dies bessere Informationen, wenn die Boundaries unkorrekt sind (Sicher oft auf der Welt!). Aber die beiden Abfragen sollten deckungsgleich sein im optimalen Fall. Ich sehe dies als Gegenkontrolle. Man muss sich also nur kümmern bei Abweichungen.
Mit der Bitte, die “is_in” tags nicht zu löschen, sondern vielmehr zu korrigieren. Danke euch.

Das wäre nur dann logisch, wenn OSM dadurch für jeden Anwender komplett unbrauchbar würde – denn „Ende als kollaboratives Projekt“ kann doch nur bedeuten, dass es keine interessierte Community mehr gibt. Aber warum sollte es? OSM ist doch keine Adressdatenbank. Freilich ist es „nett“, gleich aus OSM alle Kontakt- und Adressdaten zu bekommen, wenn man sie mal haben möchte. Aber als Geodatenbank ist OSM für mich auch dann schon wertvoll, wenn ich „nur“ die Information, was da ist, sowie die Geoposition bekomme. Für vollständige Postadressen gibt es im Zeitalter ständig verfügbarer Datenanbindung andere Quellen, das ist in OSM für mich eher ein „nice to have“.

Für mich ist OSM deshalb wertvoll, weil ich überall, wo ich bin, sehen kann, wie meine Umgebung aussieht, wo die Straßen und Wege hinführen, und was da so angeboten wird. Für mich ist OSM wertvoll, weil ich in einer fremden Stadt, wenn sich mein Hund eine Pfote an einer Glasscherbe aufreißt (Idioten, die es sinnvoll finden, Bierflaschen auf Gehwegen zu zertrümmern und den Müll liegenzulassen, gibt es ja überall), in OsmAnd nach „Tierarzt“ suchen und mir dann auch gleich den Weg dahin anzeigen lassen kann. Dessen ladungsfähige Postadresse brauche ich dazu nicht, Länge und Breite reicht. Für mich ist OSM wertvoll, weil ich damit eine aktuelle Abbildung der baulichen und verkehrsmäßigen Strukturen in der Tasche habe, die es mir unschätzbar erleichtert, mich zurechtzufinden. Das ist für mich der Sinn einer Geodatenbank.

Das läuft auf „Wer anderer Meinung ist als ich, ist bösartig“ hinaus und darf wohl als radikale Ansicht bezeichnet werden. So was hätte ich eher von Pegida-Kundgebungen erwartet als hier im Forum.

–ks

Umkreissuche ist doch nett.

Auf meinem PC läuft ebenso eine hochwertige Esri Umgebung. Leider gibt es bei dieser einen lizenbedingtes Timeout, in OSM gelangt man daher jeweils um entscheidende Sekunden schneller in die geografische Übersicht. Ich habe übrigens noch nicht verstanden warum ich eine restriktive Lizenzbarriere für Trivial Abfragen hinnehmen soll.

Geschwindigkeit bedeutet, dass ich für Trivial-Abfragen nicht ganze Regionen in den Speicher laden möchte.
Auf lokaler Ebene hat sich gezeigt dass is_in gelegentlich das einzige Mittel ist, wie man gleichlautende Straßen zweier Ortschaften auseinanderhalten kann.