Um administrative Grenzen in JOSM zu betrachten und herunterzuladen, stelle ich in JOSM folgende Overpass Abfrage:
[out:xml][timeout:90][bbox:{{bbox}}];
(
nwr["boundary"="administrative"];
);
(._;>;);
out meta;
Wenn ich dann einen einzelnen Punkt bewege, können aber noch andere Dinge drankleben. In der Realität bilden oft beispielsweise landuse, highway oder Gewässer diese Grenzen, so dass in OSM diese oder einzelne deren nodes an die Grenze geklebt sind. Auch für andere Typen von Grenzen wie beispielsweise PLZ oder Wahlkreise trifft das zu, All das würde mitbewegt, ohne dass ich das mitbekomme. Kann ich die Anfrage erweitern, so dass alles mit heruntergeladen wird, was dranklebt?
Wenn ich Grenzen mit JOSM anfasse, entklebe ich vorher konsequent… Man muß natürlich z.B. auf PLZ-Grenzen und Schutzgebietsgrenzen aufpassen.
In JOSM nutze ich dann “Geometrie ersetzen”. Es kann dann nur noch vorkommen, daß eine Grenze mit was anderem verklebt ist und just an dem Punkt was anderes, z.B. eine Abbiegerelation hängt. Wird ein Gewässersegment direkt als Grenzsegment genutzt, wird es aufwendig…
Kurz: Ich löse alles so auf, daß Admin-Grenzen einen nichtverklebten Datenbestand bilden. Mit etwas Erfahrung bekommt man das fehlerfrei hin…
[out:xml][timeout:90][bbox:{{bbox}}];
(
nwr["boundary"="administrative"];
);
(._;>;way(bn);>;);
out meta;
Es können schlussendlich nur Ways an Nodes der Grenzrelation hängen. Zwar könnte theoretisch auch eine Relation einen Way als Member haben und ansonsten nur unverbundene Objekte. Wenn die anderen Objekte der Relation unverbunden sind (wenn das überhaupt vorkommt), dann sind diese auch unbeeinflusst vom exakten Grenzverlauf.
Extra Relationen, die irgendwas hier referenzieren, könnte man bekommen, wenn man mit einer zusätzlichen Zeile (._;rel(bw)->.r;rel(bn);); vor der Ausgabe diese explizit einsammelt. Ab irgendwann sind es aber auch einfach zu viele Daten. Relationen gibt es gerne sehr viele sehr große.
Vielen Dank für Deine Reaktion. Zum Stichwort große Relationen hat man es als Nordseeküsten-Bewohner bei den Gemeindegrenzen automatisch auch mit den Grenzen Niedersachsens und Deutschlands sowie der Niederlande und der Küstenlinie zu tun. Nach meiner Erfahrung wäre es besser, diese zuvor absehbaren Abschnitte gesondert und kleinteilig zu betrachten. Bei der Küstenlinie haben wir ja noch jemand, der das letzte Wort hat und somit Eurasien nicht beispielsweise wegen einer falschen Wegrichtung überschwemmt wird.
Nicht nur das. Es kann auch irgendwas (in OSM) direkt daneben liegen und ein verschobener Punkt ist dann evtl. nicht genug. Aus meiner Sicht ist es immer besser, den Bereich, in dem der Knoten liegt, komplett herunterzuladen.
@drolbr Uhi… die Abfrage ist harter Toback! Danke! Die gefällt mir sehr!
Das gibt Ideen, da {{style: …}} mit zu verbauen… Ich denke da an Kombinationen mit Schutzgebietsgrenzen, die gerne mal teilweise direkt durch Admingrenzen definiert sind…
Der Grund erschließt sich mir nicht. Es geht doch gerade darum, andere Dinge als die Grenzen von einer versehentlichen Berührung auszuschließen. Gerade bei den Grenzen muss man immer wieder weit raus zoomen, um beispielsweise anhand der Form zu bestimmen, wo der zu bearbeitende Punkt liegt. Da sieht man den Wald vor lauter Bäumen nicht mehr, wenn alles umzu runtergeladen ist. Dann muss wieder weit rein zoomen, um nichts Benachbartes zu erwischen. Da möchte man doch möglichst alles aus dem Weg haben, was nicht von den Edits betroffen ist. Nur bei den angeklebten Objekten kommt man nicht daran vorbei, diese von den Grenzen zu isolieren. Die Luftbilder und OSM-Carto im Hintergrund bleiben natürlich zur Orientierung eingeblendet. Man ist beispielsweise darauf angewiesen, wenn eine Grenze in enger Bebauung verläuft und man sie exakt zwischen die richtigen Häuser platziert. Auch andere, deaktivierte Layer können als Hintergrund fungieren.
Then follows one of the symbols: w (forward from ways), r (forward from relations), bn (backward from nodes), bw (backward from ways), or br (backward from relations).
Ist folgendes Szenario konsistent oder gibt es einen Denkfehler?:
Es können punktförmige Objekte mit eigenem Tagging (beispielsweise Ortsschilder) auf der realen Grenze stehen und somit einen Node der Grenzrelation darstellen. Dieser Node könnte beim Editieren des Grenzverlaufes verschoben werden, wenn beispielsweise die Grenze an dieser Stelle schnurgerade ist und sich einige hundert Meter zu krümmen beginnt. Dann steht das Ortsschild komplett falsch.
Könnte man solche Punkte der Grenzrelation, die ein eigenes Tagging aufweisen, durch Overpass ausfiltern und ihnen einen Style überstülpen? Der würde dann signalisieren, dass man diesen Node nicht verschieben darf. Könnte man dieses Abfrageergebnis zudem in einen weiteren Layer legen, um später noch sehen zu können, wohin man den versehentlich verschobenen Node wieder zurück schieben muss? Oder kann es Probleme machen, Nodes in einem Layer zu verschieben und in einem anderen nicht?
eine adaptierte Version mit mehr boudary-Werten (u.a. protected_area) und einer vorhandenen {{style:…}} Version…
Das hier landuse und natural mit geliefert werden ist klar, Hier im Spreewald sind mitunter Schutzgebietsgrenzen z.B. durch die Uferkante eines Gewässers zur Landfläche definiert… Das ließe ich gesondert darstellen…
Aber: die eine schnurgerade Linie quer durch das Totalreservat “Groß Wasserburg” ist ein Rendering-Fehler (??) oder fehlt noch was? Datenmäßig ist das in Ordnung und lange nicht angefasst worden…
Lassen sich übrigens im {{style:…}} - Argument die Darstellungsreihenfolge manipulieren?
Ich bin mir nicht sicher, was bei “Geometrie ersetzen” passiert. Sehe ich es richtig, dass diejenigen Nodes der Grenze, die von anderen Ways benötigt werden, dort erhalten bleiben? Aus dem neuen Objekt, das beim Ersetzen entsteht, werden sie aber gelöscht?
Gilt dasselbe für Nodes, die (beispielsweise als Ortsschild) getaggt sind. Bleiben die an alter Stelle stehen und werden aus dem neuen Objekt gelöscht?
Ja. So wie ich das beobachte, wird die Historie der Liniengeometrie erstetzt, bleibt somit erhalten als auch die Stützpunkte. Weitere, zusätzliche Stützpunkte kommen natürlich hinzu…
Wenn z.B. ein Ortsschild auf einem Straßenstützpunkt sich zugleich ein Stützpunkt mit einer Grenze teilt, wird die Aktion verweigert… Das muß man dann vorher manuell trennen: Grenze von Straße und Ortsschild an Straßennode und Grenznode ohne entsprechende Info. Ähnlich auch z.B. mit Punkten vor Abbiegerelationen und so…
Ein Node der alten Grenze hat eigene Tags. Diese Tags können ihn als Ortsschild, Brunnen oder beliebiges anderes Objekt ausweisen. Die Betonung liegt auf eigenen Tags, weil die meisten Nodes einer Linie keine eigenen Tags haben. Dieser Brunnen-Node gehört nur zum Grenzweg und sonst zu keinem anderen Objekt.
Ich mappe eine neue, korrigierte Grenze 50 Meter entfernt von der alten, die somit am Ort dieses (Brunnen-) Nodes richtigerweise keinen Node hat. Dann wende ich “Geometrie ersetzen” an. Wenn der Brunnen dann an anderer Stelle steht, wäre das ja falsch. Daher die Frage: Steht der Brunnen dann noch dort, wo es vorher stand. Wenn ja, ist er dann Member des neuen Grenzweges oder steht es solitär, ohne Mitglied irgendeines Weges zu sein.
Schlussendlich muss der Brunnen nach der Aktion dort stehenbleiben, wo er vorher stand. Da der neue Grenzweg jetzt woanders verläuft, darf er nicht mehr dessen Bestandteil sein.
Hast Du es mal mit Filtern (in JOSM nicht mit Overpass) versucht? Rausgefilterte Objekte sollten nicht modifizierbar sein.
Probleme macht es keine. Ich benutze den Trick mit mehreren Ebenen, wenn ich vor dem Hochladen feststelle, dass ich Objekte versehentlich gelöscht habe. Wichtig ist, dass Du die Objekte in beiden Ebenen verändert hast (ich setzte ein FIXME=*), damit beim Vereinen der Ebenen Objektversionskonflikte entstehen. Ansonsten wird nur die neuere Version verwendet.
“Geometrie ersetzten” ist sehr sicher und verwendet Punkte nur, wenn sie keine Tags haben und ausschließlich die zu ersetzenden Linie als Eltern haben. Soviel ich weiß, gilt das auch für Relationen wie z.B.:
Relation 4763363 hat als Member aufeinanderfolgend Way 679217776 und Way 679217777. Way 67921776 endet in Node 12299888033, aber Way 67921777 beginnt mit Node 1083315200. Beide haben die gleiche Koordinate, so dass die Relation graphisch geschlossen wirkt, aber datentechnisch offen ist, sogar mit zwei Doppelnodes.
Es hat auch bei gedauert, bis ich da auf die richtige Idee gekommen bin. Ich hatte mir die Rohdaten heruntergeladen und von Hand an beiden Enden der komischen Linie geschaut, wie und wie oft die exakte Koordinate vorkommt.