Überarbeitung der place-Nodes Deutschland

Ich möchte gern mit euch über eine Überarbeitung der place-Nodes (Ortspunkte) in Deutschland diskutieren. Meiner Meinung nach fehlt es dort an einer einheitlichen, vollständigen Grundstruktur und allgemeine Aufmerksamkeit, denn ich finde hier steckt für eine konsistente Weiterverarbeitung/Verwendbarkeit viel Potential.

1.) postal_code aus allen place-Nodes entfernen

Dieses müsste ansonsten flächendeckend (alle place-Nodes) sauber gepflegt werden, da bspw. Nominatim dieses tag dem PLZ-Gebiet vorzieht. Daher kommt es in vielen Fällen dazu das die PLZ der nächsten Ortslage, welche natürlich nicht zwingend die richtige sein muss, dem Suchergebnis zugeordnet wird.

Nach meiner Analyse liefern etliche Suchabfragen fehlerhafte oder irreführende Ergebnisse, welche jedoch nach Entfernung des postal_code-tags nicht mehr auftreten würden, da dann das zugrunde liegende PLZ-Gebiet ausgeliefert würde.

Nach meiner Auswertung betrifft es ungefähr 8000 place-Nodes => hier ein fehlerhaftes Beispiel (Bad König)

In diesem Punkt bin ich sehr auf eure Meinung gespannt.

2.) openGeoDB:* Tags entfernen bzw. sauber einpflegen

Da brauch ich wohl nix zu sagen

Anregungen:

3.) place-tag korrekt zuordnen

Eine korrekte Filterung der Ortslagen von Deutschland, selbst mit den values => ‘city’ und ‘town’ ist grundsätzlich nicht möglich. Hier sind teilweise auch Dörfer oder Stadtteile als ‘Stadt’ gekennzeichnet.

4.) wenn place-Node zentraler Ort einer Administration (bspw. einer Gemeinde) ist, diesen dort zuweisen (gutes Beispiel - Contra)

Keine Centroid-Funktion kann bspw. den wirklichen Ortsmittelpunkt/-kern einer Gemeinde bestimmen - damit wäre Abhilfe geschaffen.

Ich würde mich freuen wenn ich wenigstens etwas Anregung verschafft habe und bei wesentlichen Punkten (der tag-Entfernungen) zu einem Ergebnis kommen könnten. Und vielleicht hat der ein oder andere noch weitere Vorschläge.

Das postal_code=-Tag brauchen wir in Deutschland m. E. gar nicht mehr, seit wir flächendeckende postal_code-Relationen haben, die ganz Deutschland abdecken. Das kann nicht nur aus place-nodes raus, sondern auch aus allen Straßen (gibt hier und da ein paar die noch ein postal_code-Tag haben).

Die Entfernung der openGeoDB-Tags wurde bereits zuvor im Forum beschlossen. Die Dinger werden weder genutzt noch gewartet.

Sollte man dann nicht das Wiki updaten?
http://wiki.openstreetmap.org/wiki/OpenGeoDB

Gilt das nur fuer Deutschland?

Also meine Wenigkeit würde eine solche Überarbeitung sehr begrüßen. Allerdings bin ich nur ein einfacher Mapper ohne besondere Erfahrung mit der Verarbeitung dieser Daten; dazu müssen sich also die kompetenten Experten äußern.

Nur “im Forum” reicht nicht. Gabs da auf den Mailinglisten auch was?

Versteht mich nicht falsch, ich brauch die Tags auch nicht und sie stören mich. Aber wenn wir sie rausnehmen wollen, dann richtig.

Die Thematik wurde ebenso im AT Forum, aber bereits als Feststelltung!: “im deutschen Forum gibt es den Standpunkt, dass OpenGeoDB obsolet ist” gepostet: https://forum.openstreetmap.org/viewtopic.php?pid=645973#p645973

Hier im DE Forum finde ich kleine Feststellung dieser Art.

Sofern wir aus allen Place Nodes wirklich den Tag Postleitzahl entfernen, so könnten wir ebenso auch den Gemeindenamen entfernen, denn dieser ergibt sich sogar besser als die Postleitzahl aus der Admin Relation.

Der Editor ID wäre dann überflüssig denn wenn der kleine Mapper anschließend auf www.osm.org eine Objektabfrage startet, -Beispiel einer einfachen Objekabfrage: http://www.openstreetmap.org/way/288266054#map=18/47.52594/12.39909-, dann bekommt er künftig keine vollständige Adresse mehr geliefert. Das macht die Bürgerbeteiligung kaputt.

Mein Fazit:
Nachdem wie oben beschrieben eine einfache Datenbankabfrage ein brauchbares Fehlerbild liefert, so kann man eine solche Abfrage auch als Korrekturgrundlage nutzen. PLZ Fehler kann man relativ einfach mittels Datenbankabfrage identifizieren und mit sehr geringem Aufwand bereinigen. Ein globales Entfernen von PLZ Zahlen verhindert übrigens nicht dass der kleiner OSM User, später solche Elemente nicht doch wieder hinzufügt.

Daher Nodes sollten möglichst vollständig alle Elemente eines Objektes beinhalten, das Entfernen von Postleitzahlen schadet dem OSM als kollaboratives Projekt, und ist daher strikt abzulehnen.

Sollte ich das missverstaendlich geschrieben haben, so tut mir das sehr leid. Ich meinte damit einfach nur, dass es den Standpunkt gibt und wollte nicht als Fuersprecher fuer das deutsche Forum auftreten, oder verkaufen wollen, dass alle im deutschen Forum so denken. Ich hatte ja sogar auf diesen Thread hier verlinkt.

Auch wenn ich geocodecs Thread “Wozu OSM” gerne gelesen habe, moechte ich diese (derzeit im AT Forum kaum vorhandene Diskussion) gerne in (m)einem eigenstaendigen Thread belassen.

Sofern jemand eine geoDatenbank ohne Redundanzen möchte, so kann er gerne einen Abzug von OSM nehmen und daraus mit Verweis auf “Datenteile entnommen aus OSM” sein eigenes propreitäre Geo-Projekt weiterentwickeln.

Jetzt aber OSM zu biegen und für den kleinen Mapper dadurch kaputt zu machen, und sich dann später wenn es keinen einzigen kleinen Mapper mehr gibt, in eine Abspaltung zu vertschüssen, halte ich für unfair.

In https://forum.openstreetmap.org/viewtopic.php?id=17293 hat mindestens keiner groß widersprochen.

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