Boundaritis - wo soll das hinführen?

Wenn da ein Weg ist, gehört da ein highway=* hin, das ist klar. Und wenn das früher mal eine Bahnstrecke war, kann von mir aus auch railway=abandoned an den highway dran. Mir geht’s um die alten Ways, die als railway=abandoned jetzt mitten durch Häuser laufen und wirklich überhaupt nichts Sichtbarem mehr entsprechen.

–ks

Also ich glaube, wir sind uns einig dass so ein Schmarrn wie “Großherzogtum Baden” oder “Volksstaat Württemberg” raus kann? Nicht, dass jemand noch auf die Idee kommt und die Relation “Großdeutsches Reich” anlegt. Man kann nicht alle jemals existierenden Grenzen bis zur Römerzeit zurück anlegen, da hätten wir ein heilloses Durcheinander.

Aber der Limes bleibt drin?

–ks

Hallo Frederik,
grundsätzlich stimme ich dir zu, dass Beispiele, wie “Wasserwachteinsatzbereichsgrenzen” (boundary=rescue_unit; rescue=water_rescue) Anwenderdaten sind, die nicht nach OSM ausgelagert werden sollten.

Verwaltungsgrenzen hingegen in ihren Variationen sollten m.E. auf jeden Fall Teil der Datenbank sein. Insbesondere weil sie einfach auszulesen sind und sie für einen großen Anwender-/Auswerterkreis verwendbar und damit interessant sind. Ob ich definiere, dass Landkreis X aus den Gemeinden ABCD oder aber outer boundary ways abcd besteht, bleibt doch Geschmacksache, oder? Bei der von dir wohl favorisierten ersten Form, kann ich die größere Einheit (hier:Landkreis) aber erst bestimmen, wenn alle kleineren Einheiten (Orte) erfasst sind, bei der zweiten Definitionsform ist das nicht notwendig.

Dein Beispiel am Rhein als Wassergrenze ist ein Sonderfall, gerade hinsichtlich der von dir geforderten Verifizierbarkeit. Nähme ich dieses Kriterium ernst, dann würde deine Argumentation recht schwach:
So sind es z.B. im Spessart gerade die historischen Grenzen, die immer deutlicher sichtbar sind als neuere Grenzziehungen, nämlich in Form Jahrhunderte alter Grenzsteine. Die will keiner wirklich einzeln per Hand erfassen, obwohl am Wegesrand klar erkennbar.

Aus der Praxis: Wandere ich mit Osmand durch den Wald, genügt ein Blick aufs Handy um bei einer Reihe von Grenzsteinen oder einer Schneise zu erkennen, dass ich mich zwischen Gemarkung A und B bewege und das vielleicht der Grund für die unterschiedliche Bepflanzung ist. Finde ich toll, auch wenn boundaries hier meist 10m abseits des tatsächlichen Verlaufs (Weg, Bach etc.) und mit grober Erfassung zu finden sind. Oft sind dies Gemarkungsgrenzen aus frühreren Zeiten, die mit der Gebietsreform aufgehoben wurden. Ich weiß, dass das Herzogtum Baden nicht mehr existiert, würde aber wetten, dass jede Menge Grenzsteine in den Wäldern zu finden sind.

So, ich geh nochmal in den Wald, die Sonne scheint so schön … :slight_smile:
Cepesko

Bei dem Sachverhalt “viele Relationen auf einem Way” fällt mir spontan das Thema “ÖPNV” hier gibt es das gleiche Thema… :roll_eyes: nur das hier so alles mehr oder weniger zum erliegen kommt aufgrund teils des Aufwandes…

Aber die Probleme sind die Gleichen:

  • Doppelungen
  • Hohe Anzahl an Relationen
  • Wartbarkeit
  • Robustheit gegenüber von Beschädigungen
  • usw. usw.

Die Tagging-Schemen hat auch ähnliche Ideen wie man das lösen könnte… mit Vor- und Nachteilen dieser Lösungen.

Die jetzige Form der Relation ist recht robust gegenüber Beschädigungen… Eine zu hohe Verschachtelung von Relationen in Relationen fände ich nicht gut.

Mehr sollte man schauen Relationen besser zu schützen vor versehentlicher Beschädigung… aber hier wäre die Editoren gefragt.

Zum erstellen von Relationen wäre auch die Möglichkeiten eines Routing-Algorithmus interessant.

mfg Miche

http://www.openstreetmap.org/way/482026344 ist so ein Weg, der nicht mehr zu sehen ist.
Er ist aber im weiteren Verlauf noch sichtbar: http://www.openstreetmap.org/way/373014422

Aber insgesamt eine historische Eisenbahnstrecke: http://de.wikipedia.org/wiki/de:Niederhermsdorfer%20Kohlezweigbahn?uselang=de

Alle Jahre wieder!

kommt sie, mit schöner Regelmäßigkeit, die Forderung, alles historische aus der Datenbank rauszuschmeißen. Weil “wir” ja ach so schön uns dem Prinzip der Nachprüfbarkeit am Boden verschrieben haben. Mit Ausnahme von… (jetzt ist aufzuführen alles, was diejenigen, die das Wort führen dann allerdings doch eigentlich ganz gerne hätten).

