Boundaritis - wo soll das hinführen?

Was Eisenbahnen anbelangt ist es eine Alternative, wenn für eine erfasste Bahnstrecke der Obkjektzusammenhang zwischen erhaltenen Streckenteilen und abgebauten Streckenteilen erhalten bleibt. Das hieße, daß Bestandsstrecken in Datenbank A, abgebaute Strecken in Datenbank B und die relation in Datenbank C (?) steht. An den Anschlußpunkten zwischen Bestandsstrecke abgebauter Strecke muß dann auch der topologische Zusamenhang erhalten bleiben: Strecke in meiner Nachbarschaft wo das zuträfe: http://www.openstreetmap.org/relation/5645886

Eine Verarbeitung dieser Daten z.B. OpenRailwayMap oder HistoricPlace muß dann aber gegeben sein, Das ist schon gewissermaßen ein Alleinstellungsmerkmal das derzeit die Grenzübergreifende Nutzung dieser Daten möglich ist.

Grenzen…

Es gibt Grenzen, wo ich mich frage, warum diese drin sind: boundary=physiogeographical ist solch eine http://overpass-turbo.eu/s/rqQ. In meinen Augen sind solche Grenzen obolet, nicht zuletzt auch deshalb, weil diese extrem Grob sind und sie nicht der realen Situation entsprechen. Diese Grenzen basieren auch alten z.T. sehr groben TK100-Karten, auch gibt es verschiedene Bearbeitungen. Hier gibt es gelegentlich auch jüngere Bearbeitungen, die auf DGM-Auswertungen basieren, diese Grenzen unterscheiden sich dann erheblich.

Auch Wahlkreisgrenzen… Wahlkreise basieren doch auf Administrative Einheiten… Hier reicht eine Liste aus mit der Information Gemeine A ist Wahlkreis 1, Gemeine B ist Wahlkreis 1 und Gemeine C ist Wahlkreis 2… Ein Merge der Wahlkreise findet über Wahlkreis statt.

Schutzgebietsgrenzen…

Schutzgebietsgrenzen werden manchmal in Teilen durch Administrative Grenzen definiert. Manchmal werden die Grenzen eines Schutzgebietes zugleich auch durch landschaftliche Gegebenheiten definiert, z.B. kann die Uferkante eines Gewässers zum Wald die Grenze eines NSG’s sein. Solche Grenzdefinitionen gibt es hier im Spreewald zu Hauf…

würde man die Daten auslagern, müsste auch hier dieser topologische Zusammenhang erhalten bleiben, alles andere ist in meinen Augen ein nicht hinnehmbare Verschlechterung der Datenqualität. Also wenn ich aufgrund besserer Luftbilder das Gewässerufer besser erfassen kann, muß ich zugleich auch die entsprechende NSG-Grenze mit anpassen.

Sven

Hallo Harald,

Ich kann zwar nur von der OpenRailwayMap sprechen, von historic.place habe ich wenig Ahnung, aber du scheinst zwei verschiedene Bedeutungen von “historisch” zu vermischen.

historisch: Objekt, das alt ist und von dem Teile oder das Ganze noch vorhanden sind:

• Burgruinen (nicht: disused:man_made=castle)
• Sühnekreuze
• archäologische Fundstellen

historisch: Objekt, das man existiert, aber nicht mehr existiert und restlost entfernt wurde:

• restlos abgebaute (ggf. sogar überbaute) Bahnstrecken, nur noch in den Köpfen alter Anwohner und einiger Pufferküsser existent
• abgerissene Gebäude, an deren Stelle ein neues gebaut wurde
• geschlossene Ladengeschäfte

Viele Grüße

Michael

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 …
Cepesko

Bei dem Sachverhalt “viele Relationen auf einem Way” fällt mir spontan das Thema “ÖPNV” hier gibt es das gleiche Thema… 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 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.