Ja, es wäre genauso gut gewesen, wenn es im PTv2 anders herum gestanden hätte. Aber jetzt ist es so und das hat Folgen.
Jetzt darf z.B. ein Programm zum Extrahieren der Haltestellen den Rest der Relation überspringen wenn der erste Fahrweg-Eintrag kommt. Das zu tun ist sogar sinnvoll, denn in PBF-Dateien ist das Überspringen sehr zeitsparend. Viele Programme bei OSM laufen täglich und da ist es ein riesiger Unterschied, oft sie 2 Stunden oder 20 Stunden brauchen.
Es kann auch Edit-Wars geben, weil verschiedene Mapper sich auf verschiedene Quellen berufen.
Wenn ein Mapper entscheidet, dass er abgekürzte Varianten nicht eintragen will, dann ist das völlig OK. Auch wenn viele Mapper das tun, ist es völlig OK.
Ein Problem ist es aber, das zu verbieten. Nach PTv2 darf und soll man es. Wenn ein Mapper sieht, dass eine Variante fehlt und sie einträgt (richtig nach PTv2) und ein anderer löscht sie, weil es so in dem Papier steht, dann haben wir einen Edit-War. Und da muss man klar sagen: solange PTv2 dran steht ist das Eintragen des ersten Mappers richtig und das Löschen durch den zweiten falsch.
Nein. Beispiel: Ein Bahnhof “Pusemuckel” hat 4 Bahnsteige (1 bis 4). Auf der einen Seite ist ein Busbahnhof “Pusemuckel Bahnhof” mit 8 Bussteigen (1 bis 8). Auf der anderen Seite ist ein Busbahnhof “Pusemuckel Bahnhof/Westseite” mit 3 Bussteigen (1 bis 3).
-Nach PTv2BE sind es 15 Stop-Areas und ? stop_area_groups.
-Nach PTv2 sind es 3 Stop_Areas.
-Nach meinem Vorschlag sind es drei Stop-Areas und eine Stop_Area-Group.
Wenn eine zweite Platform da ist, dann darf ein Mapper sie auch in einer Route benutzen. (Er darf nicht beide Platforms benutzen, das wären dann zwei Halte und falsch.) Jetzt kann man aber an der einzelnen Platform eventuell nicht mehr alle Routen erkennen, weil einige auf der anderen Platform liegen.
Man kann nicht vorhersehen wie die Datenbank benutzt wird. Deshalb sollten die Sachen stimmen – egal ob man einem ein Problem mit falschen Einträgen einfällt oder nicht.
M.E. ist das meist wichtige dass es bequem ist für Mapper um die zu überarbeiten. Es gibt nicht viele Mapper die sich am PT interessieren, für die Wenige die es gibt muss es so angenähm wie möglich sein. Ein Komputerprogramma würde ich nie so schreiben dass es aufhört mit dem Processing in der Mitte von eine Relation. Es gibt immer die Möglichkeit das ein iD-Benutzer eine HS am Ende hinzugefügt hat, meistens ohne es sich zu realisieren. Die Optimalisazion für Programme sollte darin bestehen die Datenmenge so klein wie möglich zu halten. Das machen wir aber sowieso nicht mit unsere lange Tagnamen und vielfalt duplizierte Daten.
Da hast du Recht. Das ist ein Problem. Wäre es möglich um die Reihenfolge für v3 um zu drehen? Oder ist sowas ausgeschlossen?
Verboten habe ich es ja nicht. Das Skript das die Daten umwandelt, stellt die kurzere Variante von “Teleskoplinien” aber nicht zur Verfügung. Dieses Skript spart Mapper soviel Zeit (weil es nicht mehr notwendig ist, stundenlang Fahrpläne zu bestudieren um aus zu finden welche Variante es gibt. Es wäre wenig sinnvoll nicht gebrauchzumachen von die praktische Lösung. Ich kenne genau 1 Mapper der das vor einige Jahren für 2 Linien gemacht hat. Er hat das aber zeitdem nicht mehr neu gemacht und De Lijn ändert das ständige kleinere oder grossere sachen dran. Desto mehr Varianten wir beschreiben, desto mehr Arbeit der oft nicht gemacht wird.
Nein. Beispiel: Ein Bahnhof “Pusemuckel” hat 4 Bahnsteige (1 bis 4). Auf der einen Seite ist ein Busbahnhof “Pusemuckel Bahnhof” mit 8 Bussteigen (1 bis 8). Auf der anderen Seite ist ein Busbahnhof “Pusemuckel Bahnhof/Westseite” mit 3 Bussteigen (1 bis 3).
Für mich ist es einfacher um das zu illustrieren an Hand Beispiele.
Also habe ich mal Bahnhof in Oostende und Haltestellengruppe Gent Zuid überarbeitet.
(In Oostende ist es eine Ausnahme dass die Gleise vom Tram ihre eigene Sequenz für Numerierung haben. Das ist historisch so gekommen und es wird warscheinlich nicht mehr so sein nachdem das ganze in welche Jahren umgebaut wird zu einem völlig integrierten Bahnhof.)
Wenn man in ein ganzes Land der Regel hat um die Platforme die auf Ways un MPs gemappt sind nicht in die Routerelationen auf zu nehmen, dann ist da keine Verwirrung möglich. Wir sind hier angefangen HS nur auf Nodes zu mappen und es wäre sehr schwierig um das jetzt noch zu ändern. Ich bleibe dabei dass es besser gewesen wäre um diese Nodes nicht public_transport=platform zu vergeben.
Jetzt haben wir Nodes getaggt mit highway=bus_stop, public_transport=platform, bus/tram=yes welche alle Details enthalten.
Und Ways und MPs getaggt mit public_transport=platform, bus/tram=yes, highway/railway=platform, die angeben wo es in der Wirklichkeit Steige (Platforms) gibt.
Etwas verwirrend dass 2x public_transport=platform dafür benutzt wird, aber es ist unproblematisch um die 2 auseinander zu halten.
Das einzige Problem ist denn aber wo Routes über die Grenzen gehen, sowie in Aachen, Breda, Dunkerque. Da wird eine stop_area benötigt um die zu verbinden. Das funkzioniert natürlich nur, wenn es genau 1 stop_area pro HS gibt. Ist es möglich um das so vor zu schlagen für V3?
Die Segmentrouten habe ich jetzt selber auch aufgegeben. Ich entwickle einen Skript dass die Arbeit um die zu Warten/Unterhalten (maintenance) ungeheuer leichter macht. Es ist noch nicht völlig fertig, aber es spart schon viel Zeit.
Der nächsten Schritt ist dann eine Art webservice der angibt wo Wartung benötigt ist.
ausgeschlossen ist bei OSM nichts. Aber die Frage ist ob man die “abwärtskompatibilität” einfach so aufgeben möchte. Die Frage ist welchen Aufwand macht es dein Programm anzupassen? vielleicht kann man mit Version 3 einfach die Position der Haltestellen am “anderen Ende” einfach zu lassen, ohne es explizit zu fordern.
Beim Bus gäbe es nach PTv2 nur eine stop_area mit allen 28 Platforms und allen 14 stop_positions. Alle 42 Elemente und die stop_area hätten “name=Oostende Station”. Der Busbahnhof wäre also eine stop_area und nicht eine stop_area_group mit 14 stop_areas.
Ich weiss. Wenn das aber alles so auf einem Häufen geschmissen wird, kann nicht mehr daraus abgeleitet werden was zueinander gehört. Dann kann man auch einfach keinen stop_area machen und alles geometrisch ableiten (versuchen).
Da ist nichts ausgeschlossen, wir bestimmen das ja alle zusammen.
In meinem Vorschlag ist aber zentral, dass die alten Relationen bleiben bis zumindest die wichtigsten Renderer beides können. Das Problem mit der Reihenfolge bleibt also – egal ob ich das in meinem Vorschlag ändere oder nicht.
Wir können gern darüber diskutieren, was bei PTv2 alles schlecht ist. Aber wenn wir etwas anderes wollen, dann sollten wir es nicht PTv2 nennen. Wenn erstmal viele Mapper die Maße von Objekten in Meter angegeben haben, dann sollte man nicht mehr darüber nachdenken, welche Länge für so einen Meter denn am praktischsten wäre. Man kann über neue und bessere Einheiten reden – aber den Meter darf man nicht alle paar Wochen ändern.
Im Public Transport Schema V2 wird für Routen ein “name”-Tag vorgeschlagen:
name = : =>
Example: Bus 201: Uitikon Waldegg, Bahnhof => Uitikon, Wängi
Dies ist unpassend und sollte verbessert werden, denn
ein solcher Name existiert in der realen Welt nicht und widerspricht somit der Namenskonvention in OSM:
“The names should be restricted to the name of the item in question only and should not include categories, types, descriptions, addresses or notes.”
kollidiert mit dem realen Namen einer Verbindung, sofern dieser existiert
Wie die Comment-Spalte nahelegt (“Prose description of route variant.”) sollte der Text in “description” statt “name” stehen.
V2.1 sollte diesen Designfehler korrigieren.
Sollte dieses “Ungetüm” irgendwo stehen?
Bus => kommt aus dem route
201 => aus dem ref
initial stop => aus dem from
terminal stop => aus dem to
Varianten stecken im via
Ich meinte dieses Ungetüm:
name = : =>
was, wie seawolff für mich richtig meint, nichts mit dem Namen einer Linie zu tun hat.
name wäre für mich z.B. statt “Bus 564 Hanau ⇒ Langen-Bergheim” “Linie 564 Langen-Bergheim”, was wahrscheinlich auch auf dem Bus stehen könnte.
Don’t panic.
Da ist PTv2 noch kürzer: die Linie heißt dort “Bus 564”. Die Linie insgesamt findet man in der route_master-Relation und nicht in den route-Relationen.
Bei den route-Relationen geht es um die Varianten und da ist der Startort genauso ein Unterscheidungsmerkmal wie der Zielort und manchmal müssen sogar Zwischenziele genannt werden. Auf dem Bus muss der Startort natürlich nicht stehen, denn den an einer bestimmten Haltestelle wartenden Passagieren ist die Vergangenheit des Busses ja völlig egal.
Statt “Bus 201: Uitikon Waldegg, Bahnhof => Uitikon, Wängi” würde man auch vermutlich auch eher “Bus 201: Waldegg=>Wängi” schreiben.
Hier werden Busrouten meist als “Linie 201” oder evtl. “Linie 201 Start-Ziel” genannt (sowohl umgangssprachlich wie auch vom Betreiber).
Züge heißen “RB 84” oder vielleicht “RB 84 Lübeck – Kiel”.
Die Konstuktionen “ : => ” sind keine Namen und gehören nicht ins name-Tag.
Als “description” oder “note” sind sie vermutlich unkritisch. Ob man sie überhaupt braucht ist eine andere Frage.
Es sind von Mappern vergebene Varianten-Namen (nicht Liniennamen) und sie werden gebraucht. Sollen wir wirklich die drei Relationen der S2 von Essen, Duisburg und Recklinghausen nach Dortmund alle “S2 Dortmund” nennen? Dann sind die Master-Relationen unlesbar.
Um es nochmal klar zu sagen: es geht nicht um den Namen der Linie. Der ist in PTv2 “Train S2” oder “S2”.
Offiziell heißt sie: 509 Glietz < > Briesensee < > Lübben wobei lediglich die wenigsten der Linien die genannte Verbindung befahren. Das ist aber Standard hier… Die Linien sind so gestrickt, daß ein regelrechter Umlauf eines Busses und Fahrers über mehrere Linien entsteht…
Die Relation enthält alle Varianten des Fahrplans… wenn ich nichts übersehen hab…
Vom Einpflegen in OSM her ein riesen Aufwand…
Ach ja, die Angabe im name-Tag der einzelnen Routen-Variante hilft mir einigermaßen bei den vielen Varianten durchzusehen… sie sind für mich unerläßlich.
Gibt es eigentlich in Deutschland auch Geselschafte die ihre Daten offenbar machen unter Lizenz die in OSM übernommen werden kann, oder die damit einstimmen das die Daten in OSM aufgenommen werden?
Wenn man das von Fahrpläne ableiten muss, ist das tatsächlich ein ungeheuer Aufwand. Speziell weil das alles jetzt von unten aus zerbrochen wird von Mappern und von ‘oben’ aus wird das auch hier und dort manchmal angepasst.
Wenn nicht von die Fahrplänen und nicht von die Quelldaten, wie kann man dann sicher sein alle Varianten sind eingeschlossen? Dann muss man diese Linien allen mal benutzen, mal auf Wochentag, mal am Samstag, mal am Sonntag, Freitagabends, Sonntagabends, Mittwoch zwischen 12 und 2. Mal die erste und die letzte Fahrt, weil die auch manchmal abweichen.
Und wie weiss man denn wenn etwas geändert würde and die Fahrplänen. Oder man musste es jede 3 Monate noch mal neu machen und vergleichen ob es noch stimmt.
Kein Problem mit 1000 Mappern, sondern wir sind froh wenn 1 pro Gegend sich daran interessiert.
Ich habe 2 Jahren mails geschickt an Gesellschaft De Lijn (Flandern) (Nicht jede Woche). Und auf einem Tag haben die dann Zustimmung gegeben um ihre Daten in OSM zu übernehmen. TEC (Wallonien) haben ihre Daten dann nochmal 2 Jahre später völlig freigegeben unter freie Lizenz.
Nur die Gesellschaft in Brüssel antwortet nicht. Vielleicht müsste ich mal auf Französisch versuchen… Man kann die Daten bekommen, aber die sagen: nicht für kommerzielle Benutzung. An Google haben die die schon langst vergeben. Und Google macht da auch eine Art kommerzielle Benutzung.
Es sind mir derzeit keine Unternehmen bekannt, welche das tun. Aber es gibt Verbünde die dies tun bzw. getan haben. Einer der ersten war der VRS welcher die Mapper eingeladen hat und dort GPX Routen bereitgestellt hatte um die Linien zu übernehmen.
Später folgte der VBB, welcher regelmäßig aktualsierte GTFS Daten zur Verfügung stellt. Dabei gibt es die ausdrückliche Genehmigung der Übernahme in OSM. Es fehlt lediglich ein Konzept, wie dies geschehen kann.
Ich hatte einmal begonnen für ein automatisches Einlesen vorzuarbeiten: http://www.openstreetmap.org/relation/3410277#map=16/52.5794/13.5257
Allerdings macht es als Einzelkämpfer nur wenig Spaß. Dazu kommt das die Daten leider nur Haltestellenbereichsscharf sind und man so diverse Spezialfälle leider nicht abdecken kann.
Wenn es dazu neue Ideen gibt, würde ich mich sehr freuen.
Inzwischen gibt es auch weitere Verbünde, die Ihre Daten anbieten. Darunter ist Ulm und der VRN (http://www.vrn.de/vrn/einfach-ankommen/fahrplaene/opendata/index.html) Hier als VDV Format. Auch dabei kann ich gerne bei der Umwandlung behilflich sein. Leider hat es nur mit dem Zuschicken der Daten nicht geklappt.
