Ja des ist dann schon eine Gefahr… dahingehend… ist die jetzige Relation mit allen Teilen robuster… Aber vielleicht zum erstellen einer Relation? Das mir das Routing-Programm… Eine Relation ausgibt…
Bis jetzt kann man mit einem Routing-Programm mir das anzeigen lassen… kann mir ein GPX downloaden… welches im Josm anhängen kann… usw. ist schon hilfreich…
Was ein Routing-Programm besser kann… alle Tags zu beachten… Einbahnstr. irgendwelche Beschränkungen usw. usw. Abbiegebeschränkungen usw… Wer überblickt das schon alles beim erstellen einer Route?
Aber hier würde es schon gut funktionieren… auch wenn noch eine Bushaltestelle auf dem Weg fehlt…
Ich denke, niemand sollte Einbahnstraßen etc. beim Anlegen einer Busroute berücksichtigen! Man sollte einfach nur das mappen, was man festgestellt hat.
Ja. Der Verstoß gegen die Verkehrsregeln ist ein wertvoller Hinweis. Vermutlich ist bei der Straße was falsch gemappt worden und man kann es korrigieren.
Ich verstehe nicht wie du Buslinien einträgst… bzw. herausfindest wie der Bus wo fährt? Fährst du mit dem z.B. Bus von Anfang bis Ende und dann wieder mit diesen wieder zurück bis zum Anfang? Und dann das ganze mit jeder Variante die diese Buslinie hat dann das gleiche noch einmal? Mir erschliesst sich deine Arbeitweise dabei jetzt nicht ganz? Wenn ich mit jeder Buslinie und Variante die ich schon eingetragen habe fahren müsste… dann wüsste ich was ich das nächste halbe Jahr mache… und wäre viel Geld los
Ich mach es so gut es geht, ohne mit den ganzen Bussen zu fahren… und auch vervollständigen… reparieren usw. fehlende ergänzen. Mach etliche Fehler/Hinweise… sollte was nicht stimmen kann man es ja korrigieren… aber der Anfang ist schon gemacht und der macht am meisten Arbeit Ob jetzt der Bus die eine oder eventuell andere Straße nimmt ist eigentlich fast egal… Hauptsache er hällt an der nächsten Haltestelle
Ist im Sinne von OSM ;). Hab da mal gehört… alles was sich vor Ort überprüfen lässt kann man OSM hinzufügen. Da der Fahrplan vor Ort öffentlich aushängt und von jedermann überprüft werden kann… passt also…
Da hier im Thread auch mein damaliger PTv3-Entwurf diskutiert wurde:
Es gibt einen neuen … die Segmente sind komplett wieder rausgeflogen und vieles wurde umbenannt. Siehe http://gafte.de
-Erstellung von Netzplänen: Gibt es etwa bei der Rheinbahn
-Generieren von Services wie dem DB-Zugradar, bei denen die exakte Route bekannt sein muss.
-ÖPNV-Router, die den Weg zur platform (bei einem platform-way bis auf Höhe der entsprechenden stop-position) genau anzeigen und damit auch etwa Umsteigezeiten berechnen können.
-Abfahrtsmonitore wie Öffi könnten bei korrekten Daten die stop_areas auf einer Interaktiven Karte zeigen, ein Klick auf eine stop_area führt zu einem Abfahrtsmonitor, und wenn man dann auf eine Abfahrt klickt wird mittels der online hinterlegten Echtzeit-Halteposition die position der entsprechenden stop_position auf einer Karte angezeit.
Wie du siehst ist vieles denkbar und dank PTv2 auch machbar, man muss nur die Daten korrekt erfassen. Dass der entsprechende Aufwand sogar wirtschaftlich sein kann zeigen Unternehmen wie Menz, die immer mehr Kunden betreuen.
Dass es OSM-Daten allerdings auch in die internen Abläufe bei Verkehrsunternehmen schaffen wage ich jedoch sehr zu bezweifeln, dafür sind unsere Daten leider viel zu vandalismusanfällig und damit unzuverlässig. Für die Kundeninformation sind sie jedoch sehr gut geeignet.
Ich glaube noch nicht mal das Vandalismus das entscheidende Problem wäre. Dem kann man begegnen, in dem man beim Fahrplanwechsel eine Review der Daten macht und diese dann für den eigenen Gebrauch einfriert, bzw Änderungen nur übernimmt wenn diese überprüft wurden.
Ich glaube aber für solche Zwecke ist unser Datenformat nicht geeignet. Verkehrsunternehmen brauchen auch Angaben wie Fahrzeugumläuf, Ruhezeiten usw. Wir sollten uns auf die Fahrgastaspekte konzentrieren.
Da liegt die Zukunft. Bisher arbeiten die Verkehrsunternehmen in der Regel mit statischen Umsteigematritzen. Das macht das Routing sehr unfexibel und erlaubt auch nicht, dem Kunden exakte Umsteigewege anzuzeigen. Das Interesse ist groß.
Das ist mancherorts schon Gegenwart. Dabei werden hier im VRR die Haltestellen als Nodes in einer Datenbank des Verkehrsunternehmens gespeichert und zwischen den Nodes wird Fußwegrouting auf OSM-Daten gemacht. D.H. also lustigerweise, dass für den ÖPNV OSM-Daten genutzt werden, soweit es keine ÖPNV-Daten sind.
Je nach Qualität der einzelnen Nodes in der Nodedatenbank des Verkehrsunternehmens ist die Qualität unterschiedlich. Wir könnten evtl. durch unsere linienförmigen und flächenförmigen Steige bei Bahnen bessere Ergebnisse erzielen, da ein einzelner Node bei einem Bahnsteig mit mehreren Abgängen schlechte Abstände liefert…
Das ist mir schon klar. Ich meine, dass bisher z.B. kein Bahnsteig zu Bahnsteig Routing gemacht wird, das geht momentan nur mit statischen Matritzen mit statischen Umsteigezeiten. Würde man auch hier die OSM daten nutzen um zu ermitteln welche Umsteigebeziegungen möglich sind, wäre das sehr viel flexibler.
Ich haben ihn mir durchgelesen und finde ihn recht interessant, verstehe aber glaube ich nicht alles. Ich werde aber mal Feedback geben aber da immer nur einzelne Aspekte herausgreifen, da mir das sonst zu viel auf einmal wird. In diesem Fall PIOs:
Wenn ich das richtig verstanden habe, lösen PIOs u.a. das Problem, das Wartebereich und Platform nicht identisch sein müssen. PIOs markieren quasi die Grenze zwischen Fussgänger (Rollstuhl oder was auch immer) und ÖPNV-Routing richtig? Das halte ich für einen recht pragmatischen, nützlichen und intelligenten Ansatz. Hab da noch Fragen:
Lösen PIOs das Problem, dass es ggf unterschiedliche Bahnsteige zum Ein- und Ausstieg gibt und daher der PIO in beide Richtungen unterschiedlich sein müsste?
Wurde die wachsende Rolle des Bedarfsverkehrs berücksichtigt? Kann man so etwas wie “Einstieg nur nach Anmeldung 30min im Voraus” abbilden?
Was für real existierende Probleme lösen die PIOs noch?
Ja. Wobei auch mal noch ein ganzes Stück zwischen PIO und Verkehrsmittel liegen kann. Z.B. wäre bei der Fähre Kiel-Göteborg der PIO im Gebäude von Stena Line, denn da muss man als Fußgänger hin – da ist die Kontrollschleuse. Das Schiff fährt aber ein ganzes Stück entfernt ab. Dazwischen liegt ein langer Gang, der dann nicht erfasst ist. Aber in dem Gang gibt es auch keine Möglichkeit, sich zu verlaufen.
Nein. Aber man könnte die Rollen “pio-in” und “pio-out” dazunehmen. Über das “+” kann man ja beliebig viele Einzelangaben zu einem Halt machen. Man kann das Problem bei Autos (als Fährpassagiere) auch über oneway lösen … aber das geht bei Fußgängern vermutlich nicht.
Nein. Jedenfalls habe ich keine Idee, wie man das mit vertretbarem Aufwand da reinbekommen kann. Das muss wohl über Fahrplanangaben gemacht werden.
Konflikte mit dem Mapping physischer Objekte. Ich kenne einige gute Mapper, die keinen Nerv mehr haben auch nur eine Bushaltestelle anzulegen.
PIOs sind nie physisch. Es ist immer klar, dass man für einen Bahnsteig railway=platform und für einen physisch vorhandenen Bussteig highway=platform oder highway=pedestrian oder was-weiss-ich nehmen muss. Man kann das nie durch ptv3_object=pio ersetzen. Dadurch kann man auch mehrere PIOs auf einem Bahnsteig haben. In Mainz Hbf gäbe es z.B. auf dem physischen Bahnsteig an den Gleisen 4 und 5 die PIOs 4a, 4b, 4, 5a, 5b und 5. In Duisburg Hbf gäbe es z.B. einen PIO für die relativ zum Bahnsteig sehr kurzen Doppelstockzüge. Damit käme man für das Umsteigen vom Zug in die U-Bahn auf realistische 300m … vom Bahnsteig zur U-Bahn sind es dagegen nur 30m. (Die Zahlen sind grobe Schätzungen. Die genauen Zuglängen und Haltepositionen hab ich nicht.)
So ein Reviev dürfte zu viel Aufwand bei einer zu hohen Fehlerwarscheinlichkeit darstellen.
Fahrzeugümläufe etc. wären mit OSM problemlos errechenbar, wenn die Infrastruktur komplett erfasst ist. Die derzeitigen Programme, die so etwas berechnen, basieren auf deutlich rudimentärerern Daten, die nur die Entfernungen, Höchstgeschwindigkeiten, Signalpositionen, Haltepositionen und Steigungen beinhalten. Mehr braucht man dafür auch Infrastrukturseitig nicht und bis auf die Steigungsdaten sind unsere Daten in einigen Regionen schon sehr nahe an dem, was tatsächlich gebraucht wird. Dazu kommen natürlich dann noch die Fahrzeugeigenschaften wie der Beschleunigungswert und die Bremshundertstel. Aber das hat ja mit OSM nichts zu tun.
Aus den Daten wird dann erst mal die reine Fahrzeit berechnet und daraus kann man dann die notwendige Wendezeit ableiten. In einem späteren Schritt wird dann meist erst die Schichtplanung erstellt.
Aber ich bin da ganz deiner Meinung, dass wir uns besser auf die Fahrgastinformation fokussieren sollten, zumal die Reiseauskünfte in den wenigsten Fällen direkt vom Betreiber ausgegeben werden. Das ist eigentlich nur noch im eigenwirtschaftlichen Verkehr der Fall. Im Regionalverkehr kommen die Infos meist von den Verbünden, für die es auch ein nicht unerheblicher Aufwand sein kann die notwendigen Informationen zusammen zu tragen und dann alle auf ein Format zu bringen. Da kann OSM schon eine sehr gute Stütze sein.
Nicht umsonst sind die Verbünde mit die ersten kommerziellen Akteure gewesen, die nicht nur für das erstellen eines normalen OSM-Routers sehr tief in die OSM-Materie eingestiegen sind. Die meisten anderen kommerziellen Anwendungen von OSM beschränken sich auf das verwenden vom Mapnik als Hintergrundbild, manchmal werden noch kleinere Sachen gemacht wie die Auslesung der highway=motorway ways, um damit eine Echtzeit-Verkehrskarte zu erstellen, wie etwa beim WDR.
Für das Problem “Wie komme ich zum Verkehrsmittel” ist das ausreichend. Das Problem “Wie viel Zeit brauche ich zum Umsteigen?” bzw. “Wann muss ich da sein?” lässt sich damit aber ggf. nicht ohne externes Zusatzwissen lösen oder? Oder müsste dass dann schon in den Reisezeiten und Abfahrts- und Ankunftszeiten mit drin sein?
Ich frage mich auch wie das ist, wenn sich die Wege nach dem Wartebereich noch aufteilen können wie beim Flughafen. Was wäre dann der PIO? Was ist mit Systemen wie der TGV in Frankreich, bei denen es gar keine festen Bahnsteigzuordnungen gibt, sondern diese dynamisch disponiert werden? Aber vielleicht ist das sogar einfacher, das ist mir gerade nicht ganz klar.
Das würde wohl gehen. Ich denke da an Systeme wie die sog. “Spanische Lösung” z.B. rechts einsteigen links aussteigen. Ist bei vielen Metrosystemen weltweit recht verbreitet und sollte daher funktionieren.
OK, da werde ich mir noch gedanken machen. Das ist wohl auch für die linien relevant, da werde ich vielleicht später noch etwas zu sagen.
Wären dass dann Nodes, Ways oder Flächen? Die würden dann immer zusätzlich zu vorhandenem physischer Objekten angelegt? Wenn ein PIO “4a” heißt, wie erfolgt dann die Zuordnung zu Mainz Hbf?
Wenn man die Daten ohnehin schon hat ist das natürlich erst mal ein großer Zusatzaufwand. Letztendlich müssen die Daten aber ohnehin einmal richtig erfasst und auf Fehler überprüft werden. Danach nur noch die Änderungen. Beim erfassen macht man sich noch zu nutze, dass die Community da viel kostenlose Vorarbeit geleistet hat. Gibt sogar Feuerwehreinsatzkarten auf OSM Basis: https://www.youtube.com/watch?v=1__IjaP1EY8. Da werden solche Verfahren beschrieben.
also lieber gegen Verkehrsregeln verstoßen…
Wenn ich mit jeder Buslinie und Variante die ich schon eingetragen habe fahren müsste… dann wüsste ich was ich das nächste halbe Jahr mache… und wäre viel Geld los 
Ob jetzt der Bus die eine oder eventuell andere Straße nimmt ist eigentlich fast egal… Hauptsache er hällt an der nächsten Haltestelle 