Boundaritis - wo soll das hinführen?

ACK. Womit natürlich die nächste Diskussion über historische Bahnlinien ins Haus steht. Also so was wie https://www.openstreetmap.org/relation/1765740, wovon on the ground beim besten Willen nichts mehr zu sehen ist, jedenfalls in den mir bekannten Abschnitten.

Abgebaute Elemente so lange drin lassen, wie sie auf den gängigen Luftbildern noch zu sehen sind, damit Sesselmapper sie nicht neu wieder einzeichnen. Aber danach weg damit. Eventuell könnte man das sogar automatisieren: alles mit removed:-Präfix, das fünf Jahre lang nicht angefasst wurde, wird gelöscht.

Aber sorry, ich bin thematisch abgedroffen. Für Wahlkreise etc. gilt aber Entsprechendes. Ich stimme zu: Admingrenzen sind eine Ausnahme, weil sie einen großen Nutzen bieten. Naturschutzgebiete ebenso, das sind verifizierbare Grenzen, und sie haben in einer Karte, die auch für Outdooraktivitäten benutzt wird, zweifellos einen wichtigen Nutzen. Aber Planungsregionen?

–ks

Die Relationen TMC sind auch auf vielen Straße anzutreffen. Nachweisbar vor Ort ist es nicht (Kreuzungspunkte, Abschnitte). Wird es eigentlich genutzt?

http://wiki.openstreetmap.org/wiki/DE:TMC

Ob es wird, weiß ich nicht, aber für ein Navi ist es zweifellos nützlich, TMC-Referenzen in seinem Kartenmaterial zu haben, um Staus zu lokalisieren und Umleitungen auszugeben.

–ks

Solange sie richtig eingetragen sind, würde ich es in OSM lassen. Vielfach gibt es Wander-/Radrouten die Teile nutzen und sogar beschildert sind. Allerdings sollte so etwas nicht als extra way eingetragen sein:
https://www.openstreetmap.org/way/131397719#map=16/50.2857/7.7246

neben einem bestehenden track “Alter Bahndamm”.

So etwas willst du belassen? Da ist nur ein Parkplatz von einem Einkaufszentrum und man könnte noch nicht einmal erahnen dass hier mal eine Bahnstrecke war.

Man müßte mal überlegen, welche Konsequenzen (Aufwand, Machbarkeit, Vorteile, Nachteile, …) sich aus einer grundsätzlichen Trennung (Datenbankebene) von realen und virtuellen Objekten ergeben würde.

Eine Diskussion über “gute und schlechte” Grenzen dürfte wohl eher zu nichts/wenig fü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