Neuer Mapper bearbeitet Busrelationen

mmd · 2021-03-18T09:15:38.000Z

ToniE:

Aber würde man dann, neben ‘role’, ein generelles “Sortierungskriterium” als tag einführen (und dessen Syntax offen lassen) statt die Reihenfolge der Member zu beachten?

Ist halt das, was ich manchmal sehe: role=stop_1, role=stop_2, … in die Rolle gequetscht. Könnte man dann auch auf die Wege anwenden.

role=stop + sequence=1
role=stop + sequence=2
…
role=‘’ + sequence=1 für ways
role=‘’ + sequence=2

Das würde allerdings nicht das hier lang und breit diskutierte Aufsplitten eines Ways lösen

zunächst müsste für den neuen Way die sequence-Nummer ermittelt werden und

dann müssten alle “sequence”-Nummern “hinter”/“größer dieser” dem gespiltteten Way incrementiert werden
“increment” für sequence > x ist aber einfacher

dann könnte man anhand der sequence-Nummer neu sortieren (im Editor, in der Anwendung?) … oh la la wir wollen ja keine Sortierung der Member (im Editor) mehr?

Ja, die Sortierung der Wege ist ein guter Punkt, das hatte ich in meinem Beispiel gar nicht mit drin. Mit dem extra Tag am Relationsmember hatte ich von der Idee auch eher so etwas in Richtung Highway-Nummerierung in USA im Kopf, wo die Ausfahrten nicht einfach durchgezählt werden, sondern von der Entfernung in Meilen abhängen. Wenn dann eine neue Ausfahrt dazukommt, ändert das nicht die Nummern der anderen Ausfahrten.

Falls sich eine Buslinie nun aber so stark ändert, dass plötzlich 5 neue Haltstellen dazukommen, würde mir aber weder eine Entfernung zum Start der Linie noch eine Zeitdauer wirklich weiterhelfen. Beide würden sich dann für alle nachfolgenden Haltestellen immer ändern.

Zu den Ways: Wenn wir jetzt jeden einzelnen Weg fortlaufend durchnummerieren, bleibt beim Splitten nichts anderes übrig, als die Nummerierung aller nachfolgenden Wege auch wieder anzupassen, am besten automatisch mit Unterstützung durch den Editor.

Wirklich super ist beides nicht. Aber das war ja das Ziel, herauszufinden, ob/wie so ein Konstrukt überhaupt helfen kann.

GerdP · 2021-03-18T11:47:09.000Z

Bin ich der einzige, dem schlecht wird bei dem Gedanken, dass noch mehr kaum nachvollziebare PT Daten ins OSM Datenmodel reingequetscht werden soll? Gibt es nicht genau dafür dieses wikidata Tag?

Weide · 2021-03-18T12:06:36.000Z

miche101:

Des findet man einfach heraus… weil sich dann die Routing in der Länge erheblich verändert.

Zur Qualitätskontrolle müsste man dann historische Daten heranziehen.

miche101:

Ja… stimmt, aber das ganze arbeitet mit GTFS Daten und nicht mit Relationen…Würde es mit Relationen arbeiten… würde bei einer Relation mit Lücke auch nicht mehr richtig funktionieren.

Bei einer PTv2-Route könnte man sehen, dass der Bahnsteig nicht an der Fahrstrecke liegt. Aber ich meinte einen anderen Effekt: Wenn man versehentlich in Köln Deutz den falschen Bahnsteig (aus dem unteren statt dem oberen Teilbahnhof) angibt, dann wird der Router den Zug genauso bekloppt fahren lassen, wie es in kleinerem Maßstab bei TRAVIC bei den Straßenbahnen der Fall ist.

ToniE · 2021-03-18T12:10:29.000Z

GerdP:

Bin ich der einzige, dem schlecht wird bei dem Gedanken, dass noch mehr kaum nachvollziebare PT Daten ins OSM Datenmodel reingequetscht werden soll? Gibt es nicht genau dafür dieses wikidata Tag?

