Überarbeitung der place-Nodes Deutschland

+1

Würde ich mal so drastisch nicht ausdrücken. Man sollte nur nicht vergessen, das das deutsche OSM sicher zu den bestgepflegtesten gehört, was boundary angeht. Die Ortsnodes stammen natürlich aus vergangenen Jahren und sind immer noch vielerorts nicht günstig platziert, unvollständig und nicht eindeutig z.B. als Ortsteil einer Gemeinde spezifiziert. Da viele Mapper (auch im Ausland) evtl. unser deutsches Tagging als Vorgabe betrachten könnten (Vermutung), wäre es bestimmt nicht gut, die Ortsnodes “abzuspecken”, die noch vor wenigen Jahren Standard waren. Wir in Deutschland sollten nicht so “hochnäsig” sein, und einleuchtendes Standard-Tagging einfach umbauen. Viele Mapper sind froh um solche Strohhalme.

Österreicher belehrt Deutsche im Deutschen Forum. Die Emotionen gehen hoch.
Ich denke wir sprechen in unseren Sprachfarben aneinander vorbei, haben aber als OSM Mitwirkende sicher mehr Gemeinsamkeiten als trennendes.

@Rogehm: Was genau haben an den Grenzrelationen sauber abgeschlossene Straßen mit dem Vorhandensein oder Nichtvorhandensein von is_in an place-Nodes zu tun? Da hätte ich gerne eine einleuchtende Erklärung - wie man da einen Zusammenhang herstellen kann, ist mir nicht klar.

Dass man die is_in dort nicht entfernt, wo man auf andere Weise nicht an die Daten kommt (also keine Redundanz gegeben ist), ist ja klar.

“auf andere Weise nicht drankommt”: Das ist etwas, was mich etwas stört, das man nicht auf “Mausklick” in den Editoren dran kommt. Da wünsche ich mir in JOSM (und ID, Potlach, …) einen Button, der mir dann anzeigt was “unter” dem mich interessierenden Punkt liegt. Ähnlich dem “?” auf openstreetmap mit den “umschließende Objekte”. Aber das ist ein anderes Thema.

Das kann der Editor allerdings erst dann ermitteln, wenn er die betreffende umgebende Grenzrelation auch vollständig im Speicher hat. Wenn er keine Onlinequellen anzapfen will.

–ks

Der Kern von OSM ist eine DB, aber OSM ist mehr. Dazu gehören auch die vielen Auswerte- und Renderprogramme (Karten).
Erst sie machen aus einem Datenhaufen ein für viele attraktives System.

Redundanz ist für eine DB eine potentielle Quelle von Inkonsistenz und daher zu vermeiden, bei einem kooperativem Projekt ohne zentrale Steuerung ist Normalisierung aber Illusion.

Redundanz hat auch eine zweite Seite: Der einfachere Zugriff auf Information, wenn nur Teile der DB (sprich: kleiner Ausschnitt) geladen sind. Ein Beispiel dafür ist die vollständige Postadresse an einem POI, die die Regel ist.
Hausnummer ist unumstritten, aber schon bei der Straße gehen die Redundanzprobleme los. Eckhäuser können meist nicht automatisch einer Straße zugeordnet werden, aber Straßenname am way und am POI können auseinanderlaufen.

Ich halte das is_in-Tagging auch für überholt und verwende es nie. Löschen würde ich es aber nur, wenn es dafür einen allgemeinen Konsens (siehe landuse=farm) gibt und gewährleistet ist, dass keine Information vernichtet wird.

Adressen…

Die Zugehörigkeit des Straßennames (wie auch der Postleitzahlen) kann man nicht immer eindeutig durch spatiale Abfragen feststellen.


A                     B
A ------------------- B
A |                 | B
A |                 | B
A |                 | B
A |   Grundstück    | B
A |                 | B
A |                 | B
A | Haus            | B
A |                 | B
A |                 | B
A ------------------- B
A                     B

Gehört das Haus zur Straße A oder zur Straße B? Eine Bestimmung durch spatiale Abfragen ergibt Straße A, es gehört aber zu Straße B. Daher ist der Straßenname zwar redundant, dieser ist aber nicht entbehrlich, weil keine eindeutige Zuordnung gegeben ist. Die Redundanz hier ließe sich nur vermeiden, indem man die Adressen per Relation an die Straße hängt. Bei Straßen mag das noch praktikabel sein, bei Postleitzahlen nicht mehr (im Sinne vom Handling in den Editoren). Von daher gibt es nicht immer den Königsweg.

Es ist wie immer im Leben, man muß abwägen. Stumpf “überflüssiges” zu löschen, halte auch ich für falsch.

Ich kenne übrigens keinen Renderer oder ein Auswerteprogramm, welches “is_in” auswertet, das dürfte ohne größere Verrenkungen auch ziemlich schwierig sein. Eine Verifizierung ist AFAIK im Moment nur durch manuelle Sichtung möglich.

Moin,

ihr könne ja mal folgende Query probieren, die alle Knoten mit is_in Tags anzeigt. Zusätzliches wird auch ein is_in_boundary-Tag mit ausgegeben, das die is_in auf Basis der existierenden administrativen Grenzen direkt ermittelt. Einfach um mal eine Idee dafür zu bekommen, wie redundant is_in wirklich ist.

http://overpass-turbo.eu/s/p6D

Beispiel


  <node id="260440481">
    <tag k="is_in" v="Großostheim"/>
    <tag k="name" v="Pflaumheim"/>
    <tag k="place" v="village"/>
    <tag k="postal_code" v="63762"/>
    <tag k="is_in_boundary" v="{2:Deutschland};{4:Bayern};{5:Unterfranken};{6:Landkreis Aschaffenburg};{8:Großostheim}"/>
  </node>

Was hat das jetzt mit Österreicher und Deutschen zu tun? Haben wir jetzt etwa rassistische Vorurteile schon zwischen D und AT? Oder will jemand umgekehrt „den Deutschen“ generell solche Vorurteile unterstellen? Das ist doch alles Unsinn. Ich (als Deutscher) lasse mich sehr gerne von einem Österreicher, Syrer, Nigerianer, Inuit, … belehren, wenn derjenige es eben besser weiß als ich; ich würde mich aber nicht gerne von Personen belehren lassen, die es nicht besser wissen (auch nicht, wenn diese Personen Deutsche sind).

Ich verstehe Ortsnodes als Notnagel in Gegenden wo es keine Bounderies gibt. Falls das deutsche OSM Vorbild ist, dann sollte es die Ortsnodes “abspecken” und nur da belassen, wo es keine Bounderies gibt. Den Bounderies + Ortsnodes ist nicht vorbildlich.

Außerdem sollte im Wiki dargestellt warden, dass es eine Priorisierung zwischen Ortsnodes und Boundaries gibt.

Ich habe da ein Verstaendnis Problem: Aus meiner Sicht kann ich unmoeglich jede “Ortschaft” als 2D-Objekt mit Hilfe von Boundaries abbilden!?

Meiner Vermutung nach ist in AT die kleinste in OSM [EDIT: als 2D-Objekt] umgesetzte (und meiner Meinung nach sinnvolle) Einheit die Gemeinde, welche aber durchaus aus mehreren Ortschaften (teilweise Kaffs, die aus drei Haeuserln bestehen) bestehen. Diese Ortschaften haben alle Place-Nodes und ich haette keine Ahnung, wie ich daraus ein sinnvolles Flaechenobjekt machen koennte - wo verlaufen die Grenzen genau? Das waere kompliziert.

War hier auf Besuch:
http://www.openstreetmap.org/search?query=Haindling%202b#map=16/48.8245/12.4026

Das ist in Deutschland, einfach zufaellig ein Kaff raus gepickt, dort werden auch Place Nodes verwendet.

Lg, Gppes

PS.: Mir sind Posting-Ursprungs-Nationen auch Wurscht! :slight_smile:

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?