PTv3: Zielsetzung eines modifizierten ÖPNV Modells

Hiermit möchte ich zu einer Überarbeitung des Public Transport Tagging Standards aufrufen und zunächst die Zielsetzung zur Disskussion stellen. Konkrete Lösungsansätze beabsichtige ich, in separaten Threads zur Diskussion zu stellen, um die Diskussionen übersichtlich zu halten. Public Transport ist so komplex, dass eine Gesamtdiskussion aufgrund der Unübersichtlichkeit wohl ohnehin zu keinem konkreten Ergebnis führen kann.

Als wesentliche Ziele eines neuen Public Transport Tagging Standards (PTv3) sehe ich:

  • Zugänglichkeit für eine breite Mapperbasis
    Einerseits, weil iD für die Routenbearbeitung funktional ungeeignet ist, und andererseits, weil auch mit JOSM im Wesentlichen nur Experten zur Bearbeitung von Public Transport Bearbeitung fähig sind, ist derzeit die Mehrheit der Mepper von der Public Transport Bearbeitung weitgehend ausgeschlossen. Der Zustand des ÖPNV Mappings leidet darunter natürlich erheblich. Wir können nicht davon ausgehen, dass überall importierbare Daten der Verkehrsnetze zur Verfügung stehen, die dann von PT Experten nur noch eingepflegt werden müssen, sondern gerade in ländlichen Regionen sind wir auf das Wissen jedes lokalen Mappers auch für den ÖPNV angewiesen.

    Zweifellos muss iD erweitert werden, um PT sinnvoll editieren zu können. Allerdings erscheint es mir auch nicht als Lösung, einen JOSM-artigen Relationseditor in iD anzubieten. Dem typischen iD Nutzer wird dieser ebensowenig eine PT Bearbeitung ermöglichen wie dies derzeit bei der Mehrheit der JOSM Nutzer der Fall ist. Experten wird man unter den iD-Nutzern kaum finden.

    PTv2 hat den Kardinalfehler, dass es für ein manuelles Mapping im Relationseditor optimiert ist und nicht optimiert ist, um einen intuitiv bedienbaren PT-Editor zu ermöglichen. Es sind oft Kleinigkeiten im PTv2, die eine intuitive Editiermöglichkeit verhindern.

    Ein PTv3 ist meines Erachtens nur sinnvoll, wenn es eine derartige intuitive Editiermöglichlichkeit ermöglicht und eine solche in iD auch integriert wird. Sofern wir den Maintainer von iD von der Notwendigkeit eines solchen PT-Editors in iD überzeugen können, bin ich auch gern dazu bereit, durch Pull Requests dazu beizutragen.

  • Verbesserung der Auswertbarkeit
    Für die Motivation der Mapper ist es wichtig, dass die Daten auch in tatsächlichen Anwendungen genutzt werden. PTv2 macht es aber sehr schwer, da sich die Anwendung auf fast nichts verlasen kann. Vieles ist nur optional. Auch das Rendering ist ein Problem. Teilweise gemappte Daten führen bei PTv2 zu Fehlinterpretationen. Beisielsweise gaukeln fehlende Haltestellen in einer Route einen nicht-vorhandenen Expressverkehr vor. Wir können nicht erwarten, dass ein Mapper komplette Routen beitragen kann.

    Dies ist also auch ein Feld, wo ein PTv3 nachbessern sollte.

  • Funktionale Verbesserungen
    PTv2 funktioniert nicht bei geteilten Bahnsteigen (z.B. teilweise auf Brücke oder in Tunnel) oder bei beidseitigen Bahnsteigen (spanische Lösung).

  • Effizienteres Mapping
    Derzeit ist ÖPNV-Mapping und insbesondere dessen Wartung sehr zeitaufwendig, so dass auch hier Verbesserungen anzustreben sind.

  • Wartbarkeit von Highway und Railway
    Insbesondere durch die Vielzahl generierter Varianten Relationen wird die Wartbarkeit der Wege bei PTv2 stark eingeschränkt. Hier ist anzustreben die Anzahl der Relationen an dem jeweiligen Weg zu reduzieren und diese Relationen einfacher reparierbar zu machen.

  • Durchsetzbarkeit
    PTv2 hat das Mapping gegenüber PTv1 für viele Anwendungsfälle deutlich erschwert, was mit zur schleppenden Durchsetzung von PTv2 beigetragen haben dürfte. Dies sollten wir beim PTv3 vermeiden.

    Auch müssen wir vermeiden, dass Dinge mit PTv3 nicht mehr darstellbar sind, da dies eine Umstellung vorhandener Daten verhindern und somit die Durchsetzung von PTv3 beeinträchtigen würde.

    Ein PTv3, dass sich nur sehr langsam durchsetzt, würde alles nur verkomplizieren anstatt zu vereinfachen.

    Es ist also wichtig, keine Durchsetzungshindernisse zu schaffen, und der Vorteil von PTv3 muss groß genug sein, damit die Umstellung zügig erfolgt.