Im Prinzip könnte man sich ja darauf reduzieren, nur die Haltestellen zu mappen ohne dass die Haltestellen in irgendeiner Beziehung zueinander stehen… denn nur die Haltestellen existieren ja. Die Route existiert ja nur “virtuell” durch Auswertung andere Informationen (Fahrpläne).

Dann kommen aber sicherlich einige Leute daher, die dann anmerken, dass man Buslinien nicht mehr auf Karten sehen kann.

Müsste man dann nicht auch so konsequent sein und Rad-/MTB-/Wander-/Ski/…-Routen auch auf deren Hinweisschilder/Wegweiser zu reduzieren?

Seien wir mal realistisch: das simple PTv1-Schema taugt nicht wirklich zu mehr als zum Malen von Buslinie auf Karten. Es taugt nicht einmal für eine einigermaßen brauchbare Qualitätssicherung.

Wenn wir also ernsthaft (im Sinne von “professionell”) mit ÖPNV in OSM arbeiten wollen, müssen wir die Komplexität der Realität irgendwie in eine Datenmodell abbilden und deren Daten in eine Datenbank speichern - das “Malen von Karten” ist ab diesem Punkt nur noch Nebensache.

Die Herausforderung besteht darin, die komplexe Realität in ein möglichst einfaches Datenmodell zu packen, das Editieren einfach zu halten, eine einfache Auswertung und Qualitätssicherung zu ermöglichen, … und den “Kartenmalern” das Leben nicht allzu schwer zu machen (immerhin sind Karten unser Aushängeschild).

PTv2 ist sicherlich nicht das Gelbe vom Ei - sonst hätten wir nicht andauernd solche Diskussionen.

Die Wege aus den Relationen rauszulassen und durch Navigation von Haltestelle zu Haltestelle (ggf. mit Hilfe von ‘via’-Punkten) zu ersetzten ist ein guter Ansatz. Ich habe aber schon zwei negative Aspekte gehört: Kartenmaler brauchen eine Routing-Engine und eine Brückensperrung mag zu fehlerhaften Ergebnissen führen.

just my 2 (EUR) ct

Weide · 2021-03-18T12:14:42.000Z

GerdP:

Bin ich der einzige, dem schlecht wird bei dem Gedanken, dass noch mehr kaum nachvollziebare PT Daten ins OSM Datenmodel reingequetscht werden soll? Gibt es nicht genau dafür dieses wikidata Tag?

Nö, sehe ich auch so.

Aber das Wikidata-Tag verweist auf Wikidata. Wir müssten was haben, mit dem Apps den dazu passenden Fahrplan im Internet finden können.

skyper · 2021-03-18T12:35:27.000Z

GerdP:

Ist alles nur Spaß, oder? Ihr wollt nicht ernsthaft Fahrpläne in OSM abbilden, oder? Wahrscheinlich dann auch noch mit Gültigkeits-Perioden, damit auch irgendwer schauen kann, ob der Bus schon immer am Ostersonntag um 8:10 die Haltestelle in Pusemuckelsdorf ausgelassen hat. Ja klar. Das ist wichtig, aber der 1.4. ist noch ein paar Tage entfernt.

+1, sehr passend.

mmd:

PTv2 ist wahrscheinlich so fragil, weil es zu sehr im Grenzbereich des aktuellen Datenmodells liegt.

Diese Aussage verstehe ich nicht. Eine Sortierung ist doch nicht Grenzgebiet.

Weide:

mmd:

Für PTv2 würde ich dort z.B. Eigenschaften wie “nur Einstieg” oder “nur Ausstieg” unterbringen, statt das irgendwie in die Rolle zu quetschen.

In PTv2 darf man nichts in die Rolle quetschen. Alle Rollen sind klar festgelegt.

+1, zudem funktioniert es doch mit den Rollen für nur Ein- oder Ausstieg.

Weide:

mmd:

wenn man z.B. den Zeitpunkt eines Stops durch Hinzufügen eines Zeitstempels eindeutig macht, also “Stop wird immer nach 00:37 Minuten gemessen ab Startzeitpunkt der Linie angefahren”.

