Neuer Mapper bearbeitet Busrelationen

ghostrider44 · 2021-03-09 11:33:34

Bei der Prüfung der Buslinien mit https://ptna.openstreetmap.de/results/D … tml#A2.5.7 habe ich festgestellt, dass insbesondere im Raum Backnang zahlreiche Busrelationen etliche Fehler aufweisen. Auch 2 Relationen, die in den Bereich des Kreises Ludwigsburg führen und die ich schon mal überarbeitet hatte, sind davon betroffen. Der Kollege verwendet dafür den iD-Editor, der m.E. für Busrelationen nicht geeignet ist. Ich habe den Kollegen gestern angeschrieben, s.u. https://www.openstreetmap.org/changeset … 91/9.42478 . Er hat noch nicht geantwortet, macht aber eifrig weiter. Seine Tätigkeit sollte überprüft werden, um den Schaden in Grenzen halten zu können.

Last edited by ghostrider44 (2021-03-18 17:44:25)

ToniE · 2021-03-09 11:46:59

ghostrider44 wrote:

Bei der Prüfung der Buslinien mit https://ptna.openstreetmap.de/results/D … tml#A2.5.7 habe ich festgestellt,

Servus ghostrider44,

ein fast unbekanntes Feature bei PTNA: man kann die Linien direkt addressieren: (<route>_<ref> oder <relation-ID>)

* https://ptna.openstreetmap.de/results/D … ml#bus_455

* https://ptna.openstreetmap.de/results/D … ml#bus_457

* https://ptna.openstreetmap.de/results/D … l#11679631

Sorry, dass ich mit der Dokumentation ziemlich hinterher hinke.

Gruß,Toni

Edit: bin mir nicht mehr sicher, ob 'skyper' oder jemand anders den Feature-Request gestellt hatte.

Last edited by ToniE (2021-03-09 11:48:55)

*abq* · 2021-03-09 12:46:47

Das mit den Busrelationen habe ich selbst auch schon unwissentlich mit iD verursacht. Da reicht ein simples Teilen eines ways mit iD anscheinend aus.

Ich kann das selbst nicht nachvollziehen, da ich mich mit Busrelationen noch nie befasst habe, aber skyper hat mich darauf aufmerksam gemacht.

Bei Wanderrelationen scheint das Teilen eines ways hingegen die Relation in der Sortierreihenfolge zu erhalten.
VG Reiner

Skinfaxi · 2021-03-09 20:53:49

Nur um es gesagt zu haben: gehen Metadaten wie Buslinien kaputt, weil jemand die Grunddaten verbessert, kann man über den Begriff "Schaden" zumindest diskutieren.

dooley · 2021-03-09 21:18:29

Der User ändert auch Schlüssel an administrative Grenzen, damit werden die nicht mehr auswertbar. Innerhalb 2 Tagen 2 x.

History ganz nach rechts scrollen.

Rainero · 2021-03-09 22:54:12

*abq* wrote:

Das mit den Busrelationen habe ich selbst auch schon unwissentlich mit iD verursacht. Da reicht ein simples Teilen eines ways mit iD anscheinend aus.
Ich kann das selbst nicht nachvollziehen, da ich mich mit Busrelationen noch nie befasst habe, aber skyper hat mich darauf aufmerksam gemacht.
Bei Wanderrelationen scheint das Teilen eines ways hingegen die Relation in der Sortierreihenfolge zu erhalten.
VG Reiner

Skinfaxi wrote:

Nur um es gesagt zu haben: gehen Metadaten wie Buslinien kaputt, weil jemand die Grunddaten verbessert, kann man über den Begriff "Schaden" zumindest diskutieren.

Die Buslinien sind aber wohl Hauptziel des Mappers, nicht Kollateralschaden.
Ich kommentiere mal den Änderungssatz mit dem seltsamen Kommentar.

Weide · 2021-03-10 20:12:54

*abq* wrote:

Das mit den Busrelationen habe ich selbst auch schon unwissentlich mit iD verursacht. Da reicht ein simples Teilen eines ways mit iD anscheinend aus.

Wenn man einen nicht in sich geschlossenen Weg an einem Node auftrennt, dann macht der iD das m.W. automatisch richtig und ist damit in diesem einen Fall sogar besser als der JOSM.

