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
Wenn ich den Fahrweg der Buslinie nicht kenne, würde ich ihn auch nicht taggen.
Außerdem müßte man sich Gedanken über die Datenquelle machen, ist Abschreiben von Fahrplänen im Sinne von OSM?
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
Also ich hätte folgende Use-Cases:
-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.
Grüße
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.
Grüße
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.
Ich denke, dass es bei solchen Gatesystemen immer Vorschriften gibt, wann man spätestens vor Abfahrt auftauchen muss. Ist man erstmal durch wird man auch mitgenommen und die Weglänge spielt keine Rolle.
Ich fürchte, dass man diese Vorlaufzeiten nicht mal sicher im Fahrplan findet. Ich meine mich zu erinnern, dass man bei den Fahrten mit der Fähre ab Göteborg je nach Wochentag und Saisonablauf verschiedene Zeiten hatte und erst ein oder zwei Tage vorher per Internet oder Telefon was genaues dazu erfahren hat.
Die verschiedenen möglichen Bahnsteige werden mit der “alt-pio”-Rolle angegeben. Die alternativen Gleise im Bahnhof werden dabei ignoriert.
Das gilt aber nur, wenn es eine lokal auf den Bahnhof beschränkte Variation ist. Wenn die Züge ab Gleis 4 z.B. immer schon in A-Dorf statt in B-Dorf enden, dann ist es eine echte Variante und damit eine eigene Relation.
Ich hab das mal von Japan gehört. Da war auch die Rede von versetzten Türen, so dass die ein- und aussteigenden Massen sich gegenseitig garnicht behindern.
Ich denke auch, dass es rein sollte. Eigentlich müsste es ja “pi” und “po” statt “pio-in” und “pio-out” heißen, aber ich glaube dann flippt die Mehrheit aus 
Ja
Ich würde in dem Fall Linien nehmen.
Auf jeden Fall ist das ptv3_object=pio an sich nichts physisches. Normalerweise bekommt ein mit anderen Tags beschriebenes physisches Objekt zusätzlich ein ptv3_object=pio. Wo es sinnvoll ist, legt man statt dessen neue Datensätze mit ptv3_object=pio an. Es kann auch mal vorkommen, dass da physisch absolut nichts ist und es trotzdem eine Bushaltestelle ist; dann hat man eben nur einen Datensatz mit ptv3_object=pio.
Das wäre “ptv3_name=Mainz Hbf” und “ptv3_number=4a”.
(“ptv3_name” darf anders als “name” Abkürzungen enthalten und gibt die Beschriftung der Schilder wörtlich und ohne Steignummern wieder. Dann hat auch der Kollege aus Japan eine Chance, rechtzeitig auszusteigen.)
Da Pio nicht gerade eine intuitiv verständlich ist, könnten wir statt “pio”, “pio-in” und “pio-out” auch einfach die Rollen “inout”, “in” und “out” verwenden.
Die spanische Lösung (beidseitige Bahnsteige) gibt es übrigens auch im Münchner S-Bahn-Tunnel.
Sofern auf einem Gleis mehr als eine Linie verkehrt, wird man aber keine reine “in” und “out” Aufteilung haben, sondern mindestens eine Seite wird eine eingeschränkte inout Funktion für Umsteiger haben. Welche das ist, wird durch die Anordnungen zum Aussteigen bestimmt.
Vielleicht könnten da Rollen wie “in+change” und “out+change” helfen.
Wir sollten den Spezialfall flughafenartiger Gates von dem Pio Konzept separieren, zumal es auch wenn solche Gates vorhanden sind, oft zusätzlich eine nachgeschalteten fahrzeugnahen Wartepunkt gibt und ggf. auch der Ausstieg ggf. nicht über das Gate erfolgt.
Wir können das Gate entweder statisch per spezieller Relation den fahrwegnahen Pios zuordnen oder es zusätzlich in die Linienrelation aufnehmen. In letzterem Fall sollte es durch z.B. eine “gate”-Rolle und/oder entsprechende Tags am Gate-Objekt von sonstigen Pios unterschieden werden.