Dann bekommen wir zuviele Varianten. Viele Busse haben zu unterschiedlichen Uhrzeiten ein unterschiedliches Timing. Bei Zügen gibt es für eine Variante unterschiedliche Aufenthaltszeiten an wichtigen Umsteigebahnhöfen je nach Timing der anderen Züge.

+1, sehe ich genau so.

mmd:

https://wiki.openstreetmap.org/wiki/API_v0.7#Tags_for_relation_members._Role_is_not_enough

So wie ich dies verstehe geht es hier für PT-Relation nur um den Fahrplan und eine Modellanpassung an diesen.
Warum nicht endlich GTFS aufräumen/verbessern, damit da wenigstens mehr Konsistenz bei den Ids enthalten ist und sich nicht bei nur einer kleinen Änderung alle shape_id und trip_id änder können. Das gleiche trifft zu, wenn eine Variante mal aussetzt. Die alte Id wird nicht entsprechend wieder verwendet, wenn die Variante wieder aufgenommen wird. Das ist alles viel zu kurzlebig gedacht. Ganz zu Schweigen von einem Archiv der alten GTFS-Daten.

Eine Verlinkung mit dem Fahrplan sollte über die Ids jetzt schon möglich sein, nur passe ich die Ids doch nicht alle paar Wochen an, nur weil es eben einen Monat länger keinen Schulverkehr gibt.

Weide:

mmd:

Das war nur ein Beispiel, es geht mir um das Prinzip von der Sortierung der member wegzukommen.

Das ist ein wichtiges Ziel für das nächste PTv.

Verstehe ich nicht. Nur weil die Software die Api nicht richtig unterstützt und auf richtige Reihenfolge achtet.

Weide:

Eine andere Möglichkeit wäre die folgende:
Man unterteilt die Gesamtstrecke durch Markierungsnodes in einzelne Stücke (meist nur eins), die selbstberührungsfrei und selbstkreuzungsfrei und lückenlos oder für Lücken ganz leer sind. Die Reihenfolge innerhalb der Stücke ist dann egal und die Stücke sind automatisch sortierbar. Splitten von Wegen ändert daran nichts. Ein sehr großer Anteil der weiteren heutigen “Kaputtänderungen” wäre so automatisch feststellbar. Fehlende Stücke am Anfang und Ende wären anders als jetzt erstmalig mappbar.

An so etwas habe ich auch schon mal gedacht. Eine Zwischenebene für die Strecke mit Segmenten und die Variante dann ähnlich einer Superroute mit den Haltestelle und den Segmenten. Würde allerdings pro Linie und Richtung jeweils Segmente erstellen und diese nicht für alle Linien auf einer Strecke verwenden, da sonst der Bezug zu den einzelnen Linien schnell verloren geht. An (Bus-)Bahnhöfen wird es etliche Segment-Relationen geben und insgesamt sind es auf jeden Fall noch mehr als bei PTv2.
Habe leider nicht ganz verstanden was Du mit diesen Lücken meinst, wobei ich mir nicht sicher bin, ob leere Relationen gut funktionieren. Ist gar nicht einfach die überhaupt zu finden.

Weide:

miche101:

ja ich würde die Fahrstrecke ganz weg lassen… das kann man mit Routing machen… dafür bräuchte es machmal nur ein paar Via Punkte.

Man könnte auf die Fahrstrecke verzichten … kann man auch jetzt schon. Von Routing – auch mit via-Punkten – halte ich nichts. Wenn da irgendwo eine Brücke gesperrt wird, dann würde nicht mehr angezeigt, dass die Buslinie nicht mehr stimmt. Statt dessen würde irgendwas plausibel aussehendes aber vermutlich falsches dargestellt, denn der Automat macht bestimmt nicht das, was das Verkehrsunternehmen unter Berücksichtigung möglicher Haltestellenverlegungen und Umsteigemöglichkeiten beschließen wird.