Schwebt dir da denn schon etwas vor? Ein stumpfes completion= tag wäre, finde ich, eine schlechte Lösung. Aber wie soll ein System sonst erkennen dass eine Route so wie sie erfasst ist vollständig oder nicht ist?
Ein Gedankengang von mir wäre jetzt vielleicht ein Parameter stop_count= welchen man mit der Anzahl erfasster Stops abgleichen könnte…

Gegenüber ptv1 wo alles in die selbe Relation geknüllt wurde sind hier aber wenigstens die Inhalte der einzelnen Routenrelationen relativ übersichtlich. Ich schätze mal du denkst da “wieder” an ein Segmentansatz, aber das könnte im schlimmsten Fall auch wieder beliebig kleinteilig werden.

Dem ist nur zuzustimmen.

Ich würde gern zwei Punkte der Ziele noch konkretisieren wollen:

  • Diesen Punkt finde ich richtig. Ich erlebe in meinem Mappinggebiet (Berlin, Brandenburg und Mecklenburg-Vorpommern) auf einigen Routen eine Vermischung verschiedener Mapping- und Taggingansätze. Ich würde mir (aufgrund meiner Erfahrung vor allem mit Regionalbahnen), wünschen, dass sich eine mögliche Umstellung auf ein (potentielles neues) Schema weitgehend automatisieren lässt, alles Andere bindet knappe Ressourcen und verzögert Änderungen um Jahre.

  • Was diesen Punkt betrifft, sind mit vor Allem die »Metadaten« der PTv2-Relationen ein Dorn im Auge: Momentan ist es so, dass z.B. der Verkehrsverbund in jeder Einzelrelation (nach PTv2-Definition sollen das mindestens zwei sein) und zusätzlich in der Masterrelation gespeichert werden. Ich habe noch keinen Fall gesehen, wo diese Daten in der Realität verschieden sind (Einspruch erwünscht…). Bei Änderungen wird aber manchmal nur eine Relation geändert und es kommt zu einem Widerspruch (Bsp: RE4 Lübeck - Szczecin Główny: https://www.openstreetmap.org/relation/2609914).
    Dieser Hinweis trifft genauso auf die Tags »ref«, »ref:Verkehrsverbund«, »operator«, color und »service« zu.
    Ich kenne einen Sonderfall, bei dem verschiedene Linienrelationen der selben Linie von verschiedenen Unternehmen bedient wurden (existiert nicht mehr), aber von dem Einzelfall abgesehen, war das bisher für mich nur zusätzlicher Aufwand und eine möglichst zu vermeidende Fehlerquelle.

Abgesehen davon sehe ich relativ wenige Optimierungsmöglichkeiten: Es gibt eine große Vielzahl von Spezialfällen im ÖPNV (die Spanische Lösung wurde schon angesprochen, ansonsten gibt es noch Ringlinien, die nur in einer Richtung bedient werden, saisonale Verbindungen, wechselnde Bahnsteige), die sich momentan nur schwer modellieren lassen. Jeder Sonderfall hat das Potential, eine Relationenstruktur weiter zu vergrößern (etwa durch das Hinzufügen eines zusätzlichen Tags), was als kompliziert wahrgenommen wird.

Ich halte einen Editor für ÖPNV-Mapping für unumgänglich (Gedankengang: Ist die Datenstruktur schon komplex, so soll es zumindest einen einfachen Zugang für Mapper geben). Daran schließt sich natürlich auch ein Validator an, welcher alle Merkmale des Schemas überprüft…

Da habe ich schon recht konkrete Vorstellungen. Der Ausgangspunkt sind Überlegungen, wie ein einfach zu bedienendes User-Interface aussehen kann. Wenn der User z.B. eine Bushaltestelle im Editor selektiert hat, sollte er er eine Buslinie hinzufügen können. Zumeist wird man von dem User erwarten können, dass er jeweils aus einem Drop-Down-Menü die vorangegangene oder nachfolgende Haltestelle auswählen kann, damit der Editor die neu hinzugefügte Haltestelle passend in die Relation einbauen kann. Der User muss aber auch die Möglichkeit haben anzugeben, dass ihm dieses unbekannt ist, dass es keine deratige Haltestelle gibt (am Linienanfang bzw. Ende), oder diese Haltestelle noch in der Route fehlt. In letzterem Fall sollte der User um die Angabe der entspechenden Haltestelle nach der Lücke gebeten werden, um die Route passend sortieren zu können.
Die getroffenen Auswahlen müssen natürlich im Editor visualisiert werden und jederzeit nachträglich korrigierbar sein.

Technisch kann diese Information gespeichert werden, indem z.B. der stop Rolle eine Endung mit einem Statuspaar bezogen auf den Vorgänger und Nachfolger hinzugefügt wird.
Beispiele:
stop:gap|none ist der letzte Halt der Linie und davor ist eine Lücke.
stop:ok|ok ist eine innere Haltestelle in der Linie, die in diesem Bereich vollständig und korrekt sortiert ist
stop:unknown|ok ist bezüglich des Vorgängers möglicherweise noch nicht korrekt in die Relation eingeordnet.

Wir können nicht davon ausgehen, dass der Mapper Wissen über die gesamte Linie hat, und somit die Haltestellenanzahl kennt. Weiterhin fehlt dabei natürlich die Information, wo die Probleme liegen.

Da stimme ich zu, zumal wir auch hier wieder einen Mapper mit Gesamtwissen über die Linie bräuchten, um beurteilen zu können, dass alles komplett ist.

Abgesehend davon, dass ich den Ansatz begrüße, möchte ich hier nur folgendes kurz einwerfen (auch nicht zum ersten Mal in diesem Forum):

  • Ein komplexes System kann nicht auf eine beliebig simple User-Schnittstelle heruntergebrochen werden. Ich beziehe mich damit auf “… ist derzeit die Mehrheit der Mepper von der Public Transport Bearbeitung weitgehend ausgeschlossen.”. Ob es jetzt die Mehrheit ist oder nicht … geschenkt … je komplexer die Daten, desto weniger Leute können sie bearbeiten. Das ist so, und das wird so bleiben. Man kann nicht alles für jeden editierbar machen. Viel wichtiger ist es, versehentlichen Beschädigungen vorzubeugen – wie auch immer.
    Ich sehe auch das Problem, dass eine geringe Anzahl an Bearbeitern auch wenig Fortschritt bedeutet. Daher sollte die Anzahl so hoch wie möglich sein. Ich will nur vor dem Ziel eines “Volks-Editors” warnen, den auch Oma Erna bedienen kann.

  • Du hast schon über das Interface hinaus gedacht und überlegt, wie ermittelte Daten abgelegt werden. Das ist sehr wichtig, denn sonst bastelt man eine tolle Oberfläche und stellt dann bei der Implementierung fest, dass man nicht weiß, wohin mit den Informationen. Daneben wäre es aber auch sinnvoll, bei verschiedenen Editoren ein einheitliches Interface bzw. einen einheitlichen Editor bereitzustellen. Bei JOSM wäre es Java-basiert, bei iD weiß ich es nicht.

  • Ich persönlich finde PTv2 nicht so schlecht, soweit ich es selbst genutzt habe. Es ist ziemlich klar und strukturiert für “normale” Gegebenheiten einsetzbar, denke ich. Allerdings kenne ich die vielen Sonderfälle natürlich nicht, die damit nicht abzubilden sind. Einige Diskussionen bezüglich dieser Sonderfälle fand ich jedoch auch etwas weit hergeholt, muss ich zugeben. Mit ein bisschen gutem Willen, ließe sich einiges mehr darstellen als auf den ersten Blick erkennbar, glaube ich. Das soll jetzt kein Plädoyer für PTv2 sein, aber den Blick auf ggf. wiederverwendbare Ansätze freihalten.

  • Der ÖPNV ist kein deutsches Konstrukt. Ein PTv3 muss genauso im Rest von Europa und im Rest der Welt funktionieren. Auch im Sinne der Akzeptanz sollte man das früh genug mit berücksichtigen und ggf. Leute fragen, die die Gegebenheiten vor Ort kennen. Ich denke da z.B. an die New Yorker Metro, die ein paar Besonderheiten aufweist, die mir in Deutschland zumindest noch nicht begegnet sind. Auch bei den Fahrzeugklassen muss man aufpassen, dass man alles erwischt bis hin zur Pferdekutsche, wenn nötig.
    Dieses Forum kann also für eine Vorarbeit sicher gut genutzt werden, zumal es sonst auf der Welt offenbar niemand gibt, der sich massiv um das Thema kümmert (was noch nachzuweisen wäre – quasi wie bei Patentideen). Irgendwann sollte sich das dann aber auf internationale Wikis oder Foren “ausbreiten” (wenn es einen robusten Stand erreicht hat).

Na dann ... auf in den Kampf ;) Es lohnt sich.

Ich sehe PTV2 als viel zu Aufwändig, nicht Wartbar an. Alle Routenvarianten zu erfassen wird in keinsterweise gemacht… das funktioniert vielleicht in Ballungsräumen noch z.B. München. In Ballungsräumen gibt es aber nicht so viele Varianten… in den Landkreisen um München sieht es aber dann schon wieder sehr dürftig aus. Es findet sich auch kaum jemand der zu dem Thema Interesse hat, und zweimal schon nicht die PTV2 konform zu machen… und nachzuhalten.

Ich selbst habe auch das Interesse daran verloren, da ich mit manchen Edits die nach mir gemacht wurden unzufrieden bin. Kreisverkehre aufzutrennen oder Linien an stop-positionen aufzuteilen weil hier die Linie endet…usw. manches Tagging usw. finde ich kontraproduktiv und will ich nicht fördern. Diese Auswerter können mich mal :stuck_out_tongue: , dann erstelle ich lieber keine Relationen mehr in dieser Richtung.

MfG Miche

Leider erfordert die Bearbeitung der Basisinfrastruktur (highway oder railway) oft temporäre Beschädigungen der Routen. Selbst wenn man da z.B. Warnungen generiert, sind diese wenig hilfreich, wenn der Benutzer mangels Editierbarkeit das Problem nicht beseitigen kann. Die Basisinfrastuktur gegen Bearbeitungen zu sperren, erscheint auch nicht wirklich sinnvoll.

Die Editoren sind konzeptionell zu verschieden. Ein einheitliches Interface für PT wäre da in mindestens einem Editor ein Fremdkörper. iD basiert übrigens auf Java-Script.

Falls etwas bekannt ist, das in PTv2 nicht funktioniert, wäre dies interessant. Funktionale Einschränkungen sollte es in PTv3 gegenüber PTv2 nicht geben, abgesehen vielleicht von der Notwendigkeit, manche Dinge etwas anders zu mappen.

Mein Träume bzgl. PT wären

  1. Dass man eines Tages sowas wie Fahrplankarten auf OSM-Basis erzeugen könnte. Als Druckerzeugnis inzwischen wohl mehr oder weniger im Sande verlaufen. Allenfalls Südlicher Oberrhein aus den Kreisen der Erfinder lebt evtl. noch zaghaft …
    Dazu müsste man auch ein wenig durchschnittliche Fahrzeiten und Taktdichten HVZ/NVZ an den Kanten zwischen den Halten taggen. Und (falls noch nicht gemacht) auch Zugarten (RB/RE bswp.) ausreichend unterscheiden. Komplette Fahrpläne natürlich nicht, aber paar Grunddaten, damit man die unterschiedlichen Liniendicken und groben Fahrzeitangaben malen kann.

  2. Angaben zur Barrierefreiheit: Bahnsteighöhen *) und Fahrzeughöhen bspw. und vermutlich noch einiges mehr.
    Auch damit eines Tages passende Karten entstehen können, wo bspw. ein Farbschema auf einem Blick angibt, wo beides zusammenpasst.

  3. to be continued

*) In Karlsruhe gibt es gelegentlich auch zwei Höhen hintereinander (bspw. KA-Durlach 76 cm für S-Bahn RheinNeckar, 55 cm für die Stadtbahnen, am Gottesauer Platz letzteres vor 34 cm für Niederflurtrams), da ist dann das oben schon erwähnte nötig, dass man Bahnsteige teilen kann.

Hi,

Zunächst sei erst einmal erwähnt, dass ich erst zu PTv2-Zeiten bei OSM eingestiegen bin.

  • Ich finde, es ist am wichtigsten, dass PTv3 endlich klarheit bezüglich der zu verwendenen Schlüssel schafft. Dass PTv2 quasi parrallel zu PTv1 gebaut wurde hat sicherlich sehr viel zur allgemeinen Verwirrung beigetragen.

  • Es ist sicherlich keine verkehrte Idee, Schlüssel wie public_transport beizubehalten, aber hier sollte es bei der Einführung vermieden werden, auf die alten PTv2 und 1 zu verweisen. Es muss ganz klar sein, dass es ab dem Zeitpunkt nur noch PTv3 gibt und nichts anderes. Auch ist es sehr wichtig, alle relevanten Renderer von anfang an im Boot zu haben. Diese sollten in einer Übergangsfrist beide Schematas unterstützen, aber nach maximal 6-12 Monaten darf es keinen Renderer mehr geben, der PTv3 nicht unterstützt.

Zum Konkreten:
  • Bezüglich der Dopplung von PTv1 und 2 bin ich persönlich der Meinung, dass diejenigen Schlüssel, die durch den public_transport - Schlüssel derzeit gedoppelt werden, ersatzlos wegfallen müssen. Das betrifft im Wesentlichen highway=bus_stop;platform und railway=stop:platform. Diese Schlüssel werden de facto nicht mehr benötigt, um eine Haltestelleninfrastruktur ausreichend zu beschreiben. Ich weiß, dass das vor allem den orm-Mappern wehtun wird, aber eben dafür wurden ja genau Schlüssel wie train=yes eingeführt.

  • Um den Railwaymappern entgegen zu kommen schlage ich folgenden neuen Schlüssel vor: platform=railway, um die Widmung als Eisenbahninfrastruktur zweifelsfrei zu kennzeichnen. In einigen Fällen kann es nämlich vorkommen, dass an einem Vollbahn-gewidmeten Bahnsteig auch oder ausschließlich Stadt-oder Straßenbahnfahrzeuge halten. Dieser Schlüssel darf dann aber ausschließlich bei gewidmeten Vollbahnen verwendet werden.

  • Der Status des Schlüssels light_rail muss endlich endgültig geklärt werden! Es kann nicht sein, dass hier in Deutschland immer noch an einigen Stellen ein Sonderweg gefahren wird, nur, weil der Schlüssel damals bei der Dokumentation vergessen wurde.

  • Es muss ein Tool für JOSM und andere Editoren zu Handhabung von PT-Relationen her. Dieses Muss können: Haltestellen sortieren und hinzufügen und den Linienweg bearbeiten. Dabei sollte ein Befehl auch auf mehrer Relationen gleizeitig oder nacheinander ohne erneutes Auswählen der zu ändernden Relationselemente ausfürhbar sein können, um bei einem ganzen Linienbündel gleichzeitig den Linienweg verlegen zu können. Auch sollte das Tool mit doppelten Relationselementen umgehen können, derzeit ein sehr großer nachteil vom JOSM-Editor, der bei solchen Fällen manchmal abenteuerliche Leistungen hinlegt.

  • Es sollte überlegt werden, ob man nicht Relationen als Teil des Linienwegs zulässt. Damit ließen sich gebündelte Linienführungen deutlich einfacher pflegen. Diese neuen Relationen beinhalten ihrerseits den konkreten Fahrweg in der richigen Reihenfolge. Der Nachteil davon ist, dass man somit eine weitere Hürde für Neueinsteiger setzt, aber im Gegenzug wird der Wartungsaufwand erheblich gesenkt, was wiederum auch die Hürde wieder senken kann. Vor allem in Städten mit Bussen als Rückrat des ÖPNV dauert es teilweise eine halbe Ewigkeit, bis man eine einfache Änderung der Hauptachse erfasst hat, vor allem, wenn vorher ünereifrige Mapper für jede einzelne mögliche Endstation eigene Linienrelationen angelegt haben (was wiederum über einfaches Kopieren der Relation sehr einfach ist).

Viele Grüße,
hsimpson

highway=bus_stop ist einer der ältesten Tags. Den kann man nicht “wegfallen lassen”. Der wird auch noch in zehn Jahren benutzt werden, weil es zig User gibt, die nach ihrer Anfängerzeit nie wieder in ein Wiki schauen oder in Foren/Mailing-Listen was von neueren Entwicklungen mitbekommen. OSM ist ein weltweites Projekt, und wenn hier in D genug ÖPNV-Mapper da sind, um irgendwelche hochkomplizierten PTvX-Schemen umzusetzen, sieht das schon in Polen ganz anders aus… da kann man froh sein, wenn abseits der Großstädte bus_stop da ist. Und ob jemand, der in Afrika rendert, mitbekommt, dass Haltestellen in D mit bus_stop nicht zu finden sind? Bitte immer schön die Abwärtskompatibilität beachten!

Sry, aber das kann kein Grund sein! Mit der Begründung könnte man jede Neuerung im Keim ersticken und man müsste auf alle Ewigkeiten mit den jetzigen Tags leben!

Übrigens bin ich grade darum der Meinung, dass man von Anfang an alle relevanten Renderer im Boot haben muss. Erst, wenn auch dem letzten auffält, dass highway=bus_stop nicht mehr auf der Karte vorkommt, wird er vieleicht merken, dass sich etwas getan hat!

Und dein letztes Argument mit der Komplexität ist ja eben genau das, worum es sich hier drehen soll: Wie kann man mehr Mapper überhaupt in die Lage versetzen, mit ausreichender Sicherheit ein ÖPNV-System zu pflegen? Wenn PTv1 darauf eine Lösung wäre und das dann auch noch den Anforderungen der Vielseitigkeit des Öffentlichen Verkehrs genügen würde, würden wir diese Diskussion hier gar nicht führen. Aber so fahren wir hier grade zwei Systeme parrallel, was defninitiv keine Dauerlösung darstellen kann (es aber schon viel zu lange ist).

Grüße

Ich habe übrigens noch zwei weitere Probleme, für die man eine Lösung finden sollte:

  • Es gibt immer mehr Anruftaxen, die von einer bestimmten Haltestelle ein ganzes Bendiengebiet erschließen. Ein Beispiel dafür sind die Anruf-Sammel-Taxen in Köln: https://www.kvb.koeln/service/ast_und_taxibus.html Solche Fälle können bisher gar nicht erfasst werden.

  • Es gibt Fälle, in denen der Überlandbus über die Umgehungsstraße fährt, außer jemand drückt voher an der Haltestelle im Dorf eine Taste. Damit wird ein Signal vor der Abfahrt zum Dorf geschaltet, welches dem Busfahrer signalisiert, dass dort Fahrgäste warten. Nach meiner Kenntnis wird dieses System in Skandinavien bereits eingesetzt, allerdings weiß ich nicht genau wo.

Viele Grüße

Das tun wir doch garnicht. PTv2 sollte die Routenrelationen aus PTv1 ablösen und das ist passiert. Es gibt fast keine PTv1-Routen mehr. Das Haltestellenmapping sollte niemals abgelöst werden. Es sollte nur ergänzbar werden und das ist passiert.

Leider wird auch da ergänzt, wo es sachlich garnicht nötig ist, weil es dieses unausrottbare falsche Gerücht gibt, dass highway=bus_stop durch PTv2 abgelöst wurde und die ganze Welt mit public_transport=* zugeschüttet werden muss.

Ist das so? Ich habe in den randgebieten des AVVs oft mit Routenrelationen zu tun die zwar kein PTv1 sind aber näher an PTv1 als an PTv2 in dem Sinne, dass es z.B. nur eine Rountenrelation für alle Fahrvarianten gibt.

Ich hab auch genügend gemacht pro Fahrrichtung… Relationen aber mit alles Varianten… oder einzelne Varianten aber nicht alle… oder alles in einer… mir wäre nicht bekannt das sich da mal die Mühe gemacht hätte diese auf PTV2 zu ändern…

Ich hab immer noch >50 Hinweise platziert… wo noch Bushaltestellen komplett fehlen… welche erst vor Ort aufgenommen werden müssen. Also da stimme ich zu das wir da zu “durch PTV2 abgelöst” noch sehr weit entfernt sind.

Auf dem Land sind Bushaltestellen bisher so gut wie gar nicht gemappt, da braucht man ans Public-Transport-Mapping noch gar nicht zu denken. Noch dazu sind die Fahrpläne dort eine einzige Katastrophe nur weil man der Meinung ist, die Schulbusse müssten auch für “Auswärtige” zugänglich sein und damit im Fahrplan eingetragen werden.

Wer ein “Schreckensbeispiel” sehen will: bitteschön. Versuch das mal jemand in PTv2 darzustellen.

Ich sehe das Konzept der Routeneintragung als überholt an. Es müllt die Datenbank zu… und erschweit die Bearbeitung. :confused: Man könnte heute die Route durch eine Routingsoftware berechnen lassen mit wenigen Wegpunkten… und z.B. als GPX ablegen und diese bei Bedarf neu berechnen.

M.E. wäre es sehr wichtig, die Bushaltestellen mit dem Link zum Onlinefahrplan zu versehen - heute meist als qr-Code mit angegeben. Dort sind dann auch Routenänderungen automatisch - z.B. bei Baustellen - mit enthalten.

http://www.openstreetmap.org/node/3740880925
Hier ist z.B. noch nicht die Routenänderung der Linie C - bisher Bannewitz - jetzt Bahnhof Hainsberg enthalten. Könnte also als description:de und auch als Relation (Route) entfallen, da über

http://www.vvo-online.de/de/fahrplan/aktuelle-abfahrten-ankuenfte/abfahrten?stopid=33001141

ersichtlich, wohin und wann ein Bus fährt.

Bei uns musst man teilweise “Schulbus” nutzen um in die “Dörfer” zu kommen.

Ja. Es gibt eine Menge Probleme. Aber diese Probleme kommen nicht daher, dass PTv2 bei der Ablösung von PTv1 nicht brutal genug war.

Ich weiß natürlich nicht, was die Ziele von PTv3 sind. Für mich stellt sich immer die Frage, welchen Nutzen hat das Ganze. Ich war gestern beim Wandern in einer fremden Gegend und habe auf der OSM-Karte eine Bushaltestelle gesucht und glücklicherweise gefunden. Auf der Karte habe ich dann auch gesehen, auf welcher Straßenseite die Haltestelle ist und damit auch in welche Richtung der Bus fährt und dies wohl deshalb, weil das von vielen verpönte “highway=bus_stop” vorhanden war. Der Mapper-Kollege hat hier einfach nicht gegen den Renderer gearbeitet und ihm die Chance gegeben, die Haltestelle auf der Karte darzustellen. Ich fordere also, dass ich auf der Karte erkennen kann, wo eine Bushaltestelle ist und auch auf welcher Straßenseite. Wie dies umgesetzt wird, ist mir egal. Der Renderer muss jedenfalls eine Möglichkeit habe, dies darstellen zu können.