Dann kommt bald wieder das Argument, die Datenbank sei zu voll. Nein, ist sie nicht, nur das Datenmodell und die Recherchemöglichkeiten sind (… nein das schreibe ich hier lieber nicht…).

Und die Überprüfbarkeit am Boden? Naja, wenn es sonst keine Qualitätssicherung gibt, dann kann man das als ersten Ansatz nehmen - der aber sehr schnell an seine Grenzen stößt - und genau deshalb auch nicht als Mantra taugt.

Fakt ist, daß die Mapper in die Datenbank das eintragen, von dem sie glauben, daß irgendwann jemand aus dem kartographischen Umfeld daraus Nutzen ziehen könnte. Ja, vergessen wir nicht, OSM hat tatsächlich was mit Kartographie zu tun - nein, es ist erst in zweiter Linie eine Datenbank. Kartographie ist das Ziel, Datenbank nur das Mittel zum Zweck.

Ah ja, ich vergaß: Die Forderung nach Aufteilung in verschiedene Datenbanken - auch immer wieder zu lesen. Macht nichts einfacher aber vieles komplizierter. Warum? Wenn die Daten ordentlich strukturiert sind, tun mir die Daten die ich nicht nutzen möchte, auch nicht weh. Wenn ich aber aber Spezialkarten mache und so ziemlich jede Spezialkarte nutzt irgendwo Daten, die für andere (“den mainstream”) uninteressant sind - dann ist es sehr viel umständlicher, sich diese aus einem Konglomerat an Datenquellen zusammensuchen zu müssen.

Der Charme von OSM lebt gerade von seiner Vielfalt. Wenn ich nur eine Straßenkarte will, bin ich mit Google Maps besser bedient. (uuuuuuh - er hat Jehova gesagt!)

Ein sauber strukturiertes Datenmodell wäre eine Forderung, in die man eher mehr Gehirnschmalz stecken sollte.

…irgendwie habe ich das Gefühl, das ganz schon einmal so ähnlich geschrieben zu haben…

Gruß,
Zecke

Um den vor Post zu kommentieren… Man muss nicht alles fixen war irgendwer in die Welt setzt hat…

Hallo,

Der Limes ist in etwa so sichtbar wie manche railway=abandoned. Wenn man hinschaut, findet man ihn. Wenn man ahnungslos hinglotzt, nicht. Manchmal reicht auch ahnungslose Hinglotzen, um ihn zu finden.

Viele Grüße

Michael

Die Definition der Naturräume mag grob und wechselhaft sein, aber eigentlich leiten sich diese Grenzen aus natürlichen Gegebenheiten ab, sind also eigentlich aus vor Ort verifizierbaren Bodenwahrheiten ableitbar. Die Moräne hat ein mit Schaufel verifizierbares Ende und das ist dann nach einer Definition womöglich zugleich der Wechsel zweier Naturräume.
Diese Grenzen hätten nach dem Mantra also eigentlich sogar mehr Berechtigung, in OSM zu sein, als PLZ-Grenzen …

Das Mantra bei der Wahlkreisgrenzziehung ist eine ähnliche Größe aller Wahlkreise, was manchmal Änderungen nach sich zieht und etwas eigenartig anmutende Zuschnitte. Ob das immer so einfach abzubilden ist …

Theoretisch mag das stimmen, rein praktisch… aber… wird es da extrem schwierig… vor allem entsprechende Grenzen in der Landschaft zum einen identifizieren und zum anderen dann noch erfassen zu wollen. Für Brandenburg habe ich mich berufsbedingt mit Naturraumgrenzen unterschiedlicher Bearbeiter beschäftigt. Historisch gibt es drei Bearbeitungen (Autoren: Meynen/Schmidhuesen (Nachbearbeitung durch Ssymank), Schulze und Scholz), die alle auf grobe, generalisierte Kartenbearbeitungen der 1940er bis 1960er Jahre basieren (TK100 und so). Alle drei unterscheiden sich auch in Erfassungsqualität und Lagegenauigkeit (wenn man bei diesen groben Maßstäben davon sprechen kann). Irgendwelche von denen sind digitalisiert derzeit in OSM drin… Ok… sie stören nicht… wirklich zu was nütze sind sie aber auch nicht; im Gegendatz zu den PLZ-Grenzen.

Es gibt da aber z.B. eine Neubearbeitung der Naturräume Brandenburgs von 2014 https://www.amazon.de/Naturr%C3%A4ume-Landschaften-Brandenburg-Berlin-Gliederung/dp/3954100304 auf Basis einer DGM-Auswertung… Eine ganz tolle Bearbeitung, damit könnte man schon was anfangen… Da kenne ich aber keine Downloadquelle der Geodaten (unabhängig von der Lizenz und der Verwendbarkeit für OSM).