Aber ansonsten ist der iD für PTv2-Routen ungeeignet. Es wäre schön wenn er sich weigern würde, sie zu editieren. Noch schöner wäre es, wenn der iD akzeptieren würde, dass OSM-Relationen keine mathematischen Relationen sind ... das also in der Reihenfolge der Elemente Informationen stecken dürfen, die nicht automatische erzeugbar oder reproduzierbar sind.

OSM_RogerWilco · 2021-03-10 20:19:42

Worauf muss ich als ID-User denn achten, bzw. was genau darf man nicht mit ID machen?

ToniE · 2021-03-10 20:44:36

OSM_RogerWilco wrote:

Worauf muss ich als ID-User denn achten, bzw. was genau darf man nicht mit ID machen?

Ich nutze seit Jahren JOSM und nur gelegentlich iD, mein Eindruck bzgl. iD mag also "gefärbt" sein.

Ich empfand die Handhabung von Relationen in iD als sehr unübersichtlich und umständlich.Ich kann dem echt nichts abgewinnen.

Rad-/Wander-/ÖPNV-/Road-/...-Relationen sind empfindlich was die Reihenfolge ihrer Elemente (Member) angeht.
Bei größeren Relationen wird das in Id wohl sehr unübersichtlich, welches Element wo steht und wo es eigentlich hingehört.

JOSM hat hier einen eigenen komfortablen Relations-Editor, bei dem man auch automatisch sortieren kann (aber häufig unbedingt manuell machen sollte)

MKnight · 2021-03-10 21:28:50

Weide wrote:

*abq* wrote:
Das mit den Busrelationen habe ich selbst auch schon unwissentlich mit iD verursacht. Da reicht ein simples Teilen eines ways mit iD anscheinend aus.
Wenn man einen nicht in sich geschlossenen Weg an einem Node auftrennt, dann macht der iD das m.W. automatisch richtig und ist damit in diesem einen Fall sogar besser als der JOSM.

Wie meinst Du das? Wenn die angeschlossenen Member geladen sind, dann macht JOSM das auch richtig.

Weide · 2021-03-10 21:41:46

MKnight wrote:

Wie meinst Du das? Wenn die angeschlossenen Member geladen sind, dann macht JOSM das auch richtig.

Ja. Ich meinte, dass iD das m.W. immer richtig macht und man bei JOSM etwas vorbereiten muss, nämlich den Weg und beide Endpunkte anwählen und dann "Eltern laden". Tut man das nicht vorher, dann macht JOSM zu 50% Quatsch. Ich hab ne dreistellige Zahl solcher Fehler korrigiert und sie stammten nie aus iD und das fand ich gut. Auch wenn ich ansonsten eine eher aggressive Haltung zu iD habe ... das muss ich ihm lassen.

Weide · 2021-03-10 21:43:06

OSM_RogerWilco wrote:

Worauf muss ich als ID-User denn achten, bzw. was genau darf man nicht mit ID machen?

Ich benutze auch nur ganz ganz selten iD und meine Meinung kann veraltet sein ... verlass Dich nicht darauf.

Einen offenen Weg an einem Node durchschneiden ist mW. kein Problem im iD. Im JOSM sollte man VORHER sowohl den Weg als auch seine beiden Endpunkte anwählen und Alt-Ctrl-D machen ("Eltern laden").

Das Ändern von Tags ist auch kein Problem.

Das Hinzufügen von Membern ist bei PTv1-Routen, Route-Mastern und Stop_Areas kein Problem. Aber bei PTv2-Routen. (Die Funktion "zur Relation hinzufügen" ohne eine Einfügestelle anzugeben gibt es auch im JOSM und ist da ebenfalls unbrauchbar.) Falls es eine Funktion "automatisch Sortieren" gibt: Finger weg (auch im JOSM).

Bei Nicht-ÖPV-Relationen habe ich verschiedene Meinungen gehört und sag mal lieber nichts.

Weide · 2021-03-10 21:49:56

ghostrider44 wrote:

Er hat noch nicht geantwortet

Inzwischen hat er geantwortet und das Ganze sieht nach konstruktiver Diskussion aus.

ghostrider44 · 2021-03-11 11:02:18

Wir haben inzwischen persönliche Nachrichten ausgetauscht. Bei den nicht ganz einfachen Busrelationen habe auch ich schon Fehler begangen. Gemeinsam werden wir es schon in Ordnung bringen.

axelr · 2021-03-11 11:58:07

Weide wrote:

....Ja. Ich meinte, dass iD das m.W. immer richtig macht und ...

