Boundaritis - wo soll das hinführen?

Oder sollte man sich auch mal Gedanken darüber machen, verschiedene OSM Datenbank vorzuhalten?

Wenn wir jetzt z.B. alles “historische” rausschmeißen, nehmen wir gleich mehreren Karten die Grundlagen (railwaymap, historic place, etc) … und oder wollen wir denen dann eine komplett eigene Infrastruktur aufbürden? … gut es gäbe da ja noch die OpenHistoricalMap, vielleicht wäre das eine Alternative.

Grundsätzlich würde ich aber Frederik zustimmen, dass wir mittlerweile einfach zu viele (Gebiets-)Relationen drin haben, die da nicht reingehören, u.a. wegen der Überprüfbarkeit.

+1, gut ausgedrückt, eine “on the ground” Datenbank und eben eine für alles andere :slight_smile:

@wambacher
könnte deine boundaries map denn auch Landkreis-umringe erstellen (für den export), wenn die relation dafür nur aus den relationen der gemeinden zusammengesetzt ist? oder sollte man einfach den gemeinderelationen ein tag für die kreiszugehörigkeit geben? dann bräuchte man garkeine landkreis (und aufwärts) relationen.

Dem kann und muss ich voll zustimmen. Es ist einfach zu viel - und viel zu einfach, solche Sachen anzulegen.

Mir fallen da die Superrelationen an, also Relationen, deren Member andere Relationen sind. Damit lassen sich ja “Flächen, die aus bereits existierenden Fächen bestehen” relativ einfach definieren.
Aber so richtig wohl fühle ich mich dabei nicht, da nur Schrott durch Edelschrott ersetzt wird :wink: Und ob da alle Anwendungen mit klarkommen, weiss ich auch nicht. Aber die liessen sich ja anpassen.

Das Kernproblem, dass jeder alles in OSM reinkippen muß, damit auch alle darauf zugreifen könnten - wenn sie denn wollten- wird dadurch nicht gelöst. uMap hat sowas ja für “eigene POI” und ähnliche Daten gelöst, aber das befindet sich ja nicht im Verantwortungsbereich der OWG und ist somit prinzipiell “wacklig”. Eine 2. DB für “spezielle” Daten aufzubauen, würde einen erheblichen Entwicklungs- und Wartungsaufwand bedeuten. Denkt nur an die Toolchain, die derzeit OSM zusammenhält.

Gruss
walter

ps: “Meine” im jugendlichen Leichtsinn früher mal angelegte Rel 1111111 ist derzeit defekt (wundert mich nicht), sodass ich das Verhalten von osm2pgsql hieran nicht einfach überprüfen kann.

Ich denke schon länger daran, diese Superrelation zusammen mit ihren Wegstücken aus OSM zu entfernen. Was monatelang defekt “rumliegt”, wird auch nicht benötigt.

Gegenargumente?

keine: dann sind die heute Abend weg.

Gruss
walter

Ein fachkundiger Bahn-Mapper wird mehr Indizien am Boden finden als ein Briefkasten-Mapper.
Ohne es auf Luftbildern erkennen zu können, findet man oft genug im Wald noch Geländeformen, die auf die ehemalige Bahn hinweisen. Und umgekehrt folgen viele Hecken und Buschansammlungen noch der alten Bahntrasse. Oder Wege oder Bebauungen. Im Supermarktparkplatzbeispiel kann man die ehem. Strecke zwischen heutigen Prellbock bis Marnheim noch wunderbar sogar im OSM-Kartenbild nachverfolgen.
Was wirklich nicht mehr vor Ort verifizierbar ist in der Art und daher “razed” als tag bekäme, würde vo Prinzip her zwar raus müssen, dann würde man aber Lücken reißen in ein geschlossenes Themengebiet.
Bahnen (und teils auch Straßen) hinterlassen als ehem. Kunstbauwerke nun mal noch lange Spuren.
Und wo wor gerade elegant den Bogen zu Straßen geschlagen haben :wink: Auch da gibt es ja häufig die Diskussionen, ab wann ein Waldweg noch ein Waldweg ist, raus oder nicht, wenn der Weg mal einen Sommer lang zugewuchert und absolut unauffindbar ist und erst in der nächsten Saison wieder freigeschnitten wird …

Die Regionalverbände haben durchaus ihre gewisse Stellung in der Verwaltungshierarchie und haben ihren admin_level nicht völlig zu Unrecht … Auch wenn ihre Kompetenzen gering sind. Ähnliches gilt für Gemeindezusammenschlüsse unterschiedlichster Art.
Eigentlich wäre es hier aber durchaus sinnvoll, nicht immer die Grenzen direkt reinzunehmen, sondern die Flächen der nächsten Ebene drunter, **vorausgesetzt **alle verarbeitenden Programme können es verdauen, ihre Schäflein über schlimmstenfalls 10 Iterationsstufen zusammen zu sammeln.
Wer Deutschland als Fläche braucht, müsste dann die Bundesländer zusammen sammeln, dann die Regierungsbezirke, SOFERN VORHANDEN in dem Land, dann Regionalverbände, dann die Kreise, dann die Gemeindeverbünde, dann die Gemeinden, dann die Ortsteile, dann die Stadtviertel, jeweils sofern vorhanden … Das ist viel Aufwand … Ok, ein riesenlanges Deutschland-Polygon ist auch nicht so leicht zu handeln …

Eigentlich ist es auch ein berechtigtes Anliegen, Wahlkreise und Kirchenbezirke etc. auf Karten darzustellen, wird oft genug im realen Leben gemacht und sollte mit OSM-Daten eigentlich möglich sein.

Genauso wird es ja mit PLZ gemacht, die draußen in der Natur auch nicht wirklich auffindbar sind, weniger gut auffindbar als administrative Grenzen, die immerhin vermarkt sein sollten mit Grenzsteinen o.ä.
Wenn eine Gemeinde in mehrere PLZ-Gebiete fällt, ist die Definition ja eigentlich nur laut dickem alten PLZ-Buch “A-Straße, B-Straße 1-4711 ungerade in 12345, B-Straße 2-0815 gerade, C-Straße in 23456” Wie man die Grenze der PLZ zwischen A- und C-Straße über den Acker zieht bis zur PLZ 34567 ist völlig beliebig …

Naturschutzgebiete findet man auch nicht immer in der Natur vor. Wenn muss das Schild nicht unbedingt direkt der wahren Abgrenzung entsprechen …

Wir haben also schon arg viel frei gezogenes drin …

Und ob jede U-Bahn lagetreu drin ist …

Alles sind aber Geo-Daten und wir sammeln Geo-Daten …

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 … :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.