Kleine Mappingfehler bekommen so auch große Folgen wie man bei https://tracker.geops.ch/?z=14&s=1&x=774535.9915&y=6610374.3981&l=transport alle paar Minuten an der Linie 5 sehen kann (rasender gelber Punkt).

Halte auch nicht viel von via Punkten und die sind noch anfälliger als Linien, weil hier der Bezug verlören geht. War schon bei TMC-Points ein Grund auch Wege mit in die Relationen aufzunehmen.

skyper · 2021-03-18T12:43:42.000Z

Weide:

GerdP:

Bin ich der einzige, dem schlecht wird bei dem Gedanken, dass noch mehr kaum nachvollziebare PT Daten ins OSM Datenmodel reingequetscht werden soll? Gibt es nicht genau dafür dieses wikidata Tag?

Nö, sehe ich auch so.

+1, vor allem dieser Ansatz.

Weide:

Aber das Wikidata-Tag verweist auf Wikidata. Wir müssten was haben, mit dem Apps den dazu passenden Fahrplan im Internet finden können.

Ja, das ist wohl eher das Problem, möglichst langlebige Ids der einzelnen Varianten zu erzeugen, die sich nicht weil Fasnet ausfällt oder die Schulferien zwei Tage früher beginnen ändern. Bei der Wiederaufnahme nach Schienenersatzverkehr ist es häufig das gleiche. Das ist aber eher Aufgabe der Verkehrs-Unternehmen.

skyper · 2021-03-18T13:10:36.000Z

Mammi71:

Ganz ehrlich: seit PTv2 bin ich raus aus dem ÖPNV-Mapping. Außer Haltestellen trage ich in diesem Bereich nichts mehr bei, und die sind auch nicht in irgendwelche Relationen eingebunden, sondern maximal standalone. Und wenn ich diesen thread so lese fühle ich mich bestätigt.

Schade, das Du mit den Relationen nichts anfangen kannst. Wo ist das Problem. Ich empfinde PTv2 als einfacher, da es nicht eine Mammut-Relation ist, sondern jede Variante ersichtlich und klar strukturiert ist.

Haltestellen zu erfassen und zu überprüfen ist aber eine Hauptaufgabe. Brauche meist für die Haltestellen genauso lange wie für das Erstellen der 20 Relationen danach.

miche101:

Mammi71:

Und die Gefahr vor Augen, irgendwo was versehentlich kaputt zu machen, schränkt mich auch in den weiteren Mapping-Tätigkeiten zunehmend ein. Ich glaube, auf Dauer bekommt das dem Projekt nicht so gut, wenn immer alles komplizierter wird. Das schreckt neue Mapper zunehmend ab.

Keine Angst, keine Angst… Jeder macht Fehler oder ist vielleicht mit der Situation überfordert.

+1, im Zweifel doch einfach hier mal nachfragen ob es korrekt ist.
PTv2 ist wenigstens für die Software einfacher als PTv1. Warum schreckt es ab? Liegt es an der fehlenden Unterstützung der Editor-Software?

miche101:

Ich sag einmal so… Die Straßen Daten gehen vor und wenn einer mit dem Relationen überfordert ist dann soll das nicht verhindern z.b. den Kreisel einzuzeichnen. Dann ist es OK ein Loch in die Relationen hinein zu reißen.

Mir persönlich graust es schon weil in Poing ein neuer Kreisel geplant ist… Wo 13 Relationen aus der einen, 10 auf der anderen und 5 auf der letzten Straße sind

Das JOSM-Plugin “pt_assistant” bietet dafür eine Funktion an. Bin mir nur nicht sicher wie weit es mit geteilten Auf- bzw Abfahrten klar kommt.

miche101 · 2021-03-18T15:04:18.000Z

Weide:

historische Daten heranziehen.

Ja das wäre toll… ist momentan schwer bis unmöglich die Sache anzuschauen wie sie vor der Zerstörung war… oder gar rückgängig zu machen.

Weide:

Router den Zug genauso bekloppt fahren lassen