In den letzte drei Monaten habe ich den Eindruck, dass iD beim Auftrennen von Wegen die Reihenfolge in Routen testet, dann aber falsch herum zusammensetzt.

*abq* · 2021-03-12 08:44:00

Wie gesagt, bei mir war es auch so. Simples Auftrennen eines ways (Straße) mit iD hat die daraufliegende Busrelation beschädigt. Was genau beschädigt wurde, kann ich nicht sagen, da ich mich mit Busrelationen noch nie beschäftigt habe, aber ich vermute mal irgendwelche Reihenfolgen.
Siehe hier
https://www.openstreetmap.org/way/50089361 und der dazugehörige Änderungssatz mit Kommentar von Skyper https://www.openstreetmap.org/changeset/99216821

VG Reiner

SimonPoole · 2021-03-12 09:56:33

Weide wrote:

...
Das Hinzufügen von Membern ist bei PTv1-Routen, Route-Mastern und Stop_Areas kein Problem. Aber bei PTv2-Routen. (Die Funktion "zur Relation hinzufügen" ohne eine Einfügestelle anzugeben gibt es auch im JOSM und ist da ebenfalls unbrauchbar.) Falls es eine Funktion "automatisch Sortieren" gibt: Finger weg (auch im JOSM).
Bei Nicht-ÖPV-Relationen habe ich verschiedene Meinungen gehört und sag mal lieber nichts.

Des Pudelskern: es ist weniger ein Problem der Editoren, sondern eines Taggingschemas, dass für die Praxis viel zu wenig robust ist.

Weide · 2021-03-13 07:05:13

SimonPoole wrote:

Des Pudelskern: es ist weniger ein Problem der Editoren, sondern eines Taggingschemas, dass für die Praxis viel zu wenig robust ist.

Ja, es ist zuwenig robust. Für die Fahrwege habe ich eine robustere Lösung ausgearbeitet ... es ist also möglich. Aber bei den Haltestellen sehe ich keine praktikable Lösung. (Durchnumerierte Roles haben wir damals ausprobiert und es ist einfach Müll).

Des Pudels Kern liegt aber m.E. woanders:
Seit 2009 dürfen Relationen Informationen in der Reihenfolge der Member haben und wenn ein Editor das einfach nicht unterstützen will, dann ist das schon gegen OSM gerichtet. Man kann ja die Relationen wieder mathematisch (ohne Reihenfolge) machen ... aber das ist dann eine Entscheidung von OSM und nicht von einem Editor.

SimonPoole · 2021-03-13 08:23:58

Weide wrote:

SimonPoole wrote:
Des Pudelskern: es ist weniger ein Problem der Editoren, sondern eines Taggingschemas, dass für die Praxis viel zu wenig robust ist.
Ja, es ist zuwenig robust. Für die Fahrwege habe ich eine robustere Lösung ausgearbeitet ... es ist also möglich. Aber bei den Haltestellen sehe ich keine praktikable Lösung. (Durchnumerierte Roles haben wir damals ausprobiert und es ist einfach Müll).

Das Thema ist indirekte Änderungen bei Relationen, dass kommt naturgemäss bei den Haltestellen eher selten vor (Node merge dürfte der einzige relevante Fall sein der potentiell zu Problemen führt), und deshalb ist das weniger problematisch (wobei das Problem bleibt das es keinen algorithmischen Weg gibt die Nodes korrekt anzuordnen).

Des Pudels Kern liegt aber m.E. woanders:
Seit 2009 dürfen Relationen Informationen in der Reihenfolge der Member haben und wenn ein Editor das einfach nicht unterstützen will, dann ist das schon gegen OSM gerichtet.

Was sich 2009, d.h. API 0.5 -> 0.6 vor allem geändert hat, ist das eine Relation mehrmals das gleiche Element mehrmals beinhalten darf (0.6 hat sprachlich klargestellt, dass die Reihenfolge der Elemente erhalten bleibt, aber IMHO war das technisch immer so), vorher war das, und ergab auch, ein Fehler.

Man kann ja die Relationen wieder mathematisch (ohne Reihenfolge) machen ... aber das ist dann eine Entscheidung von OSM und nicht von einem Editor.

