Hallo zusammen,
bevor wir in das Thema einsteigen: Es kann sein, dass dies der falsche Ort für dieses Thema ist. Falls ja, bitte ich um Entschuldigung und Rückmeldung, wo ich es hätte hinstellen sollen. Danke.
Ich habe in den letzten Tagen existierende Routen (Relationen mit type=route) angesehen und aufgeräumt, sprich sortiert und Lücken geschlossen. Konkret Routen für Fußgänger (route=hiking), Fahrradfahrer (route=bicycle) und Autostrassen (route=road). Weiter eingeschränkt auf Routen, die von A nach B gehen, also keine Netzwerke, und die damit bei richtiger Sortierung im Relationeneditor von JOSM eine durchgehende Linie bilden (evtl. um forward/backward roles ergänzt). Am Anfang waren auch noch Busse (route=bus) dabei, aber die lasse ich erst mal außen vor, weil es fast immer ein Eintauchen in den ÖPNV bedeutet und detaillierte Kenntnis der Linie voraussetzt. Dabei bin ich auf eine Reihe von Fragen gestoßen, die ich hier im Forum stellen will.
Problem 1.) Autostraßen, z.B. Bundesstraßen, Landesstraßen etc.
Manchmal haben diese keinen gemeinsamen Anfang/Ende, weil es von Anfang bis Ende zwei getrennte Fahrbahnen gibt (z.B. Autobahn). Diese werden dargestellt, indem durchgängig forward/backward roles vergeben werden. Dann kommt JOSM ganz schön durcheinander bei der Darstellung der Konnektivität auf Basis der forward/backward-role: Wenn es einen gemeinsamen Startpunkt gibt, wird die Konnektivität angezeigt (mit dem gestrichelten Gegenweg), aber wenn es keinen solchen gibt, wird jedes Segment als unterbrochen angezeigt, dann sieht man nichts mehr. Es gibt mehrere Fälle:
1.1) Die Route hat auf einer Seite eine gemeinsame Straße für beide Richtungen: Dann sollte man den Anfang auf diese Seite legen.
1.2) Die Route hat eine gemeinsame Fahrbahn an mindestens einer Stelle in der Mitte, Anfang und Ende sind mit jeweils getrennten Fahrbahnen: Dann kann man sich die Konnektivität ansehen, indem man die Route komplett reversed, denn auf der Endeseite arbeitet JOSM richtig. Ich habe das bei der E 54 (https://www.openstreetmap.org/relation/6244657) so gemapped, man muss es sich aber in JOSM ansehen.
1.3) Die Route ist durchgängig mit getrennten Straßen für jede Richtung: Dann kann man es nicht mehr für JOSM verdaulich gestalten.
1.4) Die Route hat Unterbrechungen und an jedem Start/Ende eines Teilstücks gibt es getrennte Fahrbahnen für jede Richtung (mehrfaches Auftreten des Problems aus 1.3). Es gibt die theoretische Möglichkeit eines Workarounds, (den ich aber für nicht richtig halte): Virtuelle Wege mit einem gemeinsamen Start-Knoten an den Anfang der Relation/des Teilstücks stellen. Ich habe das versuchsweise mal bei der B37, relation https://www.openstreetmap.org/relation/21094#map=19/49.43759/7.70927 angewandt (mit entsprechenden notes über den experimentalen Charakter).
Dass man jede der beiden Fahrtrichtungen in eine einzelne Relationen legen könnte und eine Parent-Relation dazu macht, ginge natürlich, aber das bedeutet Bäume von Relationen, wenn die betreffende Route sowieso schon in Teiletappen zerlegt ist (z.B. bei der Bundesstraße 8). In public transport v2 wird das für jede Linie so gelöst, aber dort verstehe ich das auch: gerade Buslinien können richtig kompliziert werden, wenn sie sich selber kreuzen, oder auch aus einem Teilstück wieder zurückfahren … eine Autonbahn sollte aber mit forward/backward role für beide Richtungen erschlagbar sein.
Zurück zu Autostraßen: Gibt es eine Lösung ohne separate Relationen? Z.B. eine role “forward_start”/“backward_start” einführen, die das JOSM signalisiert?
Problem 2.) Immer noch Autostraßen, z.B. Bundesstraßen, Landesstraßen etc.
Es gilt für nichtlokale Straßen (schon eine Kreisstraße ist für mich nichtlokal, Landestrassen aufwärts erst recht) häufig die Situation, dass z.B. eine Kreisstraße K1 eine andere Kreisstraße K2 (oder einen Teil davon) “mitbenutzt”. Aus dem, was ich an tagging gesehen habe, entnehme ich, dass in diesen Fällen in der Relation der K1 der Teil der K2, der mitbenutzt wird, NICHT aufgenommen wird und dass auch die gemeinsam genutzten ways als ref-tag nur “K2” erhalten (z.B. bei der “Kreisstraße LIF 7”, Relation https://www.openstreetmap.org/relation/409176, die einen Teil der “Kreisstraße LIF 2”, Relation https://www.openstreetmap.org/relation/409158 mitbenutzt). Jetzt habe ich einen Fall gefunden, in dem die “Staatsstraße St 2177” (Relation https://www.openstreetmap.org/relation/76033)) das mitbenutzte Teilstück der B 303 (Relation https://www.openstreetmap.org/relation/30437) explizit mit aufnimmt. Die Wege sind aber mit ref=B 303 getagged (wie ich es auch erwartet hätte). Im wiki (Seiten https://wiki.openstreetmap.org/wiki/Attributierung_von_Straßen_in_Deutschland, https://wiki.openstreetmap.org/wiki/WikiProject_Germany/Landesstraßen und https://wiki.openstreetmap.org/wiki/WikiProject_Germany/Landesstraßen/Bayern) habe ich nichts spezifisch hierzu gefunden, allerdings die Aussage, dass eine Landesstraße, Bundesstraße etc. als Relation geführt wird und die ways mit der Straßennummer getagged werden.
Kann mir jemand sagen, wie die Relation im Fall einer solchen gemeinsamen Benutzung auszusehen hat? In der mitbenutzenden Straße als Lücke lassen, wie fast immer gemapped?
Problem 3.) Generelles zum Aufräumen
3.1) Ich halte es für sinnvoll, eine Route, die von A nach B führt, auch in ihren Elementen so anzuordnen, wie die Teilstücke (ways) hintereinander liegen. Dadurch kann man erkennen, ob Lücken vorhanden sind bzw. die Route vollständig ist. Es bedeutet aber, dass bei zuvor relativ unaufgeräumten Relationen (und das sind eine ganze Menge) die Anordnung anschl. fundamental anders ist, so dass es schwierig wird, die Versionen der Relation auf Ebene der geordneten Elemente vor bzw. nach dem Aufräumen miteinander zu vergleichen. Aber der Mehrwert der richtigen Anordnung überwiegt die schlechtere Übersichtlichkeit der Historie (die man mit anderen Tools auch wieder auf das bisherige Niveau zurückführen können sollte).
3.2) Ich halte es für weiter für sinnvoll, Lücken zu schließen, wenn offensichtlich ist, dass nur 1 oder 2 Wege fehlen und welche das sind. Ich halte den Mehrwert einer vollständigen Route für größer als das geringe Restrisiko, dass die simple Lücke falsch geschlossen wurde (weil ohne Ortskenntnis). Bei größeren Lücken sollte man auf ein Schließen verzichten und stattdessen einen FIXME hinzufügen, ein Beispiel ist zu sehen unter https://www.openstreetmap.org/relation/1736379).
Gibt es hierzu andere Meinungen und welche sind dies? Vielleicht habe ich ja etwas wichtiges übersehen.
Problem 4.) “Auswüchse” aus der Route als Dead Ends
4.1) Kurze Auswüchse
Ich habe immer wieder die Situation vorgefunden, dass ein way A sich an den way B anschließt, aber nicht am Ende, sondern in der Mitte von B. Dies führt dazu, dass die Route vermeintlich unterbrochen ist, denn vom Ende von B aus geht es ja nicht weiter. Durch Splitten dieses “zu langen Weges” B und anschl. löschen des übrigen Teiles aus der Relation lässt sich das Problem lösen. Bei “sight seeing” Routen könnte es sein, dass eigentlich ein Abstecher zu z.B. einem interessanten Gebäude gemacht wurde (siehe dazu 4.2 unten). Man muss also sensitiv sein bei der Entscheidung. Es ist mir aber nicht verständlich, warum diese Situationen so häufig vorzufinden sind, denn wie können sie entstehen? Dass der zu splittende way schon mal getrennt war und zusammengelegt wurde, halte ich für unwahrscheinlich. Damit bleibt nur, dass einer der Mapper der Route an diesen Stellen “schlampig” gearbeitet hat. Dass die Leute so häufig schlampig gearbeitet haben, kann ich mir aber nicht vorstellen. Bleiben noch Verfeinerungen, z.B. die Verlängerung eines Weges um einen node. Wenn die Relation nicht mit gepflegt wird, ist es passiert. Könnte sein, denn wenn über so eine Stelle mehrere Routen gehen, dann haben interessanterweise alle Routen diesen Auswuchs. Was aber die eigentliche Frage an das Forum ist: Das Löschen dieses kurzen Dead Ends ist eine Veränderung der Route ohne Ortskenntnis, nur aufgrund der Plausibilität. Ich sehe den Mehrwert einer durchgängigen Route als höher an als das Restrisiko, einen gewollten Abstecher irrtümlich zu löschen, zumal das Mappen eines echten Abstechers unter 4.2 beschrieben ist. Wie seht Ihr das? Andere Meinungen? Habe ich etwas wichtiges übersehen?
Problem 4.2) Gewollte Abstecher
Wenn ein gewollter Abstecher von der Route gefragt ist, z.B. um eine Sehenswürdigkeit zu erreichen, dann ist der betreffende Abstecher zweimal aufzunehmen, nämlich hin und zurück. Wenn ich so etwas in einer Route gesehen habe (mit einem erkennbaren Ziel), habe ich es so modelliert. Das war z.B. bei “Radweg Burgenstraße” (Relation https://www.openstreetmap.org/relation/2013819) der Fall, auch wenn der Abstecher von Sinsheim nach Weiler dort eine ganze Menge von ways betrifft (darunter z.B. way https://www.openstreetmap.org/way/118945090). Da hierbei gegenüber der Route nichts verändert wird, sondern schlimmstenfalls die betroffenen ways zweimal in der Route enthalten sind gegenüber zuvor einmal, erwarte ich hierüber weniger Diskussion, höchsten über die Frage, wie man solche Abstecher in einer Route generell zu modellieren hat. Darüber habe ich aber nichts genaueres im Wiki gefunden, selbst bei public transport (https://wiki.openstreetmap.org/wiki/DE:Public_transport) ist eine vergleichbare Situation (wie sie z.B. in einer Busline auftreten kann) nicht explizit beschrieben.
5.) Kreuzungen, Kreisel, Seiteneffekte
Problem 5.1) Kreuzungen
Insbesondere bei Fahrradrouten sind komplizierte Kreuzungen mit getrennten Fahrradwegen für die Gestaltung der Route “die Hölle”, zumindest wenn die Route auch korrekt über den Fahrradweg verlaufen soll. Und es sind immer wieder Fälle da, wo die Route an einer Kreuzung auf dem Fahrradweg endet und auf der Straße weitergeht, aber wg. fehlendem Link zwischen Fahrradweg und Straße unterbrochen ist. Das kann man durch Hinzufügen eines Links (als highway=cycleway) lösen, aber es besteht das Risiko, dass der Link an der falschen Position landet. Das Problem wäre nur durch Ortskenntnis/Besichtigung zuverlässig zu lösen, umgedreht ist es unmöglich, Routen im größeren Stil ausschließlich mit Ortskenntnis/Besichtigung aufzuräumen, denn die Orte sind vielfach weit entfernt und die Fragen kommen erst beim Mappen … Ich verfahre an diesen Kreuzungen so, dass ich mir in bing ein möglichst genaues Bild verschaffe, um auf dessen Basis zu entscheiden. Aber auch hier halte ich den Mehrwert einer vollständigen Route für größer als das Risiko eines im Detail geringfügig fehlerhaften Links (von Fahrradweg am Rand auf die Straße). Im Zweifel muss ein FIXME am Weg hinzugefügt werden, mit dem Hintergrund der Relation, dann werden Leute mit Ortskenntnis auf das überregionale Problem der Route aufmerksam und können “nachbessern”. Und wenn man es im Satellit überhaupt nicht erkennen kann, dann muss ein FIXME in die Route, dass sie an dieser Stelle von außen nicht schließbar war und jemand mit Ortskenntnis das doch bitte machen möge.
Frage: Haltet Ihr dieses Vorgehen für ok? Was ist kritisch/sollte anders gemacht werden?
Problem 5.2) Kreisel in einem Stück oder in vielen Teilstücken?
Nachtrag: Zu diesem Thema gibt es inzwischen einen eigenen Topic im Forum: Kreisel und Routen, Kreisel in DE:wiki
Kreisel sind häufig in getrennte ways zerlegt anzufinden, mit einer für die Route unpassenden Struktur (d.h. die Route ist ohne Strukturänderung nicht ohne Unterbrechung darstellbar). Die Zerlegung des Kreisels muss damit in jedem Fall geändert werden, um die Route korrekt über den Kreisel zu führen. Geht man jetzt den Weg, den Kreisel durch weiteres Splitten (also noch mehr Teilwege) zu zerlegen und damit für die Route brauchbar zu machen, macht man umgedreht all die anderen Routen, die über denselben Kreisel führen, umso komplizierter, denn deren Relationen sind mit zu korrigieren. Und an einem Kreisel auf 5-10 Routen-Relationen zu stoßen ist durchaus normal. Deshalb lege ich die Teile zu einem einzigen Weg (Kreisel) zusammen, dann sehen alle betroffenen Routen anschl. einfach aus (nur eine Zeile, spezielles Kreiselsymbol in JOSM). Das geht natürlich nur, wenn alle Tags der Teilstücke gleich gewesen sind, sonst geht ein u.U. wichtiges Detail verloren. Dieser Ansatz (ein Kreisel, ein Weg) sollte allgemein durchhaltbar sein. Wenn der Kreisel z.B. durch einen Bach gequert wird, braucht man verschieden getaggte ways (mit oder ohne Brücke), dann muss man es in den Einzelstücken machen/lassen, mit allen Konsequenzen.
Frage: Ist dieses Vorgehen ok? Was habe ich übersehen?
Problem 5.3) Seiteneffekte aus Änderungen an Kreuzungen/Kreiseln für Fahrradrouten
Wenn man mit Route A an einer Kreuzung “ankommt” und die Route dort auf die Fahrradwege umlegt, muss man sich entscheiden, ob man auch die Routen B-E, die diese Kreuzung passieren und bisher auf der Straße (gegen die Pflicht zur Fahrradwegbenutzung verstoßend) verlaufen, auch auf den Fahrradweg umlegt. Ich habe eine ganze Reihe Kreuzungen gesehen mit herrlichen zusätzlichen highway=cycleway, nur waren die Fahrradrouten weiter auf der Straße gemapped (kann mich aber leider an keine konkrete erinnern, sonst wäre hier ein link). Wenn man die Arbeit strikt begrenzen will auf die Route A, an der man gerade arbeitet, dann ignoriert man die Fehler in den Routen B-E an dieser Kreuzung (macht noch nicht mal einen FIXME). Die Konequenz wäre inkonsistente Darstellung gleichartiger Dinge (Fahrradrouten) am selben Ort. Aber wenn man die Routen B-E nur an dieser Kreuzung anpacken will (und damit konsistent bleiben will), kann das bei einer schlecht geordneten Route B dazu führen, dass man Route B zumindest grob sortieren muss, bevor die Detailarbeit an der Kreuzung für diese Route ausgeführt werden kann (sonst baut man noch mehr Chaos und Fehler in die stark ungeordnete Route). Umgedreht heißt grob sortieren, dass man u.U. nicht erkennt, welche Intention die Autoren an einigen Stellen mit der Route hatten, und diese nach der groben Sortierung verloren sind. Aber Route B gleich konsequent und vollständig aufräumen ist gefährlich, weil man ziemlich sicher an eine weitere Kreuzung gerät, in der dann das Spiel mit Route S, die dorrt zufällig auch durchläuft, neu beginnt. Also Route B nur grob sortieren, und nur für die Kreuzung ins Detail gehen. Wie ich das in changesets packe, dazu unten mehr.
Ich habe mich dazu entschieden, in solchen Fällen alle Fahrradrouten an der Kreuzung mit anzupassen, schließlich kommt die ganze Aktion ja aus dem Impuls “Aufräumen” :). Das bedeutet, dass die Fahrradrouten B-E explizit mit angefasst werden. Kommentare zu diesem Vorgehen sind herzlich willkommen.
5.4) Seiteneffekte aus Änderungen an Kreuzungen, vor allem Kreiseln, auf andere Routen (Straßen, vor allem Bus)
Nachtrag: Auch zur Frage getrennter Zu-/Abfahrten in Kreisel gibt es inzwischen einen eigenen Topic: Hin-/Wegführende Fahrbahnen bei Kreiseln, Routen, Änderung Wiki hierzu
Insbesondere an Kreiseln ist immer wieder vorzufinden, dass die Route nicht korrekt über die links in den Kreisel geht bzw. daraus herauskommt, insbesondere nicht, wenn getrennte highways für die Zu- und Abfahrt modelliert wurden, z.B. wg. Verkehrsinseln, Fußgängerüberwegen etc. Die Anpassung der Route kann durchaus erfordern, gemäß bing auch die Kreuzung anzupassen. Dabei habe ich aus einem Changeset Kommentar gelernt, dass man für die Vekehrsinseln nicht unbedingt Zu- und Abfahrt in getrennte highways legen muss, sondern es bei einem highway für beide Richtungen belässt und einen Node in den einen highway legt, mit traffic_calming=island bei Nur-Inseln oder highway=crossing bei Fußgängerüberwegen (und weitergehenden crossing=* tags). Damit kommt aus der (neuen) Insel kein Komplettumbau der Kreuzung → viel Arbeit gespart und noch mehr das Risiko einer fehlerhaften Änderung vermieden. Wenn aber jetzt der zuvor in ways segmentierte Kreisel in einen einzigen Weg zusammengefasst wurde (siehe 5.2 oben), dann können auch Busrouten betroffen sein, denn die fahren über den Kreisel. Solange diese aufgeräumt sind und dem public transport v2 Schema folgen, ist der impact der Kreiseländerung gering. Wenn aber die Buslinie noch mit forward/backward und mehr arbeitet und schlecht sortiert ist (sprich: Sie ist nicht mehr verständlich), dann muss man entscheiden, ob man entweder die Buslinie zu Teilen aufräumt (was u.U. einen Übergang in pt v2 bedeutet und damit nicht “zu Teilen” geht, viel Arbeit und Risiko), oder aber akzeptiert, dass die Änderung des Kreisels die Buslinie noch ein bisschen unleserlicher macht (aber sie war auch schon vorher nicht verwendbar/verständlich ;)). Ich muss gestehen, dass hier nur die Wahl zwischen Teufel und Belzebub bleibt: Entweder man nimmt eine Verschlechterung in Kauf, oder aber man gerät in die Problematik, dass die Überarbeitung der Buslinie ihrerseits zu neuen Kreiseln mit weiteren impacted Routen oder worst case Buslinien führt (am Ende nicht praktikabel, weil es nie fertig wird). Über goldene Mittelwege kann man nur schwer sagen, was man als Ergebnis der Maßnahme erzielt hat.
Seitdem ich diese Problematik in ihrer vollen Größenordnung erkannt habe, versuche ich im Falle von Buslinien, diese nur anzupacken, wenn es einfach ist (was immer noch schiefgehen kann, denn in Sigmaringen dachte ich, dass es einfach wird. Aber am Ende habe ich die Mehrzahl der Buslinien überarbeitet). Oder ich lasse die Buslinie unverändert, schreibe aber einen entsprechenden Kommentar in den Changeset bzw. FIXME in die Buslinie. Ein Beispiel für letzteres Vorgehen ist der Kreisel in Telfs an der Autobahnausfahrt (Changeset https://www.openstreetmap.org/changeset/62107323). Wenn ich die Buslinie angepackt hätte, hätte ich sie auf pt v2 umstellen müssen (auch weil ich mich nur mit dieser Version von pt einigermaßen auskenne).
Wie gesagt, die Wahl ist zwischen Teufel und Belzebub. Bin gespannt auf Eure Kommentare, denn hier kann man sicher viel diskutieren.
Problem 5.5) Ummappen der Route von der Straße auf die Radwege in der Fläche
Die Problematik, dass 10 Jahre alte Routen nicht mehr die neue Situation bzgl. angelegter und verpflichtend zu nutzender Fahrradwege wiedergeben ist zumindest auf die Länge der Route gesehen fast überall vorhanden. Jede Route auch hier aufzuräumen würde bedeuten, dass man die Route way für way durchsehen muss. Es bedeutet aber weiter, dass z.B. bei Fahrradweg nur auf einer Seite oder auch auf beiden Seiten bekannt sein muss, ob der Fahrradweg in beide Fahrtrichtungen benutzt werden darf oder nur in eine. Diese Information halte ich im allgemeinen nur dann für zuverlässig, wenn explizit oneway=yes oder oneway=no getagged ist (dann hat sich der Mapper Gedanken hierzu gemacht). Alternativ vor Ort vorbeischauen ist schwierig, die Routen sind lang und führen weit weg.
Letztendlich belasse ich die Strecke in der Fläche wie sie ist. Und belasse damit den Fehler, der ja auch schon zuvor eingebaut war. Nur wenn ich, z.B. ausgelöst durch eine Kreuzung, die Fahrradroute sowieso auf die Radwege ummappen musste, ändere ich auch die benachbarten längeren Stücke.
Haltet Ihr dieses Vorgehen für ok?
Problem 6) Wie strukturiert man die changesets?
Nach einigem Ausprobieren und der Problematik immer länger und größer werdender Changesets, von denen ich selber nur sehr schwer nachvollziehen kann, was genau in welchem Changeset gemacht wurde, bin ich dazu übergegangen, die jeweils gelösten Problem kleinzuhalten, also in Schritten ein Teil-Problem nach dem anderen zu lösen und für jede Teillösung einen eigenen changeset zu erstellen. Das läuft dann idealisiert ungefähr so ab (bei einer schlecht geordneten Route A, aber immer noch von Ort X nach Ort Y):
- Öffnen der Routen-Relation A im JOSM Relationen Editor
- Herunterladen aller Element e von A (zumeist ways, aber auch platforms, stop_position etc.)
- Grobsortierung der Route von A im JOSM Relationen Editor, Lücken bleiben offen, Probleme mit Auswüchsen bleiben offen, noch keine Änderung von Kreuzungen/Kreiseln, also kein Mappen, nur die Reihenfolge in der Relation A.
- Changeset mit der grob sortierten Route A, typischerweise nur diese Relation A als einziges geändertes Objekt
- Entlanglaufen an der Route im JOSM Relationen-Editor von Problemstelle zu Problemstelle, zumeist sichtbar als gap. Je Problemstelle
5.1. Herunterladen der Elemente des Problembereichs, um eine aktuelle und vollständige Sicht auf die Objekte zu haben
5.2. Umstrukurieren von ways (dabei bleibt die Relation A unverändert), z.B.
5.2a. splits von ways im Fall von Teilnutzung bei Auswüchsen;
5.2b. Identifikation der Ways, mit denen gaps geschlossen werden, evtl. auch dort vorbereitender split bei Teilnutzung;
5.2c. Änderung der Ways/nodes an einer Kreuzung/Kreisel
5.3. changeset mit nur der Änderung der ways für ein gap, was bei einer Kreuzung/Kreisel immer noch eine ganze Menge angefasster/hinzugefügter ways/nodes bedeuten kann, uploaden. Hier werden u.U. auch bereits geänderte Relationen mit hochgeladen, die JOSM beim Edit der Ways automatisch mitgemacht hat (z.B. bei einem Split auch das abgesplittete Element in die Relation nehmen, in der das Original-Element war)
5.4. Je von der Änderung der ways/nodes betroffener Relation B (also nicht der auslösenden Relation A)
5.4.1. Evtl. Grobsortierung, zumindest muss der Bereich des Eingriffes überschaubar sein (im Relationen-Editor)
5.4.2. Elemente der Relation löschen/hinzufügen/umpositionieren/role ändern (im Relationen-Editor)
5.4.3. Relation sichern bzw. Relationeneditor mit ok abschließen
5.4.4. changeset mit dieser geänderten Relation B (sonst sollte sich nichts geändert haben) uploaden
5.5. Je Relation A ist damit bis jetzt nicht geändert (außer potentiell automatisch von JOSM) - Die Relation A nochmal neu in den Relationeneditor öffnen.
- Nochmaliges entlanglaufen an der Route A im JOSM Relationen-Editor von Problemstelle zu Problemstelle, zumeist sichtbar als gap. Je Problemstelle
7.1. Überflüssige Elemente entfernen (z.B. das absplittet Teilstück, das den “Auswuchs” repräsentiert) bzw. neue einfügen (zum Schließen des gaps) - Die Relation A sichern
- Upload der geänderten Relation A in eigenem changeset.
Das ergibt viele eher kleine changesets, die überschaubar bleiben und entsprechend kommentiert werden können. Die Komplexität ist aber immer noch vorhanden, sie ist jetzt über die vielen changesets verteilt. Wer nur einen einzelnen changeset sieht, versteht das big picture der Serie vielleicht nicht, deshalb ist es wichtig, in den Kommentar zur Änderung von Kreuzungen/Kreiseln reinzuschreiben, dass dies gemacht wurde, damit Relation A unterbrechungsfrei wird.
Noch ein Kommentar bei sehr langen Routen: Wenn man eine Route z.B. Wandern von München nach Venedig so Stück für Stück durchgeht, hat JOSM Probleme dies in einem Durchgang ohne Restart mitzumachen. JOSM läuft meistens gegen Memeory-Probleme, schon alleine deshalb weil man die Karte während des Downloads jeder Stelle so häufig verschieben muss (was anscheinend Speicher kostet). Und man hat das Problem, evtl. 1-2 Tage zu arbeiten und dann am Ende einen Konflikt zu bekommen, weil jemand anderes in der Zwischen zeit einen Knoten geändert hat.
Frage: Haltet Ihr dies für sinnvoll? Oder sollte man die ganze Operation in einen einzigen changeset packen (wovon ich bewusst aufgrund der Erfahrung abgekommen bin), der dann die geänderte Relation A, jede impacted Kreuzung/Kreisel, alle betroffenen Relationen B. Irgendetwas dazwischen (was dann konkret?)
Und zum Schluss noch die generelle Frage: Macht dieses Aufräumen Sinn? Erzeugt es Probleme, die oben nicht benannt und damit nicht adressiert sind?
Ich danke Euch für Eure Geduld, diese doch längeren Ausführungen zu lesen und bin gespannt auf Eure Rückmeldungen (für die ich im Voraus ebenfalls danke)
Bicycle Tourer
ist etwas Arbeit, aber lohnt sich.