Sonderfall beim Zug der über mehreren Ebenen fährt… man braucht ja nicht alles umstellen aber Bus wäre ein anfang… da ändert sich auch regelmässig was und gibt es wesentlich mehr varianten.

miche101 · 2021-03-18T15:07:53.000Z

skyper:

PTv2 ist wenigstens für die Software einfacher als PTv1.

Welche Software? außer Editoren, Renderer. OSMand mit dem versucht Öpnv routing ohne Timetable???

ghostrider44 · 2021-03-18T16:46:09.000Z

Nachdem das von mir eingestellte Thema doch erhebliche Ausmaße angenommen hat und der Mapper nach dem Umstieg auf JOSM und einigen Tipps die Relationen nicht mehr beschädigt, sondern nach wenigen Tagen schon in der Lage ist, veraltete Relationen zu verbessern und neue anzulegen, sollten wir die Probleme zum Erstellen einer PTv2-Relation nicht größer machen, als sie sind. Die Überschrift zum Thema habe ich deshalb geändert von “beschädigt” auf “bearbeitet”, da sie ja so nicht mehr zutraf.

Weide · 2021-03-18T18:31:11.000Z

skyper:

An (Bus-)Bahnhöfen wird es etliche Segment-Relationen geben und insgesamt sind es auf jeden Fall noch mehr als bei PTv2.
Habe leider nicht ganz verstanden was Du mit diesen Lücken meinst, wobei ich mir nicht sicher bin, ob leere Relationen gut funktionieren. Ist gar nicht einfach die überhaupt zu finden.

Keine Segmentrelationen! Das hab ich früher irgendwann mal vorgeschlagen und ausgearbeitet, aber beim Ausprobieren auf eigenem Datenbestand hat sich das als zu kompliziert gezeigt. Ich bin inzwischen nicht mehr für Segmentrelationen.

Im obigen Vorschlag gibt es keine zusätzlichen Relationen. Es gibt nur Nodes, die komplizierte Fahrwege in einfache Abschnitte aufteilen. Diese Abschnitte haben keine Schleifen oder Selbstberührungen und keine Lücken und gehen immer vom letzten Markierungsnode zum nächsten. Sie können daher immer automatsch richtig sortiert werden. Splitten von Wegen wird einfach. Viele andere Fehler wie Kürzen eines Weges ohne Beachtung der Relation oder Längssplitten eines Weges ohne Rücksicht auf die Relation werden dabei zu automatisch erkennbaren Fehlern. Mit zwei unmittelbar aufeinanderfolgenden Nodes wird ein leeres Stück angegeben. Bei einfachen Buslinien würde man mit einem Anfangsnode und einem Endnode auskommen … mehr Markierungsnodes braucht man nur bei komplizierten Wegführungen.

skyper · 2021-03-18T18:40:12.000Z

ghostrider44:

Nachdem das von mir eingestellte Thema doch erhebliche Ausmaße angenommen hat und der Mapper nach dem Umstieg auf JOSM und einigen Tipps die Relationen nicht mehr beschädigt, sondern nach wenigen Tagen schon in der Lage ist, veraltete Relationen zu verbessern und neue anzulegen, sollten wir die Probleme zum Erstellen einer PTv2-Relation nicht größer machen, als sie sind. Die Überschrift zum Thema habe ich deshalb geändert von “beschädigt” auf “bearbeitet”, da sie ja so nicht mehr zutraf.

Das nenne ich mal “happy news”. Eventuell ist JOSM und PTv2 für manche Personen doch nicht so schwer zu lernen.

skyper · 2021-03-18T18:52:12.000Z

Weide:

skyper:

An (Bus-)Bahnhöfen wird es etliche Segment-Relationen geben und insgesamt sind es auf jeden Fall noch mehr als bei PTv2.
Habe leider nicht ganz verstanden was Du mit diesen Lücken meinst, wobei ich mir nicht sicher bin, ob leere Relationen gut funktionieren. Ist gar nicht einfach die überhaupt zu finden.