Die Probleme sind ja die Fälle "Strasse wird zweimal befahren" und "mehrmalig benutzte Kreuzung", was sich durch eine Nummerierung wohl lösen lässt (die muss nicht einmal global für die ganze Relation sein, sondern nur für die Wege mit mindestens einem gemeinsamen Punkt). Natürlich nur wenn man überhaupt noch Wege in PT Routen haben will.

Last edited by SimonPoole (2021-03-14 17:27:44)

skyper · 2021-03-14 15:41:53

ToniE wrote:

ghostrider44 wrote:
Bei der Prüfung der Buslinien mit https://ptna.openstreetmap.de/results/D … tml#A2.5.7 habe ich festgestellt,
Servus ghostrider44,
ein fast unbekanntes Feature bei PTNA: man kann die Linien direkt addressieren: (<route>_<ref> oder <relation-ID>)
* https://ptna.openstreetmap.de/results/D … ml#bus_455
* https://ptna.openstreetmap.de/results/D … ml#bus_457
* https://ptna.openstreetmap.de/results/D … l#11679631
Sorry, dass ich mit der Dokumentation ziemlich hinterher hinke.

Die Übersetztung der gesamten Seite fehlt halt noch: https://wiki.openstreetmap.org/wiki/Pub … dden_Links

Beim RVF habe ich es auf der Seite dokumentiert: https://ptna.openstreetmap.de/results/D … tml#A2.1.2

ToniE wrote:

Edit: bin mir nicht mehr sicher, ob 'skyper' oder jemand anders den Feature-Request gestellt hatte.

Nee, das kommt nicht von mir. Ich habe nur vorgeschlagen es auch beim GTFS auf routes.php auch anzuwenden. Z.B. https://ptna.openstreetmap.de/gtfs/DE/r … #train_N49

skyper · 2021-03-14 16:13:26

*abq* wrote:

Das mit den Busrelationen habe ich selbst auch schon unwissentlich mit iD verursacht. Da reicht ein simples Teilen eines ways mit iD anscheinend aus.
Ich kann das selbst nicht nachvollziehen, da ich mich mit Busrelationen noch nie befasst habe, aber skyper hat mich darauf aufmerksam gemacht.
Bei Wanderrelationen scheint das Teilen eines ways hingegen die Relation in der Sortierreihenfolge zu erhalten.
VG Reiner

Nee, habe auch bei einfachen Wanderwegen und `route=road` Relationen das Problem entdeckt, s.u..

Weide wrote:

Wenn man einen nicht in sich geschlossenen Weg an einem Node auftrennt, dann macht der iD das m.W. automatisch richtig und ist damit in diesem einen Fall sogar besser als der JOSM.
Aber ansonsten ist der iD für PTv2-Routen ungeeignet. Es wäre schön wenn er sich weigern würde, sie zu editieren. Noch schöner wäre es, wenn der iD akzeptieren würde, dass OSM-Relationen keine mathematischen Relationen sind ... das also in der Reihenfolge der Elemente Informationen stecken dürfen, die nicht automatische erzeugbar oder reproduzierbar sind.

Mmh, da hat iD meine korrekt sortierte Kreis-Variante (`roundtrip=yes`) komplett umsortiert und den neuen Weg als ersten verwendet ohne ersichtlichen Grund und ohne auf die Stops zu achten: https://www.openstreetmap.org/changeset/100123894

Weide wrote:

MKnight wrote:
Wie meinst Du das? Wenn die angeschlossenen Member geladen sind, dann macht JOSM das auch richtig.
Ja. Ich meinte, dass iD das m.W. immer richtig macht und man bei JOSM etwas vorbereiten muss, nämlich den Weg und beide Endpunkte anwählen und dann "Eltern laden". Tut man das nicht vorher, dann macht JOSM zu 50% Quatsch. Ich hab ne dreistellige Zahl solcher Fehler korrigiert und sie stammten nie aus iD und das fand ich gut. Auch wenn ich ansonsten eine eher aggressive Haltung zu iD habe ... das muss ich ihm lassen.

Wer in JOSM mit unvollständigen Daten außerhalb der Download-Area arbeitet sollte sich grundsätzlich `Strg+Alt+D` vor dem Aufteilen von Linien oder dem Verschieben/Löschen von Punkten angewöhnen.

JOSM hatte da auch seine Problem und hat sie bei mehrfach befahrenen Abschnitten immer noch, allerdings hat sich auch einiges gebessert und bei komplett geladener Relation gibt es einen Validator-Test.

axelr wrote:

