Re: [Talk-de] ÖPNV-Relationen in OSM
Am 02.04.2012 03:13, Stephan Wolff: Moin, ich habe schon viele Stunden Arbeit in die Erstellung und Pflege von ÖPNV-Relationen (Bus-, Bahn- und Fährlinien) investiert. Leider ist der Erfolg meiner Bemühungen (und der vieler anderer Mapper) gering. Um das Thema nochmal aufzugreifen: Welches Schema präferierst du denn aktuell? Liest hier jemand auch auf talk-transit mit und kann sagen, wo da der aktuelle Trend bzw. die Mehrheitsverhältnisse hindeuten? Ich würde gerne nach dem Lizenzwechsel die Relationen in meiner Gegend wieder warten, bin mir aber unsicher, nach welchem Schema. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen in OSM
Am 04.04.12 01:58, schrieb Garry: Am 03.04.2012 17:05, schrieb Andreas Neumann: STOP! Ich weiß, jeder darf alles mappen, was er für würdig hält, aber hier sind wir an einen Punkt angelangt, der weder auf Dauer wartbar ist, noch in der Fläche realisierbar wird. Bei solch fluktuierenden Daten sollten wir uns überlegen, eher die Verkehrsverbände drauf zu drängen, dass die ihre Daten maschinenlesbar zur Verfügung stellen und wir nur noch eine ID an die Linie packen. Ansonsten wäre es reiner Wahnsinn. +1 Der Aufwand die Daten in OSM zu erfassen ist viel zu hoch dafür nur um Demo-Anwendungen damit zu füttern die zeigen was man alles tolles mit den Daten machen könnte, sowas hier z.B.: http://www.openstreetmap.org/browse/relation/403713 (Es gibt auch eine Relation für Normalsterbliche) aber kaum jemals so weit kommen wird daraus eine annähernd zuverlässige Anwendung zu machen. +1 Ein brauchbarer ÖPNV-Router kommt ohne Fahrplandaten und Echtzeitinformationen nicht aus. Wir liefern allenfalls Geodaten, also: wo ist die Haltestelle, und an welchem Haltestellenmast fährt welcher Bus mit welchem Ziel ab. Alles andere weiß der Verkehrsbetrieb besser als wir. Die Linienwege in der Relation sind ne nette Beigabe für den Renderer, und um dem Mapper den Linienweg zu veranschaulichen. Eine Relation pro Richtung ist dabei ein brauchbarer Kompromiss. Denn spätestens bei solchen Linien: http://www.bahn.de/westfalenbus/view/mdb/kursbuch/mdb_3985_464.pdf ist die Eine-Relation-pro-Fahrt-Methode für den Mapper ziemlich unübersichtlich. Und die Fahrplandaten machen mit Fußnote Fahrt verkehrt nur bei Betrieb der Schule oder des Kindergartens in Bödefeld in unserem Datenbestand auch keinen Sinn mehr. Wer effektiv routen will, nimmt die Haltestellen in der im Fahrplan zeitlich geordneten Reihenfolge, und routet auf dem vorhandenen Straßennetz. Dabei können die Relationsmitglieder eventuell noch höher priorisiert werden. Gruß, Andre Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen in OSM
Am 03.04.2012 17:05, schrieb Andreas Neumann: STOP! Ich weiß, jeder darf alles mappen, was er für würdig hält, aber hier sind wir an einen Punkt angelangt, der weder auf Dauer wartbar ist, noch in der Fläche realisierbar wird. Bei solch fluktuierenden Daten sollten wir uns überlegen, eher die Verkehrsverbände drauf zu drängen, dass die ihre Daten maschinenlesbar zur Verfügung stellen und wir nur noch eine ID an die Linie packen. Ansonsten wäre es reiner Wahnsinn. gerne. Aber es wird auch dann noch genügend manuelle Arbeit bleiben. Für die elektronische Fahrplanauskunft gibt es eine Menge von Austauschformaten. Dabei handelt es sich meist um Herstellerstandards die zudem lausig dokumentiert sind. Aber wenigstens sind es ASCII oder CSV-Formate und somit halbwegs lesber. Die Fahrten werden entweder im vollständigen Verlauf abgelegt (HAFAS-Rohdatenformat) oder in Profile zerlegt. Im Hafas-Format sind die Linien nur optional. Die DB kennt diese nicht. Im ÖPNV-Bereich ist gibt es in der Regel eine als Klartext codierte Linie sowie die Richtung 1/2 (oder war es 0/1?). In den meisten anderen Formaten sind die Fahrten als Profile abgelegt. Es gibt ein Profil der Haltestellenfolge, ein Fahrzeitprofil und eine Liste der Fahrten, aus der Haltestellenfolge, Fahrzeitprofil und Abfahrtszeit hervorgeht. (Verkehrsmittel, Gültigkeit und weitere Attribute lasse ich mal außen vor). Auch hier haben die Linien außer der Textbezeichnung nur selten eine ID. Wenn Profile vorkommen haben die ID keine Konsistenz. Sprich wenn eine weitere Variante hinzukommt ist die Varianten-ID eine andere. Die Pflege der Haltestellen erfolgt je nach System und Sorgfalt in der Datenpflege in ein bis drei Ebenen. Gesamthaltestelle, ggf. zusammengefasster Bereich mehrerer Haltestellen mit ähnlichen Umsteigebeziehungen und ggf. einzelner Mast. Die Linienwege pflege ich in einem GIS. Daraus kann ich diese als Shape exportieren. Das bringt bei der Übernahme in OSM nicht allzu viel. Zudem kann ich eine Datei erzeugen, die den Verlauf für jedes Streckensegment von Mast(ID) nach Mast(ID) mit Zwischenpunkten ausgibt. Diese nutze ich zur Visualisierung des Fahrwegs einer konkreten Verbindungsabfrage. Selbst wenn dieses Polygon auf OSM basierend geroutet wird, besteht keine Verknüpfung mit den Netzsegmenten in OSM. Wenn man das verbessern wollte, bräuchte man in OSM ein anderes Datenmodell. Dann müssten Kleinrelationen Mast-Mast angelegt werden, auf die man dann relativ automatisch die ganzen Linienvarianten mit ihren ganzen Haltestellenfolgen legen könnte. Derzeit plane ich eine Haltestellen-/Netzverwaltung. Damit will ich mit den vorhandenen Daten neben dem für die eigentliche Arbeit auch Netzextrakte erzeugen. Also Gesamtnetz als Shape/GPX/OSM, Einzellinien, ggf. auch einzelne Varianten usw. Das soll im Laufe des Jahres fertig werden. Aber selbst unter optimalen Voraussetzungen wird das die Arbeit der Community allenfalls erleichtern. Das ganze wird als OpenSource bereit gestellt werden, http://www.fapla.de. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen in OSM
Am 04.04.2012 08:04, schrieb Andre Joost: Am 04.04.12 01:58, schrieb Garry: Am 03.04.2012 17:05, schrieb Andreas Neumann: STOP! Ich weiß, jeder darf alles mappen, was er für würdig hält, aber hier sind wir an einen Punkt angelangt, der weder auf Dauer wartbar ist, noch in der Fläche realisierbar wird. Bei solch fluktuierenden Daten sollten wir uns überlegen, eher die Verkehrsverbände drauf zu drängen, dass die ihre Daten maschinenlesbar zur Verfügung stellen und wir nur noch eine ID an die Linie packen. Ansonsten wäre es reiner Wahnsinn. +1 Der Aufwand die Daten in OSM zu erfassen ist viel zu hoch dafür nur um Demo-Anwendungen damit zu füttern die zeigen was man alles tolles mit den Daten machen könnte, sowas hier z.B.: http://www.openstreetmap.org/browse/relation/403713 (Es gibt auch eine Relation für Normalsterbliche) aber kaum jemals so weit kommen wird daraus eine annähernd zuverlässige Anwendung zu machen. +1 Ein brauchbarer ÖPNV-Router kommt ohne Fahrplandaten und Echtzeitinformationen nicht aus. Wir liefern allenfalls Geodaten, also: +1 Es gibt ein länderübergreifenden Projekt, an dem schon mehrere Bundesländer teilnehmen und das europaweit ausgedehnt werden soll. Hab keine Ahnung, unter welcher Lizenz das Projekt und die Implementierungen stehen: www.delfi.de/ Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen in OSM
Am 04.04.2012 12:23, schrieb bkmap: Es gibt ein länderübergreifenden Projekt, an dem schon mehrere Bundesländer teilnehmen und das europaweit ausgedehnt werden soll. Hab keine Ahnung, unter welcher Lizenz das Projekt und die Implementierungen stehen: www.delfi.de/ Das ist derzeit nur eine Verknüpfung der Auskunftssysteme. Zwischen den Bundesländern sind Übergabepunkte definiert. Meist sind das Fernverkehrsbahnhöfe. Dazwischen findet eine verteile Verbindungssuche statt. Netzinformationen oder Haltestellenfahrpläne gibt es darüber derzeit nicht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen in OSM
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. Ich hatte auch schonmal darüber nachgedacht, ob nicht die Haltepunkte reichen, um den Linienverlauf automatisiert mittels geeigneter Routing-Engine ermitteln zu lassen. Das birgt aber folgende Probleme: - 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? - Linien folgen nicht notwendigerweise dem kürzesten Pfad (u.U. durch Rücksicht auf Anwohnergebiete oder andere Gegebenheiten: Straßenausbau, etc.) Wie Martin schon schrieb: man könnte via-Punkte einfügen. - Routing ist _nicht_ stabil: stellt euch vor, euer Router ermittelt automatisiert einen korrekten Linienverlauf, einen Monat später macht ein Mapper eine Ergänzung, welche die kürzeste Route beeinflusst - schon würde sich die Route der Linie ändern (und entspräche demnach nicht mehr dem in der Realität unveränderten Verlauf) Bei den üblichen Ergänzungen und Verfeinerungen der Straßendaten wird wohl in fast allen Fällen die neue Route korrekt sein. In wenigen Fällen würde auf einer ÖPNV-Karte ein abweichender Streckenverlauf zwischen zwei aufeinanderfolgenden Haltepunkten angezeigt. Abgesehen von Sightseeing-Fahrten ist es für den Fahrgast meist egal, welchen von zwei gleichlangen Wegen der Bus nimmt. 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. - 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. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen in OSM
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-+ | | | | +---23 | | 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
Re: [Talk-de] ÖPNV-Relationen in OSM
Am 03.04.2012 02:35, schrieb Stephan Wolff: Relation in 2 aufspalten. Wenn es alternativ bediente Teilstrecken sind, dann sollte man die Das Problem vieler Streckenvarianten derselben Linie wurde oft diskutiert aber nie gelöst. 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 - da fehlt aber die manpower. Prinzipiell kann man daran ständig arbeiten, da auch die Verkehrsunternehmen im Ganz- oder Halbjahrestakt Anpassungen vornehmen. Ansonsten kann man die Haltepunkte aus der Sicht von post_boxen betrachten, vgl.: post_box: collection_times bus_stop: collection_times pro Linie pro Richtung Beispiel: Morgens, Mittags und Abends wird die Route komplett befahren, Vor- und Nachmittags jedoch nur bis zu einem Zwischenstopp Haltepunkte sind Hp1(Start) Hp2 Hp3(Zwischenstopp) Hp4(Ende) - es gibt zwei Linienrelationen (eine pro Richtung) 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 Hp2 in der Rolle 07:10, 08:10, 09:10, 12:10, 13:10, 15:10, 18:10, n/a Hp3 in der Rolle 07:15, 08:15, 09:15, 12:15, 13:15, 15:15, 18:15, 19:15 Hp4 in der Rolle 07:30, 08:30, n/a, 12:30, n/a, n/a, 18:30, 19:30 2. Relation analog - Hp in umgekehrter Reihenfolge Grob gedacht: Nutze Werte in der Art, wie sie für collection_times verwendet werden, im Feld Rolle der Haltepunkte pro Relation. Darüber würde effektiv der Fahrplan abgebildet. Ich hatte auch schonmal darüber nachgedacht, ob nicht die Haltepunkte reichen, um den Linienverlauf automatisiert mittels geeigneter Routing-Engine ermitteln zu lassen. Das birgt aber folgende Probleme: - manche Linien machen Abstecher, halten aber nicht notwendigerweise zweimal, während sie den Teil des Pfades durchlaufen - Linien folgen nicht notwendigerweise dem kürzesten Pfad (u.U. durch Rücksicht auf Anwohnergebiete oder andere Gegebenheiten: Straßenausbau, etc.) - Routing ist _nicht_ stabil: stellt euch vor, euer Router ermittelt automatisiert einen korrekten Linienverlauf, einen Monat später macht ein Mapper eine Ergänzung, welche die kürzeste Route beeinflusst - schon würde sich die Route der Linie ändern (und entspräche demnach nicht mehr dem in der Realität unveränderten Verlauf) - der Pfad sollte Teil der Relation bleiben, eine Erfassung der Haltepunkte reicht nicht aus Viele Grüße, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen in OSM
STOP! Ich weiß, jeder darf alles mappen, was er für würdig hält, aber hier sind wir an einen Punkt angelangt, der weder auf Dauer wartbar ist, noch in der Fläche realisierbar wird. Bei solch fluktuierenden Daten sollten wir uns überlegen, eher die Verkehrsverbände drauf zu drängen, dass die ihre Daten maschinenlesbar zur Verfügung stellen und wir nur noch eine ID an die Linie packen. Ansonsten wäre es reiner Wahnsinn. Andreas signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen in OSM
Am 03.04.2012 16:23, schrieb Christian Müller: Am 03.04.2012 02:35, schrieb Stephan Wolff: Relation in 2 aufspalten. Wenn es alternativ bediente Teilstrecken sind, dann sollte man die Das Problem vieler Streckenvarianten derselben Linie wurde oft diskutiert aber nie gelöst. 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 - da fehlt aber die manpower. Prinzipiell kann man daran ständig arbeiten, da auch die Verkehrsunternehmen im Ganz- oder Halbjahrestakt Anpassungen vornehmen. Ansonsten kann man die Haltepunkte aus der Sicht von post_boxen betrachten, vgl.: post_box: collection_times bus_stop: collection_times pro Linie pro Richtung Beispiel: Morgens, Mittags und Abends wird die Route komplett befahren, Vor- und Nachmittags jedoch nur bis zu einem Zwischenstopp Haltepunkte sind Hp1(Start) Hp2 Hp3(Zwischenstopp) Hp4(Ende) - es gibt zwei Linienrelationen (eine pro Richtung) 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 Hp2 in der Rolle 07:10, 08:10, 09:10, 12:10, 13:10, 15:10, 18:10, n/a Hp3 in der Rolle 07:15, 08:15, 09:15, 12:15, 13:15, 15:15, 18:15, 19:15 Hp4 in der Rolle 07:30, 08:30, n/a, 12:30, n/a, n/a, 18:30, 19:30 2. Relation analog - Hp in umgekehrter Reihenfolge Grob gedacht: Nutze Werte in der Art, wie sie für collection_times verwendet werden, im Feld Rolle der Haltepunkte pro Relation. Darüber würde effektiv der Fahrplan abgebildet. ... Viele Grüße, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Auch wenn der Streckenverlauf in den letzten Jahren schon deutlich ausgemistet wurde, ist z.b. der 32A [1] eine gewisse Herausforderung (eine Richtung alleine 5 Streckenvarianten, Mo-Fr, Sa, So, Schule, nicht Schule, etc.). Aber nur durch die Angabe der Haltepunkte wird man da vermutlich nicht die Fahrtroute definieren können. Ich glaube der aktuelle Ansatz, jede Route einzeln zu zeichnen, ist da sinnvoller. Man müsste dann in einer externen Datenbank die Verbindung zwischen Routenvariante und Fahrplan erstellen. (z.b. Mo-Fr 07:00 Variante1; Sa 09:00 Variante2; etc.) Wie man auch in [1] auf Seite 42 sieht (aufgrund der Fehlermeldung), müsste es zumindest für Wien auch einen maschinenlesbaren Code geben, nur habe ich zweifel, dass man den auch bekommt. LG Jimmy [1] http://www.wienerlinien.at/media/download/2012/Linie_32A_ab_2_11_2012_70450.pdf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen in OSM
Am 03.04.2012 17:05, schrieb Andreas Neumann: STOP! Ich weiß, jeder darf alles mappen, was er für würdig hält, aber hier sind wir an einen Punkt angelangt, der weder auf Dauer wartbar ist, noch in der Fläche realisierbar wird. Bei solch fluktuierenden Daten sollten wir uns überlegen, eher die Verkehrsverbände drauf zu drängen, dass die ihre Daten maschinenlesbar zur Verfügung stellen und wir nur noch eine ID an die Linie packen. Ansonsten wäre es reiner Wahnsinn. +1 Der Aufwand die Daten in OSM zu erfassen ist viel zu hoch dafür nur um Demo-Anwendungen damit zu füttern die zeigen was man alles tolles mit den Daten machen könnte, aber kaum jemals so weit kommen wird daraus eine annähernd zuverlässige Anwendung zu machen. Da das Smartphone inzwischen zum Produkt für die Masse wurde wirkt sich das auch im mehr auf die Verkehrsbetriebe aus die entsprechenden Daten/Anwendungen zur Verfügung zu stellen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen in OSM
Am 2. April 2012 03:13 schrieb Stephan Wolff s.wo...@web.de: Die Relationen beschreiben entweder nur eine Richtung einer Linie, beide Fahrtrichtungen oder sogar verschiedene Linienvarianten in einer Relation. ja, das ist so, und erstmal kein Problem (verschiedene Varianten in einer Relation sollte man allerdings ausgliedern) Die Straßensegmente sind (teilweise falsch) mit role-Tag forward/backward, manchmal mit route, default, alternate etc. versehen. stop_position- und platform-Punkte haben role-Tags , stop, platform aber auch stop:22 oder platform:60:alternate:1. Die Haltestellen sind teils zwischen den ways, oft auch unsortiert am Ende. auch hier gibt es doch durch die unterschiedlichen Mapping-Varianten nicht grundsätzlich ein Problem, Fehler wie falsche Rollen sollte man natürlich korrigieren. name-Tags sind fast immer willkürliche Textfolgen aus ref/operator/network/direction. solange man weiss, welche Linie es ist (ref), ist das doch egal. Den name-Tag könnte man i.d.R. auch einfach weglassen bzw. beim Interpretieren nicht weiter berücksichtigen, da verstehe ich das Problem ebenfalls nicht. from und to fehlen teilweise oder sind uneinheitlich gebildet. Einzig die Liniennummer ist eindeutig im ref-Tag enthalten. Es kommt halt darauf an, was man haben will. Mit der Zeit sind auch unsere Ansprüche gestiegen, während man früher zufrieden war wenn man aus der Karte erraten konnte, wo der Bus der Linie 23 langfährt, so wollen manche Mapper heute auch noch zusätzlich festhalten, dass dort jeder zweite Bus ein Bus mit erhöhter Kapazität ist, mit einem durchschnittlichen Fahrzeugsalter von 3.4 Jahren, Behindertenrampe an Bord, und statistischer Verspätung von 1.2 Minuten um die Mittagszeit an Haltestelle XY (mal etwas übertrieben dargestellt). Viele Relationen sind durch spätere Bearbeitung der ways beschädigt. kann man schnell richten, wenn man weiss, wo der Bus langfährt. Üblicherweise kenne ich das von Stellen, die zunächst noch grob gemappt waren (also z.B. nur ein Way trotz mehrerer Fahrbahnen), wo aber schonmal jemand eine Buslinie draufgelegt hat. Danach hat beim Aufsplitten der Richtungen jemand nicht aufgepasst. Die Daten reichen aus, um eine Karte mit Liniennummern an Straßen und Haltestellen zu erzeugen. Unsortierte Relationselemente, unsinnige role-Angaben und kleine Lücken erzeugen allenfalls kleine Kartenfehler, die der menschliche Betrachter meist ignorieren kann. stimmt. Wahrscheinlich könnte man mit nicht zu großem Aufwand auch automatische Auswertungen soweit fehlertolerant gestalten, dass sie z.B. kleine Lücken ohne menschliche Intervention schließen können oder unsinnige Role-Angaben ignorieren. Relationselemente zu sortieren ist normalerweise trivial. Für andere Anwendungen sind die Daten ungenügend. Die vielen Tagging- Varianten machen es unmöglich, die Daten korrekt zu interpretieren. s/unmöglich/schwieriger bzw. aufwendiger Selbst wenn eine Relationen eine unverzweigte Strecke abbildet und keine Fehler hat, kann man die Angaben nicht zur Fahrtplanung nutzen, da keine Informationen zu Betriebszeiten, Takt oder Fahrzeiten bietet. Viele gedruckte Reiseführer enthalten dagegen grobe Informationen wie bis Ziel ca. 70 Min., Mo-Sa 6-22Uhr, So 8-20Uhr, tagsüber alle 15 Minuten, nach 18Uhr alle 30 Min., die auch Jahre nach dem Druckdatum noch nützlich sind. Solche Informationen wären auch in OSM möglich. +1, wenn der Mapper es für sinnvoll hält, dann sollte er durchaus diese Dinge eintragen können, wobei sich das je nach Gegend auch schnell und häufig ändern kann, so dass jahrealte Informationen prinzipiell mit Vorsicht zu genießen sind. In meinem Umfeld hier gibt es z.B. gar keine Fahrpläne (für Busse tagsüber), sondern nur Informationen wie von Dir genannt (d.h. z.B. Bus verkehrt Mo-Fr von 6:00-24:00h, jeweils Abfahrt Starthaltestelle). Leider können sich die relativ großen Relationen des ÖPNV auch unmittelbar störend auswirken. jede Zusatzinformation macht natürlich die weitere Bearbeitung komplexer, das gilt auch hier. Wenn man etwas an Relationen geändert hat, ist immer ein Konflikt beim Upload möglich, der von vielen Mappern nicht korrekt gelöst werden kann. die Konflikte treten viel eher bei den anderen Route-Relationen auf, die sich oft übers ganze Land oder sogar international durch die Landschaft ziehen (Fernstraßen, Fernwanderwege, etc.). Bei einer normalen Buslinie sollte das nicht allzu oft vorkommen. Klar, je mehr Leute editieren, und je größer ein Objekt ist, um so eher kommt es auch zu Konflikten. Die Qualität der ÖPNV-Relationen hat sich nach meiner Einschätzung in den letzten zwei Jahren nicht gebessert. Das kommt sicher darauf an, wo man mappt. Hier ist der Fortschritt unglaublich groß verglichen zum Stand vor 2 Jahren. - ein Bot, der jede Nacht die unterbrochenen Relationen repariert, die role-Tags richtig setzt und nicht automatisch korrigierbare Relationen meldet (auch sehr schwierig
Re: [Talk-de] ÖPNV-Relationen in OSM
Am 02.04.2012 03:13, schrieb Stephan Wolff: Moin, ich habe schon viele Stunden Arbeit in die Erstellung und Pflege von ÖPNV-Relationen (Bus-, Bahn- und Fährlinien) investiert. Leider ist der Erfolg meiner Bemühungen (und der vieler anderer Mapper) gering. Die Relationen beschreiben entweder nur eine Richtung einer Linie, beide Fahrtrichtungen oder sogar verschiedene Linienvarianten in einer Relation. Die Straßensegmente sind (teilweise falsch) mit role-Tag forward/backward, manchmal mit route, default, alternate etc. versehen. stop_position- und platform-Punkte haben role-Tags , stop, platform aber auch stop:22 oder platform:60:alternate:1. Die Haltestellen sind teils zwischen den ways, oft auch unsortiert am Ende. name-Tags sind fast immer willkürliche Textfolgen aus ref/operator/network/direction. from und to fehlen teilweise oder sind uneinheitlich gebildet. Einzig die Liniennummer ist eindeutig im ref-Tag enthalten. Viele Relationen sind durch spätere Bearbeitung der ways beschädigt. Das beruht noch vieles auf alten Mappingmethoden (forward, stop, etc. und die Reihenfolge der ), wo es teilweise einfach noch kein einheitliches Schema gab und jeder sein Bestes gab. Ich glaube es würde schon etwas bringen, wenn man eine eigene, übersichtliche Seite zur Erstellung von Routen-Relationen, mit allgemeinverständlichen Beispielen, erstellt. Dass einige Elemente eine Rolle haben und andere nicht, finde ich etwas unübersichtlich, vielleicht sollte man Haltepunkte und Bahnsteige in eine eigene Relation schmeißen? ad name-Tags: da gibt es ein soll: http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route_direction.2Fvariant Bei vielen Relationen ist nicht erkennbar, ob zwei Haltestellen vom selben Bus angefahren werden oder ob sie zu zwei alternativ bedienten Teilstrecken gehören. Wenn es alternativ bediente Teilstrecken sind, dann sollte man die Relation in 2 aufspalten. Bei allen Varianten könnte man Tags für Betriebszeiten (operating_hours), Takt(frequency?), Fahrzeiten (duration) und wenn möglich eine URL des Fahrplans (url:timetable?) hinzufügen. oder Ich würde Takt eher mit interval übersetzen, aber da gibt es sicher einige Kollegen, welche die englische Sprache besser beherrschen. -- Zum Thema Wartung der Routen: Eine übersichtliche Wiki Seite (wie z.b. hier: http://wiki.openstreetmap.org/wiki/Vienna_OSM_Coverage#Stra.C3.9Fenbahn) und dann gibt es Relation Analyzer, z.B.: http://ra.osmsurround.org/ So gehe ich zumindest vor um halbwegs die Übersicht zu behalten. LG Jimmy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen in OSM
Am 02.04.2012 10:54, schrieb Martin Koppenhoefer: Am 2. April 2012 03:13 schrieb Stephan Wolffs.wo...@web.de: Die Relationen beschreiben entweder nur eine Richtung einer Linie, beide Fahrtrichtungen oder sogar verschiedene Linienvarianten in einer Relation. ja, das ist so, und erstmal kein Problem Routing über Relationen ist damit nicht möglich. (verschiedene Varianten in einer Relation sollte man allerdings ausgliedern) Da es keinen Konsens gibt, wie Linienvarianten zu behandeln sind, macht das niemand. auch hier gibt es doch durch die unterschiedlichen Mapping-Varianten nicht grundsätzlich ein Problem, Fehler wie falsche Rollen sollte man natürlich korrigieren. Kein Programm kann alle Varianten richtig interpretieren. name-Tags sind fast immer willkürliche Textfolgen aus ref/operator/network/direction. solange man weiss, welche Linie es ist (ref), ist das doch egal. Den name-Tag könnte man i.d.R. auch einfach weglassen bzw. beim Interpretieren nicht weiter berücksichtigen, da verstehe ich das Problem ebenfalls nicht. Echte Namen sind von Pseudonamen nicht unterscheidbar. Das name-Tag ist eines der wichtigsten in OSM. Es wird schon oft genug missbraucht, um Texte auf die Karten zu schreiben. Hier wird das Tag als interne Merkhilfe für Mapper, die nicht zur Auswertung genutzt werden kann, umgedeutet. from und to fehlen teilweise oder sind uneinheitlich gebildet. Einzig die Liniennummer ist eindeutig im ref-Tag enthalten. Es kommt halt darauf an, was man haben will. Mit der Zeit sind auch unsere Ansprüche gestiegen, während man früher zufrieden war wenn man aus der Karte erraten konnte, wo der Bus der Linie 23 langfährt, Dafür würde ein Tag am way genügen, der viel weniger Arbeit macht. Mit den geordneten Relationen kann man weitere Informationen unterbringen, aber sie sind leider nicht nutzbar. Für andere Anwendungen sind die Daten ungenügend. Die vielen Tagging- Varianten machen es unmöglich, die Daten korrekt zu interpretieren. s/unmöglich/schwieriger bzw. aufwendiger De facto unmöglich, da Varianten wie role=platform:60:alternate:1 nirgendwo definiert sind, oft nicht erkennbar ist, welche Definition genutzt wird, und Mischvarianten existieren. Leider können sich die relativ großen Relationen des ÖPNV auch unmittelbar störend auswirken. jede Zusatzinformation macht natürlich die weitere Bearbeitung komplexer, das gilt auch hier. Zusatzinformation in Tags stört normalerweise nicht bei der Bearbeitung, Mitgliedschaft in Relationen erfordert dagegen oft Verständnis für den Relationstyp, macht Arbeit und birgt die Gefahr von Konflikten. Ich finde Relationen nicht falsch, aber es sollte einen Mehrwert gegenüber einfachen Tags geben. - Umstellung auf ein stark vereinfachtes Relationsschema, bei dem nur die Haltepunkte, aber nicht die Stecken Elemente der Relation sind. -1, die Routen sollten eindeutig beschrieben sein, dass wäre mit diesem Vorschlag nicht der Fall. Man müsste mindestens noch Zwischenpunkte (Via-Punkte, die es so nicht gibt in der Realität) erfinden, um halbwegs verlässliche Daten zu haben, die aber trotzdem nie ganz eindeutig sein könnten (da auch wenn sie es scheinbar jetzt sind, der Straßengraph jederzeit erweitert werden kann) . Ist eine Buslinie in der realen Welt über eine exakte Strecke oder nur über die Haltestellenabfolge definiert? Ich kenne Buslinien bei denen die Fahrer verschiedene Strecken nehmen (z.B. Kielius: Kiel Hbf. - Hamburg Flughafen, bei dem ich schon auf drei Wegen vom Startpunkt zur Autobahn gefahren wurde). Auch die Bahn schickt ihre Züge gegebenenfalls über wechselnde Vorfeldgleise zum Zielbahnsteig. Meist ist die Strecke zwischen zwei Haltepunkten ohnehin eindeutig. Wenn man eine Fahrstrecke genauer definieren möchte, finde ich einen via-Punkt nicht schlechter als mehrere via-ways. (Auch die via-Punkte der Abbiegerelationen gibt in der Realität nicht.) Bei allen Varianten könnte man Tags für Betriebszeiten (operating_hours), Takt(frequency?), Fahrzeiten (duration) und wenn möglich eine URL des Fahrplans (url:timetable?) hinzufügen. +1, diese neuen Tags kann man an die Linien hängen, unabhängig von Deinen anderen Vorschlägen. oder - Verzicht auf gerichtete ÖPNV-Linien in OSM. Dann genügt eine leicht zu pflegende Tag-basierte Lösung um Liniennummern mit Haltestellen und Fahrstrecken zu verbinden. Gerichtete Linien hat man ja nur deshalb eingeführt, weil es viele Linien gibt, die hin- und rückwärts nicht die genau gleiche Strecke abfahren. Auch dafür würden Tags (lines:forward, lines:backward) genügen. Mit gerichtete ÖPNV-Linien meine ich die Definition einer Haltestellenabfolge, die man für potentielles Routing braucht. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen in OSM
Am 02.04.2012 16:23, schrieb Jimmy_K: Am 02.04.2012 03:13, schrieb Stephan Wolff: ad name-Tags: da gibt es ein soll: http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route_direction.2Fvariant Das widerspricht http://wiki.openstreetmap.org/wiki/Names Name is the name only The names should be restricted to the name of the item in question only and should not include categories, types, addresses or notes. Any addition information should be included in separate tags to identify its meaning. Bei vielen Relationen ist nicht erkennbar, ob zwei Haltestellen vom selben Bus angefahren werden oder ob sie zu zwei alternativ bedienten Teilstrecken gehören. Wenn es alternativ bediente Teilstrecken sind, dann sollte man die Relation in 2 aufspalten. Das Problem vieler Streckenvarianten derselben Linie wurde oft diskutiert aber nie gelöst. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
