Herausfinden, wer Relation zerstört hat

Lokai · 2018-08-21T06:46:41.000Z

Mit JOSM kannst du so was erreichen. Eine ähnliche Frage stellte ich vor einiger Zeit. Such hier im Forum danach mit meinem Benutzernamen

streckenkundler · 2018-08-21T07:07:48.000Z

Guten Morgen,

Druzhba:

Gibt es irgendeine automatische Lösung, um den Nutzer festzustellen, der eine Relation kaputtgemacht hat (Beispiel Hokuriku-Shinkansen)?

Und hat mal jemand darüber nachgedacht, alle (Strom,Strecken-)Netz-Relationen permanent auf Lochfreiheit zu überprüfen? Gibt es irgendwo schon eine Liste für die Qualitätssicherung?

Viele Grüße

kennst du
http://osm.mapki.com/history/

Hier das für diese Relation…

http://osm.mapki.com/history/relation.php?id=1926393

Sven

ToniE · 2018-08-21T07:32:03.000Z

Druzhba:

regelmäßig werden in von mir “betreute” Eisenbahn- oder Stromrelationen Löcher hineingerissen. Manchmal war es aber gar nicht der letzte Änderer, sondern jemand davor.

Ich habe festgestellt, dass viele Lücken in JOSM/iD/… entstehen, wenn man einen Weg in zwei Teile aufteilt.
Eine manuelle bzw. automatische Neusortierung betroffener Relationen erfolgt dabei nur selten.
Manchmal stimmt die Reihenfolge danach allerdings trotzdem (per Zufall).

Druzhba:

Und hat mal jemand darüber nachgedacht, alle (Strom,Strecken-)Netz-Relationen permanent auf Lochfreiheit zu überprüfen? Gibt es irgendwo schon eine Liste für die Qualitätssicherung?

Wir haben uns im Februar letzten Jahres beim Stammtisch in München auch darüber unterhalten und wie man generell public transport Relationen besser dokumentieren kann [1] [2].
Heraus gekommen ist mittlerweile ein von mir geschriebenes Tool, welches derzeit täglich 29 Verkehrsverbünde/‘network’ analysiert [3].
Weitere Analysen zu erstellen ist recht einfach.
Der Fokus liegt bzgl. ‘Lücken’ allerdings auf PTv2, für die ist genau beschrieben, wie die Wege in die Relation zu integrieren sind. Dein Beispiel ist allerdings PTv1.

Gruß
Toni

[1] https://wiki.openstreetmap.org/wiki/Talk:M%C3%BCnchen/Transportation#Qualit.C3.A4tssicherung_-_M.C3.BCnchen.2FTransportation
[2] https://wiki.openstreetmap.org/wiki/User:ToniE/analyze-routes
[3] https://wiki.openstreetmap.org/wiki/User:ToniE/analyze-routes#Analysierte_Verbunde

Edit: typos

kreuzschnabel · 2018-08-21T08:06:50.000Z

ToniE:

Ich habe festgestellt, dass viele Lücken in JOSM/iD/… entstehen, wenn man einen Weg in zwei Teile aufteilt.
Eine manuelle bzw. automatische Neusortierung betroffener Relationen erfolgt dabei nur selten.

Hast du da was Reproduzierbares? Jeder OSM-Editor sorgt beim Aufteilen eines Weges, der Teil einer oder mehrerer Relationen ist, automatisch dafür, dass die beiden Teile hinterher in kompatibler Reihenfolge in der Relation sind.

In JOSM geschieht das nur dann nicht automatisch, wenn eine betroffene Relation schon im Relationseditor offen ist – dann muss man die Relation manuell neu aus dem Haupteditor einlesen. Tut man das nicht, bekommt man aber hinterher einen Konflikt gemeldet, so dass auch hier keine kaputten Daten auf dem Server landen.

–ks

ToniE · 2018-08-21T08:26:12.000Z

Konkret habe ich da keinen Beweis für meine Aussage.

Was mir immer wieder auffällt sind Meldungen meines Tools: “PTv2 route: has gap(s), consists of 3 segments”.
Hier gibt es zumeist zwei Lücken …W1 L W2 W3 L W4…, die häufig dadurch geschlossen werden können, indem man die Reihenfolge zweier Wege vertauscht (hier W2 und W3 → …W1 W3 W2 W4…).
Eine Analyse von W2 und W3 ergab dann meistens einen vorausgegangenen Split von W2 nach W2+W3 oder W3 nach W2+W3.
Was auch noch auffiel ist, das ein Bus in die Gegenrichtung davon häufig nicht betroffen ist.