Weide wrote:
....Ja. Ich meinte, dass iD das m.W. immer richtig macht und ...
In den letzte drei Monaten habe ich den Eindruck, dass iD beim Auftrennen von Wegen die Reihenfolge in Routen testet, dann aber falsch herum zusammensetzt.

Ja, irgendetwas ist faul und den Eindruck mit genau der falschen Position bei einfachen Beispielen habe ich auch.

ghostrider44 · 2021-03-15 11:37:29

Wenn man das Fenster zum Ändern der Busrelation in JOSM offen hat, sollte man es auf jeden Fall vorher mit OK schließen, bevor man an einem Weg oder einer Haltestelle Änderungen vornimmt, sonst kommt es evtl. zu Fehlern.

GerdP · 2021-03-15 12:44:44

Ich habe bis heute nicht verstanden, wozu die Reihenfolge gebraucht wird. Welche Anwendung braucht das?

ToniE · 2021-03-15 12:55:56

GerdP wrote:

Welche Anwendung braucht das?

https://waymarkedtrails.org kann daraus Höhenprofile für die Rad-/Wander-/MTB-/...Routen erstellen.

Automatisches Sortieren in der Anwendung ist nur bedingt tauglich, da es nicht immer korrekte Ergebnisse liefert.

ToniE · 2021-03-15 13:04:35

ToniE wrote:

Welche Anwendung braucht das?

Trufi erstellt gerade im Auftrag der Weltbank, zusammen mit lokalen Mappern eine App für den ÖPNV in Nouakchott, Hauptstadt Mauretaniens. Dort gab es bis vor einer Woche nicht eine einzige PT-Relation. Die Daten werden in OSM gemapped, in der Trufi-App genutzt und auch nach GTFS exportiert.

Ähnliches gilt für Cochabamba, CO, Duitama, BO, Managua, NI, ...

Last edited by ToniE (2021-03-15 13:13:58)

Announcement

#1 2021-03-09 11:33:34

Neuer Mapper bearbeitet Busrelationen

#2 2021-03-09 11:46:59

Re: Neuer Mapper bearbeitet Busrelationen

#3 2021-03-09 12:46:47

Re: Neuer Mapper bearbeitet Busrelationen

#4 2021-03-09 20:53:49

Re: Neuer Mapper bearbeitet Busrelationen

#5 2021-03-09 21:18:29

Re: Neuer Mapper bearbeitet Busrelationen

#6 2021-03-09 22:54:12

Re: Neuer Mapper bearbeitet Busrelationen

#7 2021-03-10 20:12:54

Re: Neuer Mapper bearbeitet Busrelationen

#8 2021-03-10 20:19:42

Re: Neuer Mapper bearbeitet Busrelationen

#9 2021-03-10 20:44:36

Re: Neuer Mapper bearbeitet Busrelationen

#10 2021-03-10 21:28:50

Re: Neuer Mapper bearbeitet Busrelationen

#11 2021-03-10 21:41:46

Re: Neuer Mapper bearbeitet Busrelationen

#12 2021-03-10 21:43:06

Re: Neuer Mapper bearbeitet Busrelationen

#13 2021-03-10 21:49:56

Re: Neuer Mapper bearbeitet Busrelationen

#14 2021-03-11 11:02:18

Re: Neuer Mapper bearbeitet Busrelationen

#15 2021-03-11 11:58:07

Re: Neuer Mapper bearbeitet Busrelationen

#16 2021-03-12 08:44:00

Re: Neuer Mapper bearbeitet Busrelationen

#17 2021-03-12 09:56:33

Re: Neuer Mapper bearbeitet Busrelationen

#18 2021-03-13 07:05:13

Re: Neuer Mapper bearbeitet Busrelationen

#19 2021-03-13 08:23:58

Re: Neuer Mapper bearbeitet Busrelationen

#20 2021-03-14 15:41:53

Re: Neuer Mapper bearbeitet Busrelationen

#21 2021-03-14 16:13:26

Re: Neuer Mapper bearbeitet Busrelationen

#22 2021-03-15 11:37:29

Re: Neuer Mapper bearbeitet Busrelationen

#23 2021-03-15 12:44:44

Re: Neuer Mapper bearbeitet Busrelationen

#24 2021-03-15 12:55:56

Re: Neuer Mapper bearbeitet Busrelationen

#25 2021-03-15 13:04:35

Re: Neuer Mapper bearbeitet Busrelationen

Board footer