Re: [Talk-de] ÖPNV-Relationen
Hi! Habe nun etwas herum probiert und muss feststellen, dass der Fehler wo anders liegt. Was habe ich gemacht: * Diesen Weg am nordwestlichen Ende kurz vor der Kreuzung gesplittet: http://www.openstreetmap.org/browse/way/32231837 . Zwei zusätzliche Tags drauf und hochgeladen. * JOSM musste 63 Elemente hochladen - dies dauerte eine mittlere Ewigkeit dafür und endete mit einem Konflikt. * Konflikt: Hochladen fehlgeschlagen, da der Server eine neuere Version von einem Ihrer Punkte, Linien oder Relationen hat. Der Konflikt wird durch ein Objekt vom Typ Relation mit ID 2.513.035 ausgelöst. Der Server hat Version 2, Ihre Version ist 1. Ein Blick in der Relationschronik zeigt, dass Version 2 gerade eben von mir selbst erzeugt wurde: http://www.openstreetmap.org/browse/relation/2513035/history Hier liegt das grundlegende Problem: das ist ein Konflikt mit mir selbst, den es so nicht geben darf. Nun wählte ich Ganzen Datensatz synchronisieren. Es wurden 48 Konflikte entdeckt, alle ausschließlich in Relationen, darunter auch eine Abbiegebeschränkung mit drei Members. Im Konfliktlösungsdialog wird ein Member auf beiden Seiten (Meine Version/Deren Version) rot markiert, die Liste ist aber soweit ich das beurteilen kann identisch. Alle 48 Konflikte wurden gelöst in dem ich immer Deren Version verwendete. Ein weiterer Hochladeversuch war dann erfolgreich, allerdings sind die Daten nun korrupt: dieser Weg ist doppelt http://www.openstreetmap.org/browse/way/206492740 und http://www.openstreetmap.org/browse/way/206490629 und die Relationen sind gleichmäßig über beide Wege verteilt. Ich werde versuche diese Stelle wieder zu bereinigen und dann ein Ticket bei JOSM aufmachen. vg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
Hi! Habe nun etwas herum probiert und muss feststellen, dass der Fehler wo anders liegt. Was habe ich gemacht: [...] Hier liegt das grundlegende Problem: das ist ein Konflikt mit mir selbst, den es so nicht geben darf. Danke für das detaillierte Recherchieren. Die gedoppelte Relation ist allerdings in der Tat ein JOSM-Bug. Vielleicht sollte man eine Operation Wege teilen auf der Main API implementieren. Das würde nebenbei auch die Qualität der Daten-Historie verbessern. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
Am 20. Februar 2013 21:27 schrieb Stefan Tiran stefan.ti...@student.tugraz.at: Für mich als Öffi-Benutzer ist es schon sehr interessant zu wissen, ob ein Bus die Autobahn verwendet oder nicht, da sich das deutlich auf die Reisegeschwindigkeit auswirkt. Leider ist es so, dass im ländlichen Raum fast jeder Kurs einer Linie einen abweichenden Verlauf hat. Das ist aber für mich nur viel mehr noch ein Grund dafür, warum es wichtig ist, dass diese Daten in freier Form verfügbar sind. Ich kann das immer noch nicht so ganz verstehen: Woher kommen denn eigentlich die Infos, wo der Bus lang faehrt? Die Fahrplane die ich so kenne geben nur Haltestellen an, der Weg dazwischen wird nur schematisch dargestellt. Klar kann ich den Weg mappen, den der Bus HEUTE genommen hat. Das wird sicher auch sehr oft zutreffen. Aber darauf verlassen kann ich mich doch sowieso nicht. Der Weg kann sich sowohl kurzfristig aendern (Stau, Baustelle, persoenliche Vorliebe des Fahrers), als auch ohne Ankuendigung langfristig (Routenanederung, Neukalkulation wg. Spritpreisen etc.), da ja in den Plaenen der Weg eben NICHT angegeben wird. Genauso widersinnig ist es aber im entgegengesetzten Fall: Strassenbahnen koenen zwischen zwei Haltestellen selten mehr als einen Weg waehlen. trozdem sind die Schienen in der Routenrelation erfasst. Wozu? Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
Am 21. Februar 2013 11:31 schrieb Ronnie Soak chaoschaos0...@googlemail.com: Ich kann das immer noch nicht so ganz verstehen: Woher kommen denn eigentlich die Infos, wo der Bus lang faehrt? von Leuten, die den Bus kennen, bzw. schon benutzt haben und wissen, welchen Weg er nimmt. Die Fahrplane die ich so kenne geben nur Haltestellen an, der Weg dazwischen wird nur schematisch dargestellt. ist aber in der Regel festgelegt, das entscheidet soweit ich weiss nicht der Busfahrer, wie er genau zur Haltestelle kommt. Klar kann ich den Weg mappen, den der Bus HEUTE genommen hat. Das wird sicher auch sehr oft zutreffen. Aber darauf verlassen kann ich mich doch sowieso nicht. Der Weg kann sich sowohl kurzfristig aendern (Stau, Baustelle, persoenliche Vorliebe des Fahrers), m.E. kommt nur Baustelle in Betracht, der Fahrer darf AFAIK normalerweise die Route nicht ändern, und auch ein spontaner Stau wird normalerweise nciht zu einer Routenänderung führen. als auch ohne Ankuendigung langfristig (Routenanederung, Neukalkulation wg. Spritpreisen etc.), da ja in den Plaenen der Weg eben NICHT angegeben wird. das wiederum kann man mit Ortskenntnis lösen (indem man bemerkt, dass der Bus jetzt anders fährt, ggf. auch den Busfahrer fragen, ob das dauerhaft ist). Genauso widersinnig ist es aber im entgegengesetzten Fall: Strassenbahnen koenen zwischen zwei Haltestellen selten mehr als einen Weg waehlen. trozdem sind die Schienen in der Routenrelation erfasst. Wozu? Vereinfachung für Auswerter der Daten, ggf. auch Redundanz zur Sicherung der Datenstabilität (zumindest irgendwas bleibt noch in der db und hilft beim Rekonstruieren falls mal durch Vandalismus oder Anfänger ein paar Haltestellen gelöscht werden oder so). [Immer ausser] selten ist ausserdem nicht ausreichend sicher m.E. um sich darauf zu verlassen ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
Am 21. Februar 2013 09:25 schrieb Martin Vonwald imagic@gmail.com: Habe nun etwas herum probiert und muss feststellen, dass der Fehler wo anders liegt. Was habe ich gemacht: * Diesen Weg am nordwestlichen Ende kurz vor der Kreuzung gesplittet: http://www.openstreetmap.org/browse/way/32231837 . Zwei zusätzliche Tags drauf und hochgeladen. * JOSM musste 63 Elemente hochladen - dies dauerte eine mittlere Ewigkeit dafür und endete mit einem Konflikt. ist ggf. die Internetverbindung in der Zwischenzeit getrennt worden? Das vermute ich z.T. als Ursache für Konflikte, die ich gelegentlich mit mir selbst hatte. Wenn diese komischen Nachrichten kommen (alles oder nur den problematischen Teil synchronisieren?) habe ich bisher noch keine zufrieden stellende Lösung gefunden, beides sorgt endlos für Kettenkonflikte. Hier gibt es z.B. ein Ticket dazu (vielleicht nicht ganz derselbe Fall?): https://josm.openstreetmap.de/ticket/7416 Hier liegt das grundlegende Problem: das ist ein Konflikt mit mir selbst, den es so nicht geben darf. +1 (dürfte) Alle 48 Konflikte wurden gelöst in dem ich immer Deren Version verwendete. Ein weiterer Hochladeversuch war dann erfolgreich, allerdings sind die Daten nun korrupt: dieser Weg ist doppelt +1, auch schon so beobachtet, nehme normalerweise auch immer deren Version in der Hoffnung, dadurch nichts von anderen zu zerstören. _Ein_ Weg doppelt ist noch harmlos ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
Hi. Ich sehe mehrere Gründe, warum man die Wege/Straßen selbst sinnvollerweise mit in die ÖPNV-Relationen aufnehmen sollte. Ich gebe euch aber auch recht, dass das momentane Schema der Relationen und vor allem der riesenrelationen in bestimmten Fällen problematisch ist, dazu ganz unten mehr. Am 21.02.2013 11:31, schrieb Ronnie Soak: Am 20. Februar 2013 21:27 schrieb Stefan Tiran stefan.ti...@student.tugraz.at: Für mich als Öffi-Benutzer ist es schon sehr interessant zu wissen, ob ein Bus die Autobahn verwendet oder nicht, da sich das deutlich auf die Reisegeschwindigkeit auswirkt. Leider ist es so, dass im ländlichen Raum fast jeder Kurs einer Linie einen abweichenden Verlauf hat. Das ist aber für mich nur viel mehr noch ein Grund dafür, warum es wichtig ist, dass diese Daten in freier Form verfügbar sind. Ich kann das immer noch nicht so ganz verstehen: Woher kommen denn eigentlich die Infos, wo der Bus lang faehrt? Variante 1: Ich setze mich in den Bus und fahre mit, ggf mit laufendem GPS-Logger. Variante 2: Ich sehe die Busse von außen und kann damit einzelne Streckenabschnitte eindeutig zuordnen (wegen StVO bleibt oft nichts anderes übrig, zumindest in der Stadt) Variante 3: Der Nahverkehrsverband rückt die Daten in ausreichend freier Form raus. Die Fahrplane die ich so kenne geben nur Haltestellen an, der Weg dazwischen wird nur schematisch dargestellt. Klar kann ich den Weg mappen, den der Bus HEUTE genommen hat. Das wird sicher auch sehr oft zutreffen. Aber darauf verlassen kann ich mich doch sowieso nicht. Der Weg kann sich sowohl kurzfristig aendern (Stau, Baustelle, persoenliche Vorliebe des Fahrers), Innerstädtischer Busverkehr wird meines Wissens nicht wegen Staus umgeleitet normalerweise, zumal Bushaltestellen bei sinnvoller Einrichtung innerstädtisch so nah beieinanderliegen, dass die Stauumfahrung bei nennenswerten Staus auch nicht viel bringt. Bei Baustellen hast du vermutlich recht, aber da gilt, was fürs Routing in OSM auch gilt: Wenn die Baustelle sehr lange besteht, wird entsprechend angepasst, wenn sie kurzfristig ist, sind die Daten eben nicht aktuell und perfekt - das ist aber kein ÖPNV-Problem. Ob Fahrer tatsächlich die Freiheit haben, sich ihre Strecke auszusuchen, weiß ich nicht; da müsste man vermutlich mal Profis fragen. Hier (Kreise Paderborn und Höxter) hab ich das als sehr regelmäßiger Busfahrer aber noch nie erlebt, dass Busse unterschiedliche Strecken je nach Fahrer nehmen (okay, den einen Busfahrer ausgenommen, der gepennt hat und falsch abgebogen ist; der hat aber auch deutlich geflucht, als er auf der Landstraße wenden musste...). als auch ohne Ankuendigung langfristig (Routenanederung, Neukalkulation wg. Spritpreisen etc.), da ja in den Plaenen der Weg eben NICHT angegeben wird. Und die man dann eben genauso nachtragen muss wie man den ursprünglichen Streckenverlauf. Genauso widersinnig ist es aber im entgegengesetzten Fall: Strassenbahnen koenen zwischen zwei Haltestellen selten mehr als einen Weg waehlen. trozdem sind die Schienen in der Routenrelation erfasst. Wozu? Zunächst mal zu der Frage, wozu man die Strecke selbst über die Haltepunkte hinaus in die Routen mit aufnehmen sollte: i) Busse gerade im ländlichen Raum halten nicht an jeder Ecke. In manchen Fällen bieten die Verkehrsunternehmen als Service in den Abend- und Nachtstunden an, dass Busse auch zwischen Haltestellen auf Anfrage halten. Im Padersprinter in Paderborn halten Busse ab 20 Uhr maximal einmal zwischen zwei Haltestellen [1]. Dafür ist es aber notwendig zu wissen, welche Strecke der Bus nimmt. ii) Wie lange ein Bus fährt, lässt sich außerdem, solange keine Fahrpläne bekannt sind, grob anhand von Streckenlänge und -verlauf abschätzen. iii) Liniennetzpläne sind entweder schematisiert (dabei wären die Straßen unnötig) oder aber auf der echten Karte abgebildet, was nur mit den Wegen machbar ist. Die andere Frage ist die der technischen Umsetzung: Wir haben in OSM momentan nur atomar zu bearbeitende Objekttypen: Das gleichzeitige bearbeiten einer Relation ist dadurch unmöglich und führt technisch bedingt zu Konflikten, selbst wenn es sich um die A7 handelt und die beiden Bearbeiter in völlig unterschiedlichen Gegenden Kleinigkeiten korrigieren, ohne die Attribute anzutasten. Bisher wird das Problem oft mit den gruseligen Master-Relationen umgangen, so dass eine Relation eben nicht mehr die A7 enthält, sondern die A7 in Hessen, A7 in NRW und sowas. Ich könnte mir hier vorstellen, dass auf Dauer das Versionierungsschema angepasst werden könnte, indem man Bearbeitungen differenziert betrachtet: - Änderungen an Attributen sind immer eine volle neue Version des gesamten Objekts und führen mit allen anderen Änderungen des Objekts zu Konflikten. - Hinzufügungen/Löschungen von Elementen aus einer Relation bzw. Nodes aus einem Way beziehen sich jeweils nur auf einen Teilabschnitt des Objekts, also z.B. nur den Bereich zwischen bus_stop Bahnhof und
Re: [Talk-de] ÖPNV-Relationen
Am 21. Februar 2013 12:21 schrieb Peter Wendorff wendo...@uni-paderborn.de: i) Busse gerade im ländlichen Raum halten nicht an jeder Ecke. Das ist ortsspezifisch. Hier halten die Überland-Busse eigentlich schon an fast jeder Ecke, auch zwischen Ortschaften, alle paar hundert Meter bis alle paar km gibt es Bushaltestellen (meistens nur ein Schild, kein Häuschen, keine Bank, ...) als sog. Bedarfshaltestellen, d.h. wenn dort jemand steht und winkt oder aussteigen will hält der Bus, sonst nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
Ich kenne hier in Belgien 2 Linien (selbe Strecke) die frei wahlen dürfen wie die erste 20 Kilometer von Leuven nach Aarschot zu gehen (305 und 306). Wenn sie dabei Haltestellen vorbeifahren würden, werden sie nicht halten. Ich habe die in OSM eingetragen über die meist übliche Route (Autobahn). Das ist eher Ausnahme. Polyglot 2013/2/21 Martin Koppenhoefer dieterdre...@gmail.com Am 21. Februar 2013 12:21 schrieb Peter Wendorff wendo...@uni-paderborn.de: i) Busse gerade im ländlichen Raum halten nicht an jeder Ecke. Das ist ortsspezifisch. Hier halten die Überland-Busse eigentlich schon an fast jeder Ecke, auch zwischen Ortschaften, alle paar hundert Meter bis alle paar km gibt es Bushaltestellen (meistens nur ein Schild, kein Häuschen, keine Bank, ...) als sog. Bedarfshaltestellen, d.h. wenn dort jemand steht und winkt oder aussteigen will hält der Bus, sonst nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
Servus, sicher, dass das Problem von den ÖPNV-Relationen stammte? Das wundert mich doch, dass in Graz Umgebung gerade so viel aktiv sein sollen. Rein aus der Betrachtung des ways hätte ich eher die beiden Europastraßen- und die Südautobahn im Verdacht. Speziell erstere sind ja dank dem tag: int_ref = E 59;E 66 irgendwie überflüssig? LG Jimmy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
Was ich schon oft gesagt habe ist das es mehr Sinn machen würde es so zu machen: http://www.openstreetmap.org/browse/relation/2336780/history Leider wird es dann nicht gerendert. Vielleicht in 10 oder 20 Jahre. Das Beispiel ist natürlich nicht komplett. Da sollte alle anderen Linien auch die Teilrelationen benutzen. Polyglot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
Hi, Viele Autobahnen haben eine eigene Relation und E-Relationen. Das Problem in dieser extremen Form kenne ich aber ausschließlich von der A2 und nur auf dem Abschnitt wo die ÖPNV-Relationen sind. In Bereichen wo es diese Relationen nicht gibt ist die A2 wie jede andere Autobahn. Generell brauchen wir eine Lösung für solche Relationen. Egal wofür sie verwendet werden. Es werden hier künstliche Wege erzeugt von Hunderten Kilometern Länge. Und wenn irgendwo auf diesen Hunderten Kilometern zwei Mapper einen Weg teilen haben sie einen Konflikt. Mit steigender Anzahl der Relationen und deren Länge wird das Problem gravierender. Im Moment ist es vielleicht nur die A2. Nur die Relationen werden nicht weniger. Wir brauchen etwas praktikables bevor uns dieses Problem auf den Kopf fällt. Vg, Martin Am 20.02.2013 um 18:15 schrieb Jimmy_K jimm...@gmx.at: Servus, sicher, dass das Problem von den ÖPNV-Relationen stammte? Das wundert mich doch, dass in Graz Umgebung gerade so viel aktiv sein sollen. Rein aus der Betrachtung des ways hätte ich eher die beiden Europastraßen- und die Südautobahn im Verdacht. Speziell erstere sind ja dank dem tag: int_ref = E 59;E 66 irgendwie überflüssig? LG Jimmy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
Servus, da hast du natürlich Recht. Da finde ich den Vorschlag von Polyglot, der mir neu ist: (http://www.openstreetmap.org/browse/relation/2336780/history) besonders für Autobahnen gut geeignet. Von einer Auffahrt bis zu nächsten Abfahrt eine Relation aus allen Wegen dazwischen und diese wird dann in alle Elternrelationen (egal ob Europastraße, Buslinie, Straßenbezeichnung) eingetragen. Im Stadtgebiet hätte sie noch den Wartungsnachteil, dass wenn ein Bus verlegt wird und z.B.: eine Straße früher abbiegt, kann es recht wartungsintensiv werden. Aber das müssen wir noch abwägen. LG Jimmy Am 20.02.2013 18:52, schrieb Martin Vonwald (imagic): Hi, Viele Autobahnen haben eine eigene Relation und E-Relationen. Das Problem in dieser extremen Form kenne ich aber ausschließlich von der A2 und nur auf dem Abschnitt wo die ÖPNV-Relationen sind. In Bereichen wo es diese Relationen nicht gibt ist die A2 wie jede andere Autobahn. Generell brauchen wir eine Lösung für solche Relationen. Egal wofür sie verwendet werden. Es werden hier künstliche Wege erzeugt von Hunderten Kilometern Länge. Und wenn irgendwo auf diesen Hunderten Kilometern zwei Mapper einen Weg teilen haben sie einen Konflikt. Mit steigender Anzahl der Relationen und deren Länge wird das Problem gravierender. Im Moment ist es vielleicht nur die A2. Nur die Relationen werden nicht weniger. Wir brauchen etwas praktikables bevor uns dieses Problem auf den Kopf fällt. Vg, Martin Am 20.02.2013 um 18:15 schrieb Jimmy_K jimm...@gmx.at: Servus, sicher, dass das Problem von den ÖPNV-Relationen stammte? Das wundert mich doch, dass in Graz Umgebung gerade so viel aktiv sein sollen. Rein aus der Betrachtung des ways hätte ich eher die beiden Europastraßen- und die Südautobahn im Verdacht. Speziell erstere sind ja dank dem tag: int_ref = E 59;E 66 irgendwie überflüssig? LG Jimmy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
Hi, Wir sollten sobald wie möglich eine Lösung für ÖPNV-Relationen finden, denn sowas kann auf Dauer nicht funktionieren: http://www.openstreetmap.org/browse/way/102155261 Im konkreten Fall ist praktisch eine komplette Autobahn kaum zu editieren. Nur als Beispiele von heute: * Eine 30 Sekunden Editoraktion (vorher Daten aktualisiert) führte zu 43 Konflikten und mehr als 30 Minuten Aufräumaktion mit weiteren hunderten Konflikten. * Ein Knoten markieren - Daten aktualisieren - Sofort P drücken zum aufteilen - Sofort hochladen (weniger als 1 Sekunde nach derhttp://overpass-turbo.eu/ Aktualisierung) - 29 Konflikte Wo genau hat es den Konflikt gegeben? Auf dem Server? Im JOSM-Validator? Aus der Historie sehe ich jetzt erst einmal nicht den Hergang. Gerade beim Editieren in Köln hat es keine Probleme gegeben. JOSM passt normalerweise die Relationen beim Teilen von Wegen automatisch an. Und eigentlich können Konflikte nur auftauchen, wenn die Relation zwischenzeitlich von jemand anderem geändert worden ist oder ein Mitglied der Relation als Element gelöscht worden ist, aber nicht als Member der Relation. Insofern wäre es wichtig zu wissen, wo eogentlich die Konflikte aufgetreten sind. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
Am 20. Februar 2013 16:23 schrieb Martin Vonwald imagic@gmail.com: Hi! Wir sollten sobald wie möglich eine Lösung für ÖPNV-Relationen finden, denn sowas kann auf Dauer nicht funktionieren: http://www.openstreetmap.org/browse/way/102155261 Im konkreten Fall ist praktisch eine komplette Autobahn kaum zu editieren. Nur als Beispiele von heute: * Eine 30 Sekunden Editoraktion (vorher Daten aktualisiert) führte zu 43 Konflikten und mehr als 30 Minuten Aufräumaktion mit weiteren hunderten Konflikten. * Ein Knoten markieren - Daten aktualisieren - Sofort P drücken zum aufteilen - Sofort hochladen (weniger als 1 Sekunde nach der Aktualisierung) - 29 Konflikte das riecht mehr nach einem Bug in JOSM als nach echten Konflikten, oder läuft bei Euch sonst gerade was Aussergewöhnliches? Derart viele Konflikte innerhalb von Sekunden sind kaum plausibel angesichts der aktuellen aktiven Mapperzahlen. Den Mappern möchte ich hier gar keinen Vorwurf machen, denn hier ist mEn das Schema ein Problem. Warum muss man jeden Meter eines Fahrplanes (gehört sowas überhaupt in eine Geo-DB?) in eine Relation stecken? Warum reichen nicht Haltestellen und einzelne Zwischenpunkte? es geht ja nicht um den Fahrplan sondern um eine Route (lineares Element). Einzelne Punkte sind nicht dasselbe (da muss man die genaue Strecke raten, zumindest nach einiger Zeit, weil wer Straßen ergänzt dann nicht mal mehr sieht, welche Routen da laufen). Ich vermute damit würden unsere Routen noch kaputter gehen als mit den linearen Relationen. Wie gesagt, meine Vermutung (sofern nicht jemand gerade ausgerechnet in der Zeit als Du gemappt hast, an diesen Routen rumgemacht hat), dass da was anderes kaputt sein könnte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
als Lösung könnte man sich vielleicht so was wie ein Blockierfunktion für Relationen vorstellen (über die API), wo man sich für eine begrenzte Zeit ein exklusives Editierrecht für eine Relation sichert und andere User in der Zeit nichts an der Relation ändern können. Bei sehr vielen Usern auf kleinem Raum wird so was vielleicht mal nötig, um Frustrationen durch Konflikte beim Hochladen vorzubeugen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
Martin Vonwald wrote: Hi! Wir sollten sobald wie möglich eine Lösung für ÖPNV-Relationen finden, denn sowas kann auf Dauer nicht funktionieren: http://www.openstreetmap.org/browse/way/102155261 Im konkreten Fall ist praktisch eine komplette Autobahn kaum zu editieren. Nur als Beispiele von heute: * Eine 30 Sekunden Editoraktion (vorher Daten aktualisiert) führte zu 43 Konflikten und mehr als 30 Minuten Aufräumaktion mit weiteren hunderten Konflikten. * Ein Knoten markieren - Daten aktualisieren - Sofort P drücken zum aufteilen - Sofort hochladen (weniger als 1 Sekunde nach der Aktualisierung) - 29 Konflikte Das führt kaum zu einer Erhöhung der Datenqualität dafür aber des Blutdruckes. Ich kann Deinen Frust verstehen, sehe die Probleme aber eindeutig nicht in den ÖPNV-Relationen. Grundsätzlich ist es klar, dass je detailierter die Informationen in der Openstreetmap werden, desto schwieriger das Editieren ist. Natürlich sollten die Editoren so schlau wie möglich vorgehen. Warum bei Konflikten so viel Benutzer-Interaktion nötig ist, ist wirklich nicht einzusehen. Ich finde man sollte da eher am JOSM ansetzen, dass dieser die Merges automatisch hinbekommt. Den Mappern möchte ich hier gar keinen Vorwurf machen, denn hier ist mEn das Schema ein Problem. Warum muss man jeden Meter eines Fahrplanes (gehört sowas überhaupt in eine Geo-DB?) in eine Relation stecken? Warum reichen nicht Haltestellen und einzelne Zwischenpunkte? Für mich als Öffi-Benutzer ist es schon sehr interessant zu wissen, ob ein Bus die Autobahn verwendet oder nicht, da sich das deutlich auf die Reisegeschwindigkeit auswirkt. Leider ist es so, dass im ländlichen Raum fast jeder Kurs einer Linie einen abweichenden Verlauf hat. Das ist aber für mich nur viel mehr noch ein Grund dafür, warum es wichtig ist, dass diese Daten in freier Form verfügbar sind. Liebe Grüße, Stefan ___ 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 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