Fazit für mich für boundary=physiogeographical: ist so, wie es ind OSM ist, unnütz und nicht verwendbar… Wenn die denn erfasst werden sollten/konnen/dürfen… dann ist aber auch die einzige Konsequenz, solche Grenzen landesgrenzübergreifend zu erfassen, bzw. vorhandenes zu verbinden. In Polen z.B. sind große Teile des Landes mit diesen Grenzen erfasst… ein nicht gerade kleiner Reil ist aber kaputt…

Sollte eine Grenze bei uns allerdings kaputt gehen, repariere ich diese aber nur, um im Zweifelsfall einen besseren Blick auf andere Geometriefehler haben zu können (ähnlich ist es mit anderen Grenzen in meinem Umfeld).

Sven

Sowohl bei den Grenzen als auch den abgebauten Bahnstrecken geht es um sehr wenige Objekte im Vergleich zur Gesamtanzahl der Objekte in der Datenbank. Eine Auslagerung in eine separate Datenbank halte ich daher nicht für sinnvoll.

Die Daten müssen nur geeignet ausfilterbar sein, auch beim Editieren. Da die Grenzen nicht auf dem Luftbild sichtbar sind, werden die meisten User diese ohnehin nicht sinnvoll bearbeiten können. Da erscheint es sinnvoll, Grenzen nur in einem speziellen Boundary-Mode des Editors oder gar nur mit einem speziellen Boundary-Editor bearbeitbar zu machen. Das würde auch die Zerstörungsanfälligkeit der Relationen deutlich reduzieren.

Von einer Aufteilung in zwei oder gar mehr aufeinander angewiesene Datenbanken halte ich auch nichts.
Das sieht nach einer kombinierten Herkules-Sisyphus-Aufgabe aus.

Das Bearbeiten und Sichtbarmachen bestimmter Objektklassen wie boundaries nur in bestimmten Editormodi scheint mir da effektiver.
Zu Bedenken gebe ich allerdings, dass OSM ein großes, internationales Projekt ist und solche Änderungen eine längere Anlaufzeit (wenn überhaupt :() brauchen. Man denke nur an die stellenweise Nicht-Kooperation der iD-Entwickler.

Zumal man dann beispielsweise alle Objekte, die in Personalunion highway=track und railway=razed sind, verdoppeln müsste. Das zu speichernde Datenvolumen stiege spürbar.

–ks

… so etwas in dieser Richtung würde aber viele Probleme lösen.

Das konzeptionelle Problem besteht ja gerade in der Vermischung / gemeinsamen Nutzung von Punkten und Linien durch virtuelle und reale Objekte. Diese gemeinsame Nutzung müßte, über welche Maßnahmen auch immer, vollständig ausgelöst werden.

Diese Verdoppelung ist manchmal nötig um manche vermucksten Dinge überhaupt noch bearbeiten zu können :confused: Es zu “trennen” bzw. “auftrennen” weglöschen neuzeichnen. Aus der Erfahrung mappen ich auch nicht landuse und highway nicht auf die gleichen Punkte… und auf Grenzen erst garnicht, macht nur das spätere bearbeiten noch schwerer…

Die Diskussion, ob parallele Datenbanken geführt werden sollten und ob das technisch/administrativ/wie auch immer sinnvoll umsetzbar ist, müssen wir hier doch gar nicht führen. Am Ende geht es hier darum, was in OSM drin sein sollte und was nicht. Wenn es dann Leute gibt, die gerne darüber hinaus noch was haben wollen, ist das erstmal deren Problem - nichts hält sie davon ab, dafür parallele Datenbanken zu führen oder einen beliebigen anderen Ansatz zu wählen.
Am Ende bleibt es für uns also nur eine “Relevanzdiskussion”. Das ist nicht schön und kaum einer hier wird wollen, dass das ausartet wie in der Wikipedia. Aber irgendwo müssen Grenzen gezogen werden (passend zum Thema hier^^). Es gibt da klare Fälle (aktuell existierende Straßen gehören in OSM), einigermaßen klare Fälle (Daten, die irgendwelche Spiele/Simulatoren nutzen wollen gehören wohl nicht in OSM) und eben Fälle über die man noch diskutieren muss. Aber um die Diskussion in irgendeiner Form wird man nicht herumkommen. Wenn man dann entscheidet, dass historische/Wahlkreis-/etc. Grenzein in OSM sein sollten gut. Wenn nicht, dann auch gut, dann müssen die halt gelöscht werden und deren Anwender sich eine andere Lösung ausdenken.

Is weg.

Es gibt noch einen zweiten oder gar 3. Kandidaten. Wenn (und ich bin mir fast sicher dass) der nicht gefixt wird, ist der/sind die auch bald Vergangenheit.

Gruss
walter

ps: ich kenne zufälligerweise den Autor vom 2. Kandidaten und der hat nix dagegen.

Jetzt mal eine sachliche Frage zu diesem “Schwafelthema”:

Kann die Overpass Flächen zusammenfassen? So wie es in PostGIS mit ST_Union() geht? Das wäre nämlich eine Alternative für manche “Sammelflächen”.

Gruss
walter

Du kannst Abfragen auf einer Menge von Objekten machen, also z.B. ermittle alle Bundesländer und suche in dieser Menge nach irgendwas - anstelle von: suche irgendwas in der Relation für Deutschland.