Keine Segmentrelationen! Das hab ich früher irgendwann mal vorgeschlagen und ausgearbeitet, aber beim Ausprobieren auf eigenem Datenbestand hat sich das als zu kompliziert gezeigt. Ich bin inzwischen nicht mehr für Segmentrelationen.

Im obigen Vorschlag gibt es keine zusätzlichen Relationen. Es gibt nur Nodes, die komplizierte Fahrwege in einfache Abschnitte aufteilen. Diese Abschnitte haben keine Schleifen oder Selbstberührungen und keine Lücken und gehen immer vom letzten Markierungsnode zum nächsten. Sie können daher immer automatsch richtig sortiert werden. Splitten von Wegen wird einfach. Viele andere Fehler wie Kürzen eines Weges ohne Beachtung der Relation oder Längssplitten eines Weges ohne Rücksicht auf die Relation werden dabei zu automatisch erkennbaren Fehlern. Mit zwei unmittelbar aufeinanderfolgenden Nodes wird ein leeres Stück angegeben. Bei einfachen Buslinien würde man mit einem Anfangsnode und einem Endnode auskommen … mehr Markierungsnodes braucht man nur bei komplizierten Wegführungen.

Ah, danke. Nach erneutem Lesen habe ich es verstanden, auch wie Du das mit Lücken meinst. Für die Markierungsnodes bräuchte es noch eine Rolle und Anfang und Ende ist beim Straßenverkehr ja schon mit der stop_position abgedeckt. Beim Zug ist das ja Ansichtssache.

Für JOSM wäre dafür dieses Ticket interessant: https://josm.openstreetmap.de/ticket/18645

skyper · 2021-03-18T19:33:09.000Z

miche101:

Weide:

Router den Zug genauso bekloppt fahren lassen

Sonderfall beim Zug der über mehreren Ebenen fährt… man braucht ja nicht alles umstellen aber Bus wäre ein anfang… da ändert sich auch regelmässig was und gibt es wesentlich mehr varianten.

Wie bitte? Hast Du mal Beispiele? Sehe eher das Gegenteil:

RE 7 https://ptna.openstreetmap.de/gtfs/DE/trips.php?feed=DE-SPNV&release_date=&route_id=90-T07-j21-1
S1 schon im GTFS zerlegt:

S1 https://ptna.openstreetmap.de/gtfs/DE/trips.php?feed=DE-S-und-U-Bahnen&release_date=&route_id=92-R01-F-j21-1
S10 https://ptna.openstreetmap.de/gtfs/DE/trips.php?feed=DE-S-und-U-Bahnen&release_date=&route_id=92-R10-F-j21-1
S11 https://ptna.openstreetmap.de/gtfs/DE/trips.php?feed=DE-S-und-U-Bahnen&release_date=&route_id=92-R11-F-j21-1

miche101:

skyper:

PTv2 ist wenigstens für die Software einfacher als PTv1.

Welche Software? außer Editoren, Renderer. OSMand mit dem versucht Öpnv routing ohne Timetable???

Beim Renderer ist die Frage was dargestellt werden soll, aber generell sind strukturierter Daten einfacher zu Verarbeiten. Die Fehleranalyse und PTNA hast Du z.B vergessen. Welche Software kommt den besser klar mit PTv1 anstatt PTv2?

miche101 · 2021-03-18T20:02:08.000Z

skyper:

Wie bitte? Hast Du mal Beispiele? Sehe eher das Gegenteil:

Ich weiß nicht was du verstanden hast… Aber beim Routing arbeitet man lat/lon… Wenn die Wege aber übereinander liegen kann es zu Problemen. Da müsste man noch den Layer angeben um das zu umgehen zu können

skyper:

Fehleranalyse

Stimmt… Aber gibt’s eine nützliche Anwendung von ptv2? Ptv1 war und ist gut zum Karte rendern… Das genügte dann auch

Weide · 2021-03-19T05:20:04.000Z

skyper:

… und Anfang und Ende ist beim Straßenverkehr ja schon mit der stop_position abgedeckt. Beim Zug ist das ja Ansichtssache.

Die stop_position ist in PTv2 nie verpflichtend vorhanden … Platform alein reicht ja auch.

Aber ich würde das sowieso nur als Konzept für das nächste PTv sehen und dann auch die Zweiteilung stop-platform rauswerfen. Wir brauchen nur die Anfangs- und Endangaben für das Routing der Passagiere vor und nach Benutzung des ÖPV. Passagiere in diesem Sinn sind Fußgänger, Radfahrer, Rollstuhlfahrer und bei Fähren sogar Autos. Solche Objekte wären meist die jetzigen Platforms, können aber auch mal erheblich davon abweichen (Ich hatte mal einige hundert Meter zwischen der Stelle zu der ich gehen musste und der Stelle an der die Fähre dann abfuhr … wir wurden als Herde per Bus zum Kai gekarrt. Ständig passiert das z.B. in Schweden bei vielen Busstationen, bei denen man am Bussteig nicht warten kann und darf. Man wartet im Gebäude bis der Busfahrer die Türen des Busses und die Gebäudetüren öffnet und der Bussteig fungiert nur als Fußweg.)

Neuwessi11 · 2021-03-19T19:50:54.000Z

Hallo!
Ich möchte nochmal zu dem anfangs angesprochenen Problem zurückkommen, da ich neu hier bin (ein freundliches “Guten Abend!” in die Runde), mich hauptsächlich mit dem Ergänzen und Korrigieren von diversen maxspeeds und lanes befasse (das schien mir bis heute vormittag auch recht einfach und intuitiv zu sein) und von einem Kollegen darauf hingewiesen wurde, dass dabei wegen der öfter mal notwendigen Wegteilungen Fehler bei den Buslinien entstehen können.

Viele der hier gerade geführten Diskussionen fand ich ziemlich faszinierend, aber für mich als Einsteiger definitiv einige Level zu hoch.
Deshalb möchte ich mal ganz konkret die simple Einsteiger-Frage in die Runde werfen:
Was kann ich denn nun abgesehen von der rocket sience machen, damit eine simple Wegteilung nicht alle betroffenen Buslinien zerstört? Ich will doch nur turn:lanes und maxspeeds eintragen …
Grüße!
Neuwessi11

SafetyIng · 2021-03-19T21:47:35.000Z

Neuwessi11:

Was kann ich denn nun abgesehen von der rocket sience machen, damit eine simple Wegteilung nicht alle betroffenen Buslinien zerstört? Ich will doch nur turn:lanes und maxspeeds eintragen …

So wie ich den #40 verstanden habe: Anstatt ID eher JOSM verwenden (ich habe bisher keine direkten Erfahrungen dazu, kann mich also nur an den Vorrednern orientieren)

Weide · 2021-03-20T06:23:33.000Z

FvGordon:

Seit einigen Monaten erscheint in JOSM beim Teilen eines Weges, der z.B. zu einer Route-Relation gehört, ein neues Fenster, das fragt, ob einige zusätzliche Mitglieder der Relation heruntergeladen werden sollen. Bejaht man diese Frage (und beantwortet man auch die nächste, ob diese Entscheidung weiterhin angewendet werden soll), werden die beiden an diesen Weg auf beiden Seiten angrenzenden Relationsmitglieder geladen, um die Position zu bestimmen, wo in der Relation das neue Wegstück eingefügt werden soll.

Leider wird dadurch das Problem nicht vollständig beseitigt.
Beispiel: Läd man die Relation 9197409 und splittet den Weg 26516141, dann fehlen danach immer noch beide angrenzenden Wege der Relation 1721547 und damit ist das Einfügen der neuen Wege dort genauso zufällig wie vorher. (Oder mein JOSM ist zu alt…)

Es bleibt daher dabei:

den zu splittenden Weg auswählen
seine beiden Endpunkte zusätzlich auswählen
ALT-CTRL-D tippen (“Eltern laden”)
dann erst splitten