Neuer Mapper bearbeitet Busrelationen

skyper · 2021-03-17 13:22:48

Oh, sorry, ich habe mich da nicht deutlich genug ausgedrückt. Bin immer von einer manuell angestoßenen Autosortierung wie im Relations-Editor von JOSM ausgegangen. Eine Autosortierung ohne User-Interaktion, wie iD sie anscheinend macht, bringt bei Routen wohl eher Ärger.

Weide wrote:

Ich denke, dass das Beispiel zeigt, dass die Autosortierung bei PTv2 nie gemacht werden sollte. Einen klareren Fall kann eine Autosortierung kaum bekommen und trotzdem war die Reihenfolge vor der Autosortierung richtig und ist danach falsch.

Da läuft dann aber einiges schief und der Fehler ist schon davor. Wieso brauche ich überhaupt eine Umordnung wenn vorher alles schon richtig war?

skyper · 2021-03-17 14:03:27

GerdP wrote:

Ich bin mal ganz ketzerisch: Sind Busrelationen nicht reine Spielerei? Mir kommt das ein bischen vor wie bei der Modeleisenbahn. Man braucht sie nicht, aber man kann sich über die Lösung von Problemen freuen, die man sonst nicht hätte.

Hilfe Mama, der will mir mein Spielzeug wegnehmen.

GerdP wrote:

Im Ernst: Ich kann mir keine Anwendung vorstellen, die über das Rendern hinausgeht, ohne andere Datenquellen wie Fahrpläne, Tarife etc. einzubinden. Wenn das aber eh nötig wäre, dann sehe ich keinen Bedarf, sich um Reihenfolgen in den OSM Daten zu scheren.

Dachte Du hast Deinen Ärger mit PTv1. Wie soll ich denn folgende Linien auf Fehler überprüfen oder auch nur den Hauch einer Ahnung haben wo der Bus lang fährt?

* https://osm.org/relation/69270
* https://osm.org/relation/3385101

GerdP wrote:

Und das soll bitte keine Aufforderung sein, jetzt auch noch Fahrpläne und Tarife in eine PTv4.0 rein zu quetschen.

Das geht schon ganz gut mit PTv2. Braucht eigentlich nur ein Feintuning von `interval` und `duration` für Wiederholungen bzw. einen optimierten Ersatz für `:conditional`.

miche101 wrote:

...ja da muss man aber auch sagen das oft das Hauptziel dieser Aktionen ist mit Hilfe von OSM-Daten ein GTFS Datei zu erstellen... welche dann bei Google dann hochgeladen wird um ÖPNV-Routing auf Google Maps zu bekommen, weil der Lokale ÖPNV das nicht selbst macht.

Super, dann steht da ja überall OSM als Quelle mit Link. Sollte dies Angabe nicht auch in die GTFS-Zip-Datei, wenn die Shapes aus OSM kommen?

Die GTFS in meiner Gegend legen zwar OSM nahe, bei den Haltestellen habe ich aber meine Zweifel und die Shapes decken sich nicht mit den PTv1-Relationen. Um eine Aussage zu PTv2 machen zu können müssen die Shapes erst mal aktualisiert werden, was dauern kann.

miche101 wrote:

Um dieses Ziel zu erreichen,... braucht es nicht umbedingt PTv2(machmal nur die platformen, highway=bus_stop).. bzw. nur eine Teilmenge, weil auf das Shape kann verzichtet werden.. bzw. lässt sich über routing erstellen

Für anständiges Routing von Bussen braucht es viel Aufwand und häufig sind die Daten unvollständig oder nicht ausreichend.

miche101 · 2021-03-17 15:22:58

skyper wrote:

, wenn die Shapes aus OSM kommen?

ja müsste dann so sein..

skyper wrote:

anständiges Routing

braucht man nicht... das Ergebnis zählt, kann man tricksen wie man will Hauptsache man hat für jeden trip einen Shape

GerdP · 2021-03-17 15:52:43

skyper wrote:

Dachte Du hast Deinen Ärger mit PTv1. Wie soll ich denn folgende Linien auf Fehler überprüfen oder auch nur den Hauch einer Ahnung haben wo der Bus lang fährt?

Ich habe schon wieder vergessen, was der Unterschied zwischen PTv1 und PTv2 ist, aber v2 war - glaube ich - weniger schlecht geeignet für das Relationsmodel. Wo der Bus lang fährt sieht man doch, wenn man Deinen Links folgt. Vorausgesetzt, die Relationen sind korrekt.
Wie man das überrpüft? Falls GPX im Bus funktioniert, wäre es einfach, sonst müsste man wohl dem Bus hinterherfahren und anschließend fragen, ob der Fahrer immer diese Strecke fährt?

