Re: [Talk-de] Public transport V2: wie Fahrt-Nr. zu einer Ref angeben?
Würde es dann nicht besser in trips_ref oder ref:trips gespeichert werden? Den Sinn sehe ich nicht wirklich, obwohl ich auch schon überlegt habe. Bei uns ist die Information aber nicht Publik vorhanden. Polyglot 2017-06-23 11:16 GMT+02:00 Dietmar Seifert : > Hallo Roland, > > vielen Dank für die Info aus Sicht der Auswerter. > > Dann speichern wir die Fahrt-Nr. wie gehabt mehr für uns intern zur > Identifizierung weiterhin in note:de > > > viele Grüße > Dietmar > > > Am 23.06.2017 um 08:27 schrieb Roland Olbricht: > > 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 : > >> 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 Ro
Wochennotiz Nr. 361 13.06.2017–19.06.2017
Hallo, die Wochennotiz Nr. 361 mit vielen wichtigen Neuigkeiten aus der OpenStreetMap-Welt ist da: http://blog.openstreetmap.de/blog/2017/06/wochennotiz-nr-361/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Public transport V2: wie Fahrt-Nr. zu einer Ref angeben?
Hallo Roland, vielen Dank für die Info aus Sicht der Auswerter. Dann speichern wir die Fahrt-Nr. wie gehabt mehr für uns intern zur Identifizierung weiterhin in note:de viele Grüße Dietmar Am 23.06.2017 um 08:27 schrieb Roland Olbricht: > 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 : >> 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.2
