Hi Dietmar, beim Matching Fahrpläne vs. OSM ist Mentz eigentlich immer betroffen. Augsburg wird entweder direkter Kunde sein oder über die bayrische Auskunft DEFAS versorgt.
Zur Erinnerung: Mentz routet auf dem OSM-Straßen- und Schiennetz, d.h. wir werten Haltestellen aus, und der Ablgeich zwischen VU-Daten und OSM-Daten findet auf dieser Ebene (ganz präsize: auf Ebene der Steige) statt. Wir benutzen keine Routen-Relationen aus OSM. Die andere Frage ist: wofür wollen wir die oben genannten Daten erfassen? Erst wenn man eine konkrete Anwendung benennt, dann kann man herausfinden, ob die Daten sich dafür eignen. Das schließt nicht aus, dass es später auch andere Anwendungen gibt, und so sollte es auch sein. Aber ohne zumindest eine Anwendung produziert man das, was Jochen neulich zum Thema Grenzrelationen als schwer auswertbare Daten angesprochen hatte. Für die Anwendung "Fahrplanauskunft" braucht man gar keine Routen-Relationen. Ich persönlich hätte ansonsten gerne eine Karte, auf der alle Linien eingetragen sind, die häufig fahren. Wie es jemand auf der FOSSGIS so schön schilderte: er sucht sich Hotels danach aus, dass sie eine häufige Verbindung zum Konferenzort haben, und dafür möchte er wissen, wo man vom Konferenzort aus häufig und problemlos hinkommt. Dann wäre es vor allem gut, auf den Relationen der oben genannten Linien ein Tag "Fahrten pro Tag" zu haben, so dass man die Relationen als selten bedient identifizieren kann. Die Diskussion darum versandet allerdings regelmäßig in anderen Grabenkämpfen. Die Fahrten-Nr selbst sind mir sonst noch nirgendwo als relevante Information begegnet, sondern entweder betriebsintern oder tiefer Bestandteil der Fahrplandaten. Ich würde in der Gesamtwürdigung die Fahrten-Nr einfach in "note:de" belassen und überlegen, für welche Anwendung man die Daten haben möchte. Ansonsten sei auf die Mailingliste nahverkehr@ hingewiesen; dort lesen zumindest mehr ÖPNV-affine Mapper mit. Viele Grüße, Roland Am 22. Juni 2017 um 22:06 schrieb Dietmar Seifert <ostr...@diesei.de>: > Hallo Toni, > > Du hast geschrieben: >> Die Frage ist aber: brauchen wir das wirklich, dass eine Anwendung ref >> und Fahrt-Nr. auswählen will? >> Was wäre das Szenario für sowas? >> Oder kann das anderweitig hergeleitet werden - nicht zu kompliziert halt? >> "anderweitig hergeleitet" vor allem für Relationen für die es keine >> Fahrt-Nr. gibt - im MVV ist mir sowas noch nicht aufgefallen. >> "anderweitig hergeleitet" als kleinster gemeinsamer Nenner? >> > > Nehmen wir an, ich nutze ein ÖPNV-App und will von Ort A Haltestelle x > nach Ort B Haltestelle y: dann kann die App pur in OSM die möglichen > Relationen finden. > > Eine App muß aber auch konkret sagen, wann der nächste Bus kommt. Das > geht nur mit dem Fahrplan der ÖPNV-Linie. Der User gibt Zeitpunkt und > Srt und Ziel an und dann wird im Fahrplan die richtige Tour gefunden. > Dann kann zwar in OSM geprüft werden, ob es eine oder mehrere Relationen > gibt, wo Start und Ziel enthalten sind. Zusätzlich müssten aber alle > weiteren Stopps auch noch geprüft werden. Erst bei kompletter > Übereinstimmung würde vermutlich eine OSM-Relation übrig bleiben. > > Ich würde als App-Entwickler eine stabile Querbeziehung suchen und das > wäre erst die Fahrtnummer (oder bereits eindeutig oder nur in Verbindung > mit Buslinie, muss ich noch prüfen). > > @Roland: seid Ihr da betroffen bzgl. Matching Fahrpläne vs. OSM > Bus-Relationen? > > viele Grüße > > Dietmar > > > > Am 22.06.2017 um 21:48 schrieb Toni Erdmann: >> Hallo Dietmar, >> >> für die unterschiedlichen Strecken- und/oder Stopverläufe sollen laut >> PTv2 jeweils genau eine Relation erstellt werden. >> PTv2 sagt nichts über die von Dir hier erwähnten Fahrt-Nr. - die scheint >> es nicht so häufig zu geben. >> >> Ich interpretiere PTv2 aber so, dass die Fahrt-Nr. *nicht* in die "ref" >> hinein kommt. >> Wenn wir also eine Unterscheidung der Fahrt-Nr. machen wollen, dann >> brauchen wir meiner Meinung nach einen weitere Key: ref:xxx oder so? >> >> name=Bus 15 >> ref=51 >> ref:xxx=1501 >> ref:xxx=1502;1503 >> ref:xxx=1504 >> >> für 4 Fahrten über 3 unterschiedliche Routen. >> >> Die Frage ist aber: brauchen wir das wirklich, dass eine Anwendung ref >> und Fahrt-Nr. auswählen will? >> Was wäre das Szenario für sowas? >> Oder kann das anderweitig hergeleitet werden - nicht zu kompliziert halt? >> "anderweitig hergeleitet" vor allem für Relationen für die es keine >> Fahrt-Nr. gibt - im MVV ist mir sowas noch nicht aufgefallen. >> "anderweitig hergeleitet" als kleinster gemeinsamer Nenner? >> >> Gruß >> Toni >> >> >> Am 21.06.2017 um 11:53 schrieb Dietmar: >>> Hallo, >>> >>> bei den Augsburger Verkehrsbetrieben (AVV) werden im Linienplan neben >>> der Ref. für die Buslinie noch für jede Verbindung eine Fahrt-Nr. >>> angegeben. >>> >>> Für jeden unterschiedlichen Strecken- und/oder Stopverlauf wurde eine >>> Relation angelegt und bisher wird nur im Tag note.de die Fahrt-Nr. >>> gespeichert. Die eine ausgewählte Fahrt-Nr. steht stellvertretend für >>> meist mehrere Fahrt-Nr. >>> >>> Wie soll die Fahrt-Nr. getaggt werden (ich würde dann im Value die >>> gesamten Fahrt-Nr. mit ; getrennt auflisten)? Sie ist eine Unterordnung >>> von ref. Nur in Kombination von Ref und der Fahrt-Nr. könnte eine >>> externe Anwendung die richtige Relation auswählen (oder durch gesamte >>> Analyse der Stops, aber das auch nicht eindeutig). >>> >>> viele Grüße >>> >>> Dietmar >>> >> >> _______________________________________________ >> Talk-de mailing list >> Talk-de@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-de -- Dr. Roland Olbricht MENTZ GmbH, Am Mittelhafen 10, 48155 Münster T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300 E: olbri...@mentz.net, www.mentz.net Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München Geschäftsführer: Christoph Mentz, Amtsgericht München, HRB 91898 _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