ToniE · 2021-03-17 16:02:54

GerdP wrote:

Wo der Bus lang fährt sieht man doch, wenn man Deinen Links folgt

"Sieht" ist hier das richtige bzw. falsche Wort ... das ist Kartenbezogen.
Mit "sehen" hat ein Programm, welches die genaue und richtige Strecke von A nach B wissen will, nicht viel zu tun.

- PTv1 hat nur eine Relation für eine Buslinie und diese nimmt alle Wege, Varianten, ... auf - daraus kann ein Programm nicht schließen, welche Wege ein Bus konkret von A nach B nehmen wird - nur welche Wege im Laufe eines Jahres von dem Bus mal befahren werden.

- PTv2 definiert für jede Variante/Richtung eine eigene Relation, bei der die Reihenfolge der Haltestellen aber auch die Reihenfolge der befahrenen Wege korrekt sein muss (meinetwegen weil du mit eingeschaltetem GPS-Gerät mitgefahren bist)
- was bei PTv2 auch nicht drin ist: an welchen Tagen zu welchen Uhrzeiten wird eine bestimmte Relation befahren
- das lässt sich aber durch interval, duration, ... auf PTv2 aufsatteln - in gewissen Grenzen (gell, skyper)

Mammi71 · 2021-03-17 17:37:04

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.

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.

miche101 · 2021-03-17 20:19:04

Mammi71 wrote:

irgendwo was versehentlich kaputt zu machen,

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

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

Gruß Miche

Weide · 2021-03-17 20:32:06

GerdP wrote:

Ich habe schon wieder vergessen, was der Unterschied zwischen PTv1 und PTv2 ist...

