Am 04.04.2012 20:18, schrieb Stephan Wolff:
Moin!
Am 03.04.2012 16:23, schrieb Christian Müller:
Bei der Vielfalt der Linienfahrpläne "in the wild" lässt sich das
eigentlich auch nur lösen, wenn die kompletten Fahrpläne erfasst werden
bus_stop: collection_times pro Linie pro Richtung
Beispiel:
1. Relation (nur Hp-Mitglieder gelistet)
Hp1 in der Rolle 07:00, 08:00, 09:00, 12:00, 13:00, 15:00, 18:00, 19:00
Das können wir allgemein nicht erfassen und pflegen.
Allenfalls für Fernbusse, spezielle Züge oder Fähren mit 1-3 (evtl. bis
5) Abfahrten pro Tag wären einzelne Abfahrtszeiten in OSM machbar.
Ansonsten wären schon die Betriebszeiten und der Takt bzw. die Zahl der
Fahrten pro Tag sehr hilfreich.
Alle angesprochenen Merkmale sind Aggregate aus dem zugrundeliegenden
Fahrplan - für Linien, die keine starke Regelmäßigkeit/Struktur
aufweisen, ist eine Aggregation nutzlos. Damit lässt sich also auch
keine allgemeine Empfehlung für die Erfassung solcher Werte aussprechen.
Der Takt z.B. bringt höchstens etwas für innerstädtische Linien - im
städtischen Randgebiet ist eine Abstraktion der stark variierenden
Linienvarianten oft nicht sinnvoll. Ich sehe auch nicht, welchen
Mehrwert die Zahl der Fahren pro Tag bringen soll. Bei den
Betriebszeiten besteht die Möglichkeit, dass für manche Linien z.B. der
letzte Wagendurchlauf ein verkürzter ist, die Linie aber in OSM komplett
erfasst ist. Wer einmal den letzten Bus des Tages aufgrund schlechter
oder falsch interpretierter Information verpasst hat, kann sich
vorstellen, welche Verwendung die Informationsquelle zukünftig für
sie/ihn noch findet. Ich empfinde es daher als nutzlos,
nicht-statische, durch Mapper selbst aggregierte Informationen von
Fahrplänen in OSM zu taggen. Wem es dennoch Spaß macht, go ahead..
In die Annahme, dass wir das allgemein nicht erfassen und pflegen
_wollen_, hatte ich schon eingestimmt - "missing manpower". Wöllten wir
es, sollten wir uns auf den Fahrplan stürzen, alles andere bliebe so
unzulänglich, wie die bisherige Varianten, deren Erfassung und Pflege Du
m.E. zu recht als mühsam und unbefriedigend genau empfindest.
- manche Linien machen Abstecher, halten aber nicht notwendigerweise
zweimal, während sie den Teil des Pfades durchlaufen
Aber die Abfolge der Haltepunkte wäre doch eindeutig definiert. Wie kann
es falsche Auswertungen geben?
Indem z.B. nicht auf dem Abstecher zurückgeroutet wird, sondern vom
Router eine andere Route zur Folgehaltestelle errechnet wird.
4---------+
| |
| |
+---2----3
|
|
1
von 3 nach 4 gibt es mehrere Wege - das Unternehmen, welches den PNV
betreibt, definiert aber i.d.R. genau eine Route, die der Fahrer nimmt.
Das Problem ist, dass eine Routing-Engine u.U. nicht nach den gleichen
Kriterien entscheidet, die das Unternehmen zur Routenplanung verwendet.
Es ist sogar so, dass die Routenplanung von Unternehmen zu Unternehmen
unterschiedlich sein wird und verwendete algorithmische Grundlagen nicht
vorliegen. Die Identität zum Problem der Bestimmung des kürzesten Weges
zwischen Haltepunkten ist somit oft nicht gegeben. Dies trifft
vermutlich um so mehr zu, je weiter Haltepunkte auf einer Route
voneinander entfernt liegen. Via-Knoten können da Abhilfe schaffen,
aber lägen die dann nicht auch auf den osm-ways die von Veränderung der
Basisgeometrie betroffen sind?
In der Praxis werden bei Änderungen an den Straßendaten gerade die
streckenbasierten Busrelationen viel zu oft unterbrochen oder nicht
auf die neuen Wege angepasst, entweder weil der Mapper die Relationen
nicht gut genug kennt, keine Lust zur Anpassung hat oder schlicht
Fehler macht. Das finde ich schlimmer, als evtl. mögliche Abweichungen
von der Fahrstrecke.
+1 Ob es besser funktioniert, als die bisherige Mappingpraxis, kann
nur ein Versuch zeigen. Solange die Hps angefahren werden, sehe ich
mögliche Abweichungen vom echten Streckenverlauf auf der ÖPNV-Karte auch
nur als kosmetisches Problem. Zumal aufgrund des angesprochenen
Variantenproblems in den Linienverläufen ohnehin nur die am häufigsten
verwendete Variante einer Linie in OSM landen wird.
Das beste wäre tatsächlich eine Verknüpfung mit echten Fahrplandaten der
Verkehrsunternehmen per API. Wenn sich da in den nächsten Jahren etwas
öffnet, kann man evtl. auf die Erfassung von ÖPNV-Relationen in OSM ganz
verzichten. Ein Mashup enumeriert dann einfach die Linien über das
angebotene API, holt sich die Haltestellen je Linie, korreliert diese
mit den bus_stops in OSM, errechnet eine Route und rendert das ganze in
die ÖPNV-Karte. Vorstellbar wäre auch, dass man verschiedene Tiles
(oder Overlay-Tiles) je nach Tageszeit generiert und ausliefert, um die
Veränderung des Linienverlaufs tageszeitbedingt zu reflektieren.
Ohne API und bei dem momentanen Interesse der Community an ÖPNV bleiben
wir vermutlich auf dem momentanen Niveau einer eingeschränkt
genauen/statischen Visualisierung der Linienverläufe stehen.
-> der Pfad sollte Teil der Relation bleiben, eine Erfassung der
Haltepunkte reicht nicht aus
Ich halte ein Steckenmodell aus Halte- und via-Punkten für einfacher,
besser wartbar und robuster. Ich habe nur Zweifel, ob eine Änderung
durchsetzbar wäre, da diverse Tools das Streckenmodell auswerten und
dann geändert werden müssten.
Ich kenne mich bei den routing engine interna nicht so aus, aber es
wurde berichtet, dass psv tags selten ausgewertet werden. Das macht es
schwer, für Programmier etwa der ÖPNV-Karte auf eine Generierung der
Routen umzusteigen (statt sie aus der Relation zu lesen).
Gruß
Christian
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