Ja, offener Relations-Editor (JOSM) und split von enthaltenen Way ist eine Fehlerquelle, die wird aber - wie Du ja erwähnst - als Konflikt beim Schließen des Relations-Editors gemeldet.

Toni

Edit: typos

Garmin-User · 2018-08-21T08:39:26.000Z

kreuzschnabel:

In JOSM geschieht das nur dann nicht automatisch, wenn eine betroffene Relation schon im Relationseditor offen ist – dann muss man die Relation manuell neu aus dem Haupteditor einlesen. Tut man das nicht, bekommt man aber hinterher einen Konflikt gemeldet, so dass auch hier keine kaputten Daten auf dem Server landen.

Stimmt leider nicht ganz. JOSM bemerkt Konflikte beim Hochladen, wenn Nodes gelöscht wurden, die zu ungeladenen Wegen gehören. Bei Wegen, ob sie denn zu Relationen gehören, geschieht diese zusätzliche Kommunikation offenbar nicht - das klappt aber beim Download einzelner Elemente. Deswegen habe ich mir angewöhnt, bei jedem Weg den ich löschen oder trennen will, diesen extra nochmal zu holen (markieren, Str+C, Objekt herunterladen - da steht ID und Elementtyp schon drin). Mit den Nodes klappt das übrigens genauso, da holt er dann die anhängenden Wege nach.

Gruß
Mario

Weide · 2018-08-21T08:42:30.000Z

kreuzschnabel:

Hast du da was Reproduzierbares? Jeder OSM-Editor sorgt beim Aufteilen eines Weges, der Teil einer oder mehrerer Relationen ist, automatisch dafür, dass die beiden Teile hinterher in kompatibler Reihenfolge in der Relation sind.

Ja. Lade im leeren JOSM einen Node mitten aus einem (Bus-)Weg. JOSM läd dann auch den Weg. Trennt man an diesem Node auf, dann werden die beiden Teile in derselben Reihenfolge in alle betroffenen Relationen gesteckt.

Der JOSM macht es nur dann richtig, wenn mindestens ein an den getrennten Weg angrenzender Weg der Relation geladen war … ansonsten ist es i.A. falsch.

Auf der sicheren Seite ist man bei Auftrennen von Wegen mit dem JOSM, wenn man vor dem Trennen sowohl den Weg als auch seine beiden Endpunkte selektiert und Alt-Ctrl-D macht. Dann sind ganz sicher alle betroffenen Relationen und alle angrenzenden Wege geladen und der JOSM arbeitet richtig.

ToniE · 2018-08-21T08:47:31.000Z

Hi kreuzschnabel,

vielleicht geschieht das aber auch nur, wenn man lediglich eine Relation in den JOSM läd und dann einen Split macht. Betroffene andere Relationen sind nicht sichtbar und “leiden” dann entsprechend. Aber dann fehlt in diesen Relationen eigentlich der neue Way. hmm?

Ein Beispiel, dessen Historie man mal analysieren könnte (hab’s noch nicht im Detail gemacht)

https://www.openstreetmap.org/relation/3767310

Dieser alte Way (Scheideweg) wurde anscheinend in 3 Teile gesplittet

alt: https://www.openstreetmap.org/way/72492484
neu1: https://www.openstreetmap.org/way/579179513
neu2: https://www.openstreetmap.org/way/579179515

Durch Vertauschen der Reihenfolge in der Relation (neu2, neu1, alt) kann die Relation wieder lückenlos gemacht werden.

Toni

SimonPoole · 2018-08-21T10:14:38.000Z

Natürlich ist die Forderung, dass die (Weg-)Routensegmente geordnet sein müssen, sind wir mal nett, eine Fehleinschätzung von wer auch immer das damals reingeschrieben hat. So oder so, ist es definitiv keine “Lücke” wenn die Wege ungeordnet sind.

Weide · 2018-08-21T10:55:30.000Z

SimonPoole:

Natürlich ist die Forderung, dass die (Weg-)Routensegmente geordnet sein müssen, sind wir mal nett, eine Fehleinschätzung von wer auch immer das damals reingeschrieben hat.

Nein. Absolut nicht.

Die Idee “man kann sich doch denken, wie es richtig ist” ist im allgemeinen Fall falsch. Selbst wenn es bei der betreffenden Variante nur eine einzige Möglichkeit der Sortierung gibt (und die entgegengesetzte), kann ein umgekehrt laufendes Stück richtig sein und es fehlen einfach zwei Stücke.

Die Reihenfolge enthält in PTv2-Relationen nicht automatisch rekonstruierbare Informationen. Der Mapper muss die Reihenfolge gemäß der Realität reinschreiben. Jede automatische Sortierung ohne Prüfung durch den editierenden Mapper ist Mist.

So oder so, ist es definitiv keine “Lücke” wenn die Wege ungeordnet sind.

Es ist eine Lücke, denn die angegebene Anordnung könnte richtig sein und es könnte daher falsch sein, einfach eine andere Reihenfolge zu vermuten. Jede Reihenfolge innerhalb des Wegeteils und jede Reihenfolge innerhalb des Haltestellenteils einer PTv2 hat eine eigene Bedeutung.

SimonPoole · 2018-08-21T12:52:18.000Z

Weide:

SimonPoole:

Natürlich ist die Forderung, dass die (Weg-)Routensegmente geordnet sein müssen, sind wir mal nett, eine Fehleinschätzung von wer auch immer das damals reingeschrieben hat.

Nein. Absolut nicht.

Die Idee “man kann sich doch denken, wie es richtig ist” ist im allgemeinen Fall falsch. Selbst wenn es bei der betreffenden Variante nur eine einzige Möglichkeit der Sortierung gibt (und die entgegengesetzte), kann ein umgekehrt laufendes Stück richtig sein und es fehlen einfach zwei Stücke.

Die Frage ist ob in solchen Fällen (an der Schleife dürfte dann nur eine Haltestelle sein, denn mit 2 ist die Fahrrichtung schon definiert), die Reihenfolge der Wege irgendwelche effektiv wirklich nützliche Informationen beinhaltet (ausser “fährt da durch”).

Die Reihenfolge enthält in PTv2-Relationen nicht automatisch rekonstruierbare Informationen. Der Mapper muss die Reihenfolge gemäß der Realität reinschreiben. Jede automatische Sortierung ohne Prüfung durch den editierenden Mapper ist Mist.

So oder so, ist es definitiv keine “Lücke” wenn die Wege ungeordnet sind.

Es ist eine Lücke, denn die angegebene Anordnung könnte richtig sein und es könnte daher falsch sein, einfach eine andere Reihenfolge zu vermuten. Jede Reihenfolge innerhalb des Wegeteils und jede Reihenfolge innerhalb des Haltestellenteils einer PTv2 hat eine eigene Bedeutung.

Du zeigst nur wieder auf, dass ein vernünftiges PT Schema keine Wegsegmente beinhalten sollte, sondern nur Haltestellen.

ToniE · 2018-08-21T14:23:11.000Z

SimonPoole:

Weide:

SimonPoole:

Natürlich ist die Forderung, dass die (Weg-)Routensegmente geordnet sein müssen, sind wir mal nett, eine Fehleinschätzung von wer auch immer das damals reingeschrieben hat.

Nein. Absolut nicht.

Die Idee “man kann sich doch denken, wie es richtig ist” ist im allgemeinen Fall falsch. Selbst wenn es bei der betreffenden Variante nur eine einzige Möglichkeit der Sortierung gibt (und die entgegengesetzte), kann ein umgekehrt laufendes Stück richtig sein und es fehlen einfach zwei Stücke.

Die Frage ist ob in solchen Fällen (an der Schleife dürfte dann nur eine Haltestelle sein, denn mit 2 ist die Fahrrichtung schon definiert), die Reihenfolge der Wege irgendwelche effektiv wirklich nützliche Informationen beinhaltet (ausser “fährt da durch”).

Hmm, mal naiv gefragt: welche “Abnehmer” der Daten in der DB haben wir denn derzeit bzgl. ÖPNV: Transport-Map, öpnvmap, …
Die sind derzeit wohl nur daran interessiert welche Wege und Haltestellen denn zur Relation gehören. Die Sortierung ist wohl egal, nur sollte die Wegstrecke keine Lücke aufweisen.
Der Betrachter - zumindest mache ich das so - ist wohl daran interessiert zu erfahren, welcher Bus welche Strecke fährt und welche Haltestellen auf dem Weg liegen.

Welche anderen “Abnehmer”/Anwendungen gibt es bei OSM denn sonst noch bzgl. PT?

SimonPoole:

Weide:

Die Reihenfolge enthält in PTv2-Relationen nicht automatisch rekonstruierbare Informationen. Der Mapper muss die Reihenfolge gemäß der Realität reinschreiben. Jede automatische Sortierung ohne Prüfung durch den editierenden Mapper ist Mist.

SimonPoole:

So oder so, ist es definitiv keine “Lücke” wenn die Wege ungeordnet sind.

Es ist eine Lücke, denn die angegebene Anordnung könnte richtig sein und es könnte daher falsch sein, einfach eine andere Reihenfolge zu vermuten. Jede Reihenfolge innerhalb des Wegeteils und jede Reihenfolge innerhalb des Haltestellenteils einer PTv2 hat eine eigene Bedeutung.

Du zeigst nur wieder auf, dass ein vernünftiges PT Schema keine Wegsegmente beinhalten sollte, sondern nur Haltestellen.

Wenn ich mal darüber nachdenke, dass man ja auch Navigation mittels z.B. Bus machen könnte …
Dann bräuchte ich den exakten Wegeverlauf inkl. zu erwartendem Aufenthalt per Haltestelle um die Fahrzeit einigermaßen abschätzen zu können - mal abgesehen von der Verfügbarkeit der Abfahrzeiten …
So pauschal würde ich daher dem “ein vernünftiges PT Schema keine Wegsegmente beinhalten sollte” nicht zustimmen. Denn selbst bei korrekter Reihenfolge der Haltestellen in der Relation ist (gerade auf dem Lande, wo viele Schleifen gefahren werden) die Strecke nicht immer eindeutig.

Weide · 2018-08-21T17:40:21.000Z

SimonPoole:

Die Frage ist ob in solchen Fällen (an der Schleife dürfte dann nur eine Haltestelle sein, denn mit 2 ist die Fahrrichtung schon definiert), die Reihenfolge der Wege irgendwelche effektiv wirklich nützliche Informationen beinhaltet (ausser “fährt da durch”).

Wenn die Reihenfolge der Wege nicht zur Reihenfolge der Haltestellen passt, dann muss die Haltestellenreihenfolge richtig sein und die Wege Wege wurden irrtümlich verdreht? Wieso nicht umgekehrt?

SimonPoole:

Du zeigst nur wieder auf, dass ein vernünftiges PT Schema keine Wegsegmente beinhalten sollte, sondern nur Haltestellen.

Das ist ein schönes Konzept wenn man garantiert nur komplette Routen hat. Soll denn “vernünftiges PT-Schema” bedeuten, dass man nur noch Fahrpläne abschreibt und nicht mehr mehr mit GPS-Gerät und Fotoapparat Busrouten erfasst?

Außerdem ging es ja um die Frage, wie man in PTv2 die Reihenfolge interpretiert und nicht, wie man ein PTv3 macht.

Druzhba · 2018-08-21T23:54:07.000Z

@ToniE:

Kann dein Tool auch eine “simple” Topologieprüfung auf Löcher machen? Wie würde der Code dafür ausehen?

Der Relation Analyzer funktioniert bei meiner Beispielrelation nicht.

ToniE · 2018-08-22T07:05:39.000Z

Druzhba:

Kann dein Tool auch eine “simple” Topologieprüfung auf Löcher machen? Wie würde der Code dafür ausehen?

Yep, das kann er. Derzeit wird die Prüfung nur gemacht, wenn die Relation PTv2 ist - denn hierbei wird es keine “false positivies” geben.
Bei PTv1 weiß man nie so genau … OK, bei Zügen, Seilbahnen, Fähren und ähnlichem eventuell …

Der Code ist auf github.

https://github.com/osm-ToniE/analyze-routes/blob/master/bin/analyze-routes.pl

Zeile 2739, etwa 500 Zeilen Code zum Sortieren der Nodes aller enthaltenen Ways in ein neues Array (für spätere andere Analysen).
Dabei fallen einige “Fehlermeldungen” an. Und yep: alle 500 Zeilen werden bei enstprechenden Inputdaten auch durchlaufen.

Update: Der Code nimmt die vorgegebenen Reihenfolge der Ways und versucht nicht die Ways so zu sortieren dass möglicherweise eine durchgängige Fahrstrecke entsteht.

SimonPoole · 2018-08-22T07:12:23.000Z

@Weide die Reihenfolge von Haltestellen ändert sich nicht durch Edits an solchen (im schlimmsten Fall fehlen welche durch Löschung, die Reihenfolge als solche bleibt aber erhalten).

Deine Forderungen laufen daraus hinaus, dass man Wege die Teile von PTv2 Routen sind nicht editieren darf, ausser man ist PTv2 Experte (natürlich passiert das in der Praxis nicht, deshalb ist das Wehklagen in diesem Thread völlig sinnfrei). Ich sage lieber man muss mit den Unschärfen in der Fahrtrichtung, die durch die automatische Rekonstruktion entstehen leben, oder ein Schema einsetzen, dass nicht so fragil ist (was an und für sich ja kein Problem wäre).

Weide · 2018-08-22T10:17:21.000Z

SimonPoole:

@Weide die Reihenfolge von Haltestellen ändert sich nicht durch Edits an solchen (im schlimmsten Fall fehlen welche durch Löschung, die Reihenfolge als solche bleibt aber erhalten).

Wir haben andauernd falsche Haltestellenreihenfolgen durch “anhängen” von Haltestellenobjekten. (Eine Lösung wäre es, die bei PTv2 völlig sinnfreie Funktion “hinzufügen zur Relation x” für PTv2-Relationen ersatzlos zu streichen).

Deine Forderungen laufen daraus hinaus, dass man Wege die Teile von PTv2 Routen sind nicht editieren darf, ausser man ist PTv2 Experte …

Es ist eine Kritik am Editor JOSM, denn es passiert praktisch nur im JOSM. Der ansonsten für PTv2 weitgehend ungeeignete iD macht dagegen praktisch keine Relationsfehler beim Auftrennen. Aber wir sind uns einig, dass PTv2 zu fragil ist (s.u.)

(natürlich passiert das in der Praxis nicht, deshalb ist das Wehklagen in diesem Thread völlig sinnfrei).

Das verstehe ich nicht. Es passiert doch andauernd.

Ich sage lieber man muss mit den Unschärfen in der Fahrtrichtung, die durch die automatische Rekonstruktion entstehen leben…

Wir leben ja auch damit. Aber zu sagen, dass die Reihenfolge da mehr oder weniger versehentlich reingeraten ist, geht total daneben. Es ist ein zentraler Bestandteil und ohne diesen ist PTv2 einfach Quatsch und sollte ganz gestrichen werden. Solange PTv2 existiert sollte man Gerüchten entgegentreten, dass die Reihenfolge da nicht so wichtig ist.

… oder ein Schema einsetzen, dass nicht so fragil ist

Da sind wir uns völlig einig. PTv2 hat eine Menge Schwächen, aber der Hauptpunkt ist seine Fragilität. Der Nachfolger von PTv2 muss unbedingt weniger fragil sein. Entsprechende Vorschläge habe ich ja auch gemacht.

SimonPoole · 2018-08-22T12:17:51.000Z

Weide:

SimonPoole:

(natürlich passiert das in der Praxis nicht, deshalb ist das Wehklagen in diesem Thread völlig sinnfrei).

Das verstehe ich nicht. Es passiert doch andauernd.

Die Meinung war, dass man nicht verhindern kann oder auch will, dass nur noch PTv2 Experten solche Wege bearbeiten.

.

Ich sage lieber man muss mit den Unschärfen in der Fahrtrichtung, die durch die automatische Rekonstruktion entstehen leben…

Wir leben ja auch damit. Aber zu sagen, dass die Reihenfolge da mehr oder weniger versehentlich reingeraten ist, geht total daneben. Es ist ein zentraler Bestandteil und ohne diesen ist PTv2 einfach Quatsch und sollte ganz gestrichen werden. Solange PTv2 existiert sollte man Gerüchten entgegentreten, dass die Reihenfolge da nicht so wichtig ist.

Man kann auch einfach festhalten, dass man PTv2 Routen schön malen kann, aber gewisse andere Auswertungen nicht zuverlässig funktionieren, weil man sich das nicht wirklich überlegt hat.

Simon

Weide · 2018-08-23T19:28:09.000Z

SimonPoole:

Man kann auch einfach festhalten, dass man PTv2 Routen schön malen kann, aber gewisse andere Auswertungen nicht zuverlässig funktionieren, weil man sich das nicht wirklich überlegt hat.

Routen malen geht mit PTv1 wunderbar, denn da sind genau die dafür nötigen Angaben drin. Ohne einen darüber hinausgehenden Informationsgehalt ist PTv2 nur eine sinnlose Verkomplizierung.

Druzhba · 2018-08-29T10:52:23.000Z

Weide:

Routen malen geht mit PTv1 wunderbar, denn da sind genau die dafür nötigen Angaben drin. Ohne einen darüber hinausgehenden Informationsgehalt ist PTv2 nur eine sinnlose Verkomplizierung.

Für mich das Zitat des Tages. +1