PTv1 ist praktisch gesehen die Buslinie wie man sie auf die Karte malen könnte. Wo der Bus nur in einer Himmelsrichtung durchfährt malt man mit Pfeilen (Rolle "forward" oder "backward" und wo der Bus vom Straßenrand aus gesehen mal von links und mal von rechts kommt nimmt man Linien ohne Pfeile ("leere Rolle"). Die Haltestellen sind ausnahmslos Nodes (Rolle egal). Die Reihenfolge der Angaben bedeutet nichts (aber man kann es übersichtlicher oder weniger übersichtlich machen). Es kommt nichts doppelt vor.

Bei einer Buslinie, die z.B. mal über A-Dorf und mal dran vorbei fährt und später dasselbe mit B-Dorf macht kann man aber dann nicht sehen, dass das immer abwechselnd passiert, das man also nicht ohne Umsteigen von A-Dorf nach B-Dorf kommt. Auch kann man keine Linien oder Flächen für die Haltestellen eintragen und das ist besonders bei Bahnlinien sehr ungünstig, da niemand auf das Mappen von Bahnsteigen verzichten will.

Deshalb wurde PTv2 erfunden. Da bekommt jede Variante jeder Richtung eine eigene Relation und man kann die möglichen Verbindungen genau sehen. Da es nur eine Variante ist, sollte bei vollständiger Erfassung immer der eine Weg aufhören wo der nächste anfängt und auch die Haltestellen gibt man in der Reihenfolge der Realität an. Da kann man dann z.B. auch sehen, dass die nach XXX Hbf durchfahrende Variante der Zuglinie in YYY an einem anderen Bahnsteig hält, der per Rollstuhl nur schlecht zugänglich ist.

mmd · 2021-03-17 22:00:41

PTv2 ist wahrscheinlich so fragil, weil es zu sehr im Grenzbereich des aktuellen Datenmodells liegt. Es gibt für API 0.7 Vorschläge, den Relationsmitgliedern selbst nochmal eigene Tags zu verpassen. 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.

Die Sortiergeschichte der Relationsmember wäre auch unnötig, 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". Wenn in einer Minute zwei Stops angefahren werden, reichen Minuten natürlich nicht mehr aus, aber ich denke, das Prinzip sollte klar sein. Fahrplan mit Abfahrtzeiten als Grundlage sollte hoffentlich ausreichen für so etwas.

https://wiki.openstreetmap.org/wiki/API … not_enough

ToniE · 2021-03-17 22:25:43

mmd wrote:

PTv2 ist wahrscheinlich so fragil, weil es zu sehr im Grenzbereich des aktuellen Datenmodells liegt. Es gibt für API 0.7 Vorschläge, den Relationsmitgliedern selbst nochmal eigene Tags zu verpassen. 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.
Die Sortiergeschichte der Relationsmember wäre auch unnötig, 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". Wenn in einer Minute zwei Stops angefahren werden, reichen Minuten natürlich nicht mehr aus, aber ich denke, das Prinzip sollte klar sein. Fahrplan mit Abfahrtzeiten als Grundlage sollte hoffentlich ausreichen für so etwas.
https://wiki.openstreetmap.org/wiki/API … not_enough

Verstehe ich nicht ganz. Wäre das eine dritte Ebene zwischen 'role' und den 'tags' der Haltestelle.

Haltestellen sind u.U. Member von vielen Relationen, d.h. "nur Einstieg" ist nicht die Eigenschaft einer Haltestelle an sich, sondern Eigenschaft dieser Haltestelle in einer bestimmten Buslinie (Relation). Selbiges gilt für die Fahrzeiten zwischen zwei Stationen dieser Buslinie. Das entspricht übrigens den trips und stop_times im GTFS-Modell (trip-spezifisch: Abfahrzeit an jeder Haltestelle statt Zeit bis zur nächsten).

Prinzipiell bin ich dafür, aber wo genau wird der Zeitstempel hinterlegt? Sicherlich nicht als zusätziches 'tag' am Node der Haltestelle - no way.

Last edited by ToniE (2021-03-17 22:28:24)

Weide · 2021-03-17 22:31:05

mmd wrote:

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.

Weide · 2021-03-17 22:32:58

mmd wrote:

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.

mmd · 2021-03-17 22:41:39

ToniE wrote:

Haltestellen sind u.U. Member von vielen Relationen, d.h. "nur Einstieg" ist nicht die Eigenschaft einer Haltestelle an sich, sondern Eigenschaft dieser Haltestelle in einer bestimmten Buslinie (Relation).

Ja genau, die zusätzlichen Tags hängen am Relationsmember und nicht an der Haltestelle. Heute gibt es das Konstrukt so überhaupt nicht mit der API 0.6, bitte daher genau die verlinkte Wikiseite durchgelesen.

ToniE wrote:

Prinzipiell bin ich dafür, aber wo genau wird der Zeitstempel hinterlegt? Sicherlich nicht als zusätziches 'tag' am Node der Haltestelle - no way.

Siehe vorgehenden Kommentar. Der Node ist als member in einer relation enthalten und dieser Member hätte zusätzliche tags, nicht aber der ursprüngliche Node. Hoffe das ist so etwas klarer.

Last edited by mmd (2021-03-17 22:46:22)

mmd · 2021-03-17 22:42:54

Weide wrote:

mmd wrote:
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.

Das war nur ein Beispiel, es geht mir um das Prinzip von der Sortierung der member wegzukommen. Es ist klar, dass es in der Realität nochmal Abweichungen gibt, das macht es aber schwierig erstmal den 90% Fall zu erklären.

Last edited by mmd (2021-03-17 22:56:27)

GerdP · 2021-03-17 22:56:01

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.

mmd · 2021-03-17 23:02:33

Zusätzliche Tags an Relationsmitgliedern ist ein Vorschlag, den jemand für API 0.7 gemacht hat. Weil jeder immer nur betroffen feststellt, dass wir seit 10 Jahren mit API 0.6 arbeiten, wird es Zeit auch mal neue Sachen anzudenken. PTv2 hat m.E. schon das Potenzial, dieses Konzept etwas weiter auszuloten.

Passt übrigens auch gut zum diesjährigen State of the Map track zur Evolution des Datenmodells:

Data Analysis and Data Model

This track is dedicated to OSM data itself: analysis of OSM data quality; reflections about enhancing the data model

Aus: https://2021.stateofthemap.org/calls/general/

Last edited by mmd (2021-03-17 23:28:00)

Weide · 2021-03-18 06:48:18

mmd wrote:

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.

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.

Last edited by Weide (2021-03-18 06:51:19)

miche101 · 2021-03-18 07:55:49

Weide wrote:

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

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. Die Via Punkte könnte man in der Relation unterbringen mit einer Rolle "via". Für Leute die kein Routing nicht machen wollen kann man noch Statisch ein GPX-Datei hinterlegen... z.B. mit einem Key/Value gpx=https://www.osm.org/static_gpx/[Linienref]_[OSM-ID].gpx . Ganz nebenbei

Gruß Miche

Weide · 2021-03-18 09:27:48

miche101 wrote:

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=77 … =transport alle paar Minuten an der Linie 5 sehen kann (rasender gelber Punkt).

ToniE · 2021-03-18 09:41:31

mmd wrote:

Weide wrote:
mmd wrote:
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.
Das war nur ein Beispiel, es geht mir um das Prinzip von der Sortierung der member wegzukommen. Es ist klar, dass es in der Realität nochmal Abweichungen gibt, das macht es aber schwierig erstmal den 90% Fall zu erklären.

OK, verstanden.

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?

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

A relation for a public transport route might arange the stop-position and platforms into sections from start to a central interchange node to another important interchange node to the to the end of the route. Each section is headed by a comment describing the following section.

"sections" einzuführen halt ich für "Erhöhung der Komplexität"

miche101 · 2021-03-18 09:45:58

Weide wrote:

irgendwo eine Brücke gesperrt wird,

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

Via-Punkte sollen das Routing unterstützen, weil ein Bus nicht immer die für den Router optimale route wählt. Oder Busse teilweise wenden und das kann ein Router unmöglich wissen wo und wie das geschieht.

Weide wrote:

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

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.

ToniE · 2021-03-18 10:00:50

ToniE wrote:

- 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?

Ich als JOSM-Nutzer und Editierer von PTv2-Routen würde dann aber folgendes wünschen ...

- im Relationseditor die Wege manuell (automatisch?) sortieren oder erstmalig in der richtigen Reihenfolge einfügen
- die sequence-Nummer vom JOSM eintragen/überschreiben lassen

denn die rechte Spalte im Relationseditor mit den Indikatioren für "Lückenfreiheit" ... ist für mich mit "Open-Eyes-2.0" das Hilfsmittel um sowas beurteilen zu können.

mmd · 2021-03-18 10:15:38

ToniE wrote:

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-18 12:47:09

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-18 13:06:36

miche101 wrote:

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 wrote:

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.

Announcement

#51 2021-03-17 13:22:48

Re: Neuer Mapper bearbeitet Busrelationen

#52 2021-03-17 14:03:27

Re: Neuer Mapper bearbeitet Busrelationen

#53 2021-03-17 15:22:58

Re: Neuer Mapper bearbeitet Busrelationen

#54 2021-03-17 15:52:43

Re: Neuer Mapper bearbeitet Busrelationen

#55 2021-03-17 16:02:54

Re: Neuer Mapper bearbeitet Busrelationen

#56 2021-03-17 17:37:04

Re: Neuer Mapper bearbeitet Busrelationen

#57 2021-03-17 20:19:04

Re: Neuer Mapper bearbeitet Busrelationen

#58 2021-03-17 20:32:06

Re: Neuer Mapper bearbeitet Busrelationen

#59 2021-03-17 22:00:41

Re: Neuer Mapper bearbeitet Busrelationen

#60 2021-03-17 22:25:43

Re: Neuer Mapper bearbeitet Busrelationen

#61 2021-03-17 22:31:05

Re: Neuer Mapper bearbeitet Busrelationen

#62 2021-03-17 22:32:58

Re: Neuer Mapper bearbeitet Busrelationen

#63 2021-03-17 22:41:39

Re: Neuer Mapper bearbeitet Busrelationen

#64 2021-03-17 22:42:54

Re: Neuer Mapper bearbeitet Busrelationen

#65 2021-03-17 22:56:01

Re: Neuer Mapper bearbeitet Busrelationen

#66 2021-03-17 23:02:33

Re: Neuer Mapper bearbeitet Busrelationen

#67 2021-03-18 06:48:18

Re: Neuer Mapper bearbeitet Busrelationen

#68 2021-03-18 07:55:49

Re: Neuer Mapper bearbeitet Busrelationen

#69 2021-03-18 09:27:48

Re: Neuer Mapper bearbeitet Busrelationen

#70 2021-03-18 09:41:31

Re: Neuer Mapper bearbeitet Busrelationen

#71 2021-03-18 09:45:58

Re: Neuer Mapper bearbeitet Busrelationen

#72 2021-03-18 10:00:50

Re: Neuer Mapper bearbeitet Busrelationen

#73 2021-03-18 10:15:38

Re: Neuer Mapper bearbeitet Busrelationen

#74 2021-03-18 12:47:09

Re: Neuer Mapper bearbeitet Busrelationen

#75 2021-03-18 13:06:36

Re: Neuer Mapper bearbeitet Busrelationen

Board footer