Überarbeitung der place-Nodes Deutschland

+1 für das Löschen der openGeoDB:*-Einträge (wenn man drüberstolpert) an den place-Nodes, genauso wie das IMHO überflüssige is_in.

is_in finde ich alsbald überflüssig wenn in einer Region sämtliche Straßen an den Grenz Relationen sauber abgeschlossen sind.
Genau das habe ich in meinem Bezirk in den letzten Monaten erledigt. http://www.openstreetmap.org/way/150170796#map=18/47.51361/12.31580

**Einfach so “is_in” zu löschen, finde ich hingegen unverantwortlich. **

Redundanz führt früher oder später zu Inkonsistenz der Daten. OSM ist in erster Linie eine Datenbank. Daraus folgere ich, dass die Grundsätze von Datenbanken eingehalten werden sollten. So ziemlich das erste, was man als Datenbankler lernt, ist die Normalisierung der anfallenden Daten in die ersten Normalform, um eben Redundanz zu vermeiden.

Die Redundanz hier entsteht durch das Vorhandensein übergeordneter Ebenen (landuse, administrative Areas etc.). Für so ziemlich jeden place-Node kann durch spatiale Abfragen die übergeordnete Ebene festgestellt werden. Und genau diese werden auch gepflegt (Namensänderungen etc.) - wer denkt daran, die place-Nodes innerhalb entsprechend zu durchsuchen und ggf. die is_in zu ändern? Und schon haben wir unnötigerweise inkonsistene Daten.

**Daher finde ich es in keiner Weise unverantwortlich, is_in zu entfernen. **

Allein Datenbank? Dem muss ich wiedersprechen. OpenStreetMap ist in erstere Linie ein Kollaboratives Projekt. Datentechnik dient der Unterstützung und ist keinesfalls Selbstzweck.
Wie unterstützende Werkzeuge -nur ein kleiner Auszug:- https://tools.geofabrik.de/, oder http://regio-osm.de/, https://thomaskonrad.at/ eindrucksvoll belegen, liegt die Hauptarbeit Tausender Mapper immer noch im Erfassen von Daten, hingegen bereits wenige Kontrollwerkzeuge genügen um Redundanzen im Zaum zu halten.

Du möchtest also die “Schafherde” der Mapper wegrationalisieren, weil Du eine schöne Datenbank möchtest.

Datenbanken füllen sich nicht von selbst.

Wer hat das wann gesagt? Kennst du einen einzigen Mapper, der sagt: „Och, wenn ich kein is_in mehr setzen darf, dann mache ich nicht mehr mit“?
Bitte keine Strohmänner aufbauen.

–ks

Mit Verlaub, das ist Bullshit. Ich möchte konsistente Daten und keinen Datenmüll. Und das wars dann auch mit der Diskutiererei mit dir, diese Unterstellungen brauche ich mir nicht anzutun.

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