PTv3: Zielsetzung eines modifizierten ÖPNV Modells

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.

Was man auch nicht übersehen darf ist die Angabe einer Referenz wie in deinem Beispiel, oder allgemein ref:IFOPT. Damit werden die Daten noch viel nützlicher weil beispielsweise Vergleiche oder Verknüpfungen zu Schnittstellen möglich werden.

Diese Dinge haben aber nicht viel direkt mit PTv* zu tun, es ist allgemein wichtig so etwas zu mappen, hier geht es aber wahrscheinlich eher weniger darum.

Ich hätte ref:IFOPT schon längst bei von mir gemappten Bushaltestellen eingetragen, kenne dafür aber keine Quelle. Gibt es die Nummern überhaupt flächendeckend?

Ich weiß nicht ob es die flächendeckend gibt, ich vermute ja; hier ist eine Übersicht (keine Ahnung ob komplett): https://zhv.wvigmbh.de/

Quellen gibt es viele, welche erlaubten es in deinem Raum gibt weiß ich nicht. In NRW darf man die Inhalte der VRR-EFA in verschiedenen Varianten benutzen.

In der Regel der örtliche Verkehrsverbund. Dieser vergibt die ref entsprechend der DIN EN 28701:2012

Ich habe zumindest bisher nichts mitbekommen, dass sich da ein Verbund aktiv gegen entschieden hätte.

Es gibt sogar einen Eintrag im Wiki dazu: https://wiki.openstreetmap.org/wiki/DE:Key:ref:IFOPT
Die Liste der Verbünde in D ist aber definitiv nicht up to date. In Bayern nutzen Sowohl der VGN als auch der MVV definitiv die IFOTP!

Grüße

Da muss ich dir wiedersprechen. Siehe: https://wiki.openstreetmap.org/wiki/VRS/Analyse Die Schienen-Routen mögen inzwischen meist PTv2 sein, aber bei den Bus-Routen herrscht noch ein wildes durcheinander. Die Analyse haben wir vor kurzem gestartet und bisher war ich alleine mit der Pflege der Relationen, die bereits PTv2 waren, voll ausgelastet.

Eben das halte ich für einen der größten Fehler, da es uns viele Unsicherheiten und spezialdefinitionen beschert hat, die kaum einer wirklich durchblickt und jeder anders interpretiert:

  • Was soll das railway=tram_stop? gilt das auch für light_rail strecken und routen? Oder muss man hier mit railway=station und station=subway arbeiten? Und überhaupt, wieso werden zwei Sytsteme, die beide unter BoStraB laufen, mal nach dem Railwayschema gemappt und mal nicht? Und darf man railway=tram_stop auch sysnonym zu railway=station setzen, wie es tausendfach praktitiziert wird oder nicht? In Düsseldorf hat letztlich wer ne Reihe von tram_stops durch railway=stop ersetzt, da die Haltestellen Teil von oberirdischen Hochflur-Linien waren. Diese sind in dem Bereich aber nur ein besonderer und kein eigenständiger Bahnkörper und daher der Definition nach eine Straßenbahn. Die entsprechenden Kommentare muss ich noch verfassen, da hatte ich bisher keine Zeit zu. In Düsseldorf haben wir übrigens auch die Besonderheit, dass ein und die selbe Linie auf Düsseldorfer Seite an tram_stop und auf Duisurger Seite an station=subway hält…

  • Was passiert, wenn Bus und Tram an einer platform halten, muss man dann ein tram_stop und ein bus_stop setzen, beides in die selbe Node, oder für den bus_stop eine eigene platform-Node, da die Tram einen railway=platform gemalt bekommen hat? Alles schon gesehen! Was passiert, wenn eine light_rail oder tram auf einer EBO-Infrastruktur fährt? In Köln ists derzeit noch die Tram, da die Linien noch nicht auf light_rail umgestellt wurden, weil noch bis vor kurzem einige S-Bahn-Linien als light_rail gemappt waren. Bisher sind die Stationen daher mit tram_stop gemappt, aber rein juristisch gesehen sind das stations und halts.

Die Beibehaltung der alten Tags mag damals vieleicht logisch und sinnvoll erschienen sein, aber wenn wir jetzt eine neue Reform haben wollen, dann sollten wir uns für ein einziges einheitliches und in sich schlüssiges Schema entscheiden, was dazu flexibel genug ist, weitere Neuerungen aufzunehmen. Das Schema sollte vol allem konsequent logisch aufgebaut werden, um Interpretierungsschwierigkeiten von vornherein zu unterbinden! Und das sehe ich bisher nur bei den public_transport Schlüsseln.

Viele Grüße

Der PT_Assistant plugin für JOSM macht schon viel von was du willst. HS sortieren entlang den Fahrtweg ist diesen Sommer hinzugefüft worden.
Hinzufügen von HS am Route aber (noch) nicht. Technisch ist das nicht all zu schwierig. Die manuel hinzufügen ist aber auch nicht so schwierig und nimmt weniger Zeit als falsche Positive löschen.

Gleichzeitig ändern von mehrere Routen ist nicht drinn, weil das relativ “gefährlich” ist. Was wohl drinn ist, ist Unterstutzung om Routen zu reparieren basiert auf andere Routen die schon kontinuerlich sind.

Das Tool kann mit doppelten Elemente umgehen. Obwohl mein Vorschlag für ein PTv3 gerade sein würde HS mit 1 zentrales Element darzustellen. Preferenziell eine Node, der alle Details hat, neben dem Weg dargestellt. Vielleicht brauchen wir ein neues Tag wie:

public_transport=pole
oder
public_transport=passenger_stop
oder
public_transport=passenger_area

oder
public_transport=halt
(ich kann kein besseres Wort finden auf English das nicht ‘stop’ ist)

anstatt
highway=bus_stop (nicht wirklich ein highway)
public_transport=platform (nicht immer ein Platform da)
bus=yes

oder
railway=tram_stop (keine Schiene neben die Schiene wo die Leute stehen)
public_transport=platform
tram=yes

Wenn ein Plattform vorhanden ist, ist es natürlich kein Problem das als Way oder Area dar zu stellen, das soll aber nicht die Details duplizieren und es sollte auch nicht in die Routenrelationen hin. (meine Meinung)

Jedenfalls ist PT_Assistant zo gemacht daß es mit mehrere Mappingstyle umgehen kann und daß es helfen kann bei die Umstellung von v1 auf v2.

Es ist auch fertig für wenn wir einen Tag mal Routesegmente benutzen können, um Linienteile zu bundlen. Das würde die Wartung erleichtern, es würde aber auch die komplexität etwas höher machen. Editor support ist dann sicher notwendig, weil manuell die Kontinuität überprüfen dann nicht mehr möglich sein wird.

Polyglot

PS: es war natürlich immer so gemeint daß public_transport highway=bus_stop und railway=tram_stop ersetzen würde. Nur ist das von die Leute die die Standard Rendering machen nie so ausgeführt. Erst angeblich um technischen Gründe, die letzten Jahre aber weil sie kein added value drin sehen. Ich habe keine Gründe zu glauben daß es ein PTv3 anders vergehen würde. Also machen wir das mit ‘double tagging’. Ich habe es schon einigen Jahren her aufgegeben das zu ändern versuchen. Ein Tag mehr oder weniger ist auch nicht wirklich ein Problem. Details duplizieren, oder mehrere Objekten an Routerelationen hinzufügen müssen, is schlimmer. m.E.

Da wird von nur einer PTv1-Buslinie gesprochen – das sieht für mich nach “fast keine” aus. (Und PTv1-Buslinien sind auch kein Problem, wenn public_transport:version=1 dransteht)

Ja. PTv2 ist zu pflegeintensiv. Insbesondere ist es zu empfindlich gegen eigentlich ganz normale Arbeiten von Mappern, die garnichts am ÖPNV ändern wollen. Das muss in einem PTv3 anders sein. Aber ein Problem des Übergangs von PTv1 nach PTv2 sehe ich da nicht.

Es gibt light_rail-Strecken. Es gibt keine light_rail-Routen. Das steht nur im Proposal, weil jemand nach der Abstimmung den Abstimmungstext gefälscht hat. Das sind Züge und sie haben route=train in PTv2. Es war richtig, dass light_rail da nicht vor kam. Genauso ist es mit route=bus. Das kommt auch dann dahin, wenn diese Buslinie durch Taxen oder Reisebusse oder von mir aus Pferdefuhrwerke bedient wird. Es geht um den Charakter der Linie und nicht um die Beschreibung der Fahrzeuge oder der Betriebsordnung.

railway=station ist der Zentralnode eines Bahnhofs und wird nach den von den Bahnleuten spezifizierten Regeln gepflegt. PTv2 arbeitet nicht mit Zentralnodes und sie kommen nie in PTv2-Relationen vor.(Wenn der Zentralnode auch noch zufällig der stop-Node ist, dann kommt er natürlich in PTv2 vor.)

Auf jeden Fall müssen PTv2-stops in den Fahrweg des betreffenden Verkehrsmittels. Wenn das derselbe way ist, dann sehe ich erstmal keinen Grund, zwei verschiedene Nodes dafür zu nehmen.

Wenn diese Platform von den Busbenutzern benutzt wird, dann muss sie in die Route. Und natürlich darf keine zweite Platform gemappt werden, wenn nur eine da ist.

Finde ich auch. Nur sollte dabei public_transport=* auch abgelöst werden.

Ich sehe da deutlich mehr, viele auch noch komplett ohne public_transport:version=1. Vor allem im Ländlichen Bereich, also bei den Buslinien, die nicht im 100er und 600er Bereich sind.
PTv1-Linien möglen technisch vieleicht kein Problem darstellen, aber alleine ihre Existenz ist eine immense Einstiegshürde für PT-unerfahrene Mapper. Und da schließt sich dann auch der Kreis, denn PTv1-Linien kommen vor allem da vor, wo es eben keine aktiven PT-Mapper gibt.

Was macht man dann mit den Stadtbahnen im Rhein-Ruhr-Bereich? Es ist nicht ohne Grund der Fall, dass hier immer noch keine Einheitliches Linien-Tagging vorherrscht. Die sind nämlich von Charakter her weder tram noch subway. Die Stuttgarter haben daher ihr Netz korrekter Weise auf light_rail umgestellt, auch wenn es das offiziell gar nicht gibt.

Und ein rechtlicher Rahmen gibt auch immer mindestens anteilig den Charakter vor. So ist es kein Zufall, dass auf allen Stadtbahnsystemen deutlich kürzere und schmalere Züge fahren als auf den Voll-U-Bahnen, das wird nämlich von der BoStrab so vorgegeben.

Die sind aber in jedem Bahnhof in der stop_area drin, auch, wenn JOSM das immer anmeckert.

Ich stimme dir da voll zu. Aber ich will hier gar keine Diskussion über die korrekte Anwendung von PTv2 führen. Ich will dir aufzeigen, dass die Leute damit einfach nicht klar kommen! Deswegen muss das ganze deutlich vereinfacht werden!

Warum? Warum unbedingt nochmal einen neuen Schlüssel erfinden, wenn wir schon einen haben, der das alles kann? Ich habe bisher noch kein Argument gehört, warum public_transpot=* nicht funktioniert!

Es ist bisher nur leider so, dass es durch die ganzen Dopplungen von vielen als Überflüssig oder als Hilfstag wahrgenommen wird. Aber die Gründe dafür liegen definitiv wo anders.

Viele Grüße

Ja. Aber public_transport=station darf rein. Dass public_transport=station etwas völlig anderes ist als railway=station ist den Leuten egal. public_transport=station wird einfach umdefiniert, damit man formal begründen kann, dass der Zentralnode in der stop_area auftaucht.

Nehmen wir mal nur public_transport=stop_position und public_transport=platform: Jeder der beiden muss in die Route, wenn er gemappt ist. Jeder der beiden ist optional, aber einer muss da sein, sonst ist da keine Haltestelle. Die Zusammengehörigkeit eines stops zu einer platform (egal, ob mit oder ohne public_transport-tag) ist nur aus den Routen zu entnehmen. Zu einer Platform können mehrere Stops gehören und zu einem Stop können mehrere Platforms gehören. Wenn man jetzt eine Karte erstellt und wissen will, ob an diesem gerade verarbeiteten Node ein Haltestellensymbol auf die Karte soll, dann kann man ohne komplette Analyse der Routen nichts entscheiden. Selbst mit Routenanalyse gibt es Fälle, in denen man nicht entscheiden kann ob da ein “H” auf die Karte soll oder nicht. Man kann natürlich mehrere “H” für einen Halt machen … aber es will doch nun wirklich keiner eine mit “H” zugepflasterte Karte.

Deshalb sollte jede Bushaltestelle genau ein highway=bus_stop haben und das sollten die Kartenhersteller nutzen.

Beim OSM-Samstag auf der heurigen FOSSGIS in Passau gab es eine Diskussion zum ÖPNV-Mapping. Ein Kurzprotokoll habe ich damals unter https://wiki.openstreetmap.org/wiki/FOSSGIS_2017/OSM-Events/%C3%96PNV-Mapping zusammengeschrieben

Hallo hsimpson,

Die Probleme bei PTv2 sind in meinen Augen:

  • Das Proposal ist zwar angenommen, aber die Wikiseiten, die sich mit ÖPNV beschäftigen, sind erst Jahre später aktualisiert worden. Solche Widersprüche fördern Missverständnisse und stiften Verwirrung. Auch ich bin diesen eine Zeit lang aufgesessen.

  • Ein Taggingschema, das mehr macht, als nur ein paar Tags zu erfinden, wird ohne eine Musterimplementierung nur beschränkten Erfolg haben. Für ein x-beliebiges neues Tag foo=bar, erfordert es nur Änderungen am Kartenstil. Neue Relationstypen erfordern jedoch Support durch die Werkzeuge, die aus diesen Relationen normale Simple-Feature-Geometrien (Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon) erzeugen, wie sie von den üblichen GIS-Werkzeugen verwendet werden. Aus diesem Grund hat die site-Relation auch nur eine geringe Relevanz. Wer also möchte, dass ein von ihm vorangetriebenes Mappingschema auch unterstützt wird, muss, so hart es leider auch klingen mag, selber Software programmieren.

  • Das Problem mit den schwer wartbaren Routen ist wirklich ein Problem. Ich meine damit das Schulbusproblem und die Segmentfrage. Ich kann mit Segmenten leben.

Nicht störenden Unschönheiten sind:

  • Masterrouten. Mir leuchtet noch nicht ein, wozu die erforderlich sind. Das mag aus Mapperperspektive auf dem Papier schön aussehen (“dann ist da eine Relation, die die anderen Relationen zusammenfasst”). Das Konzept hat aber das oben erwähnte Problem, dass es von wenigen Anwendungen unterstützt wird und in den mir bekannten Fällen nur Informationen dupliziert. Versteht mich nicht falsch! Ich bin nicht streng gegen Duplizierung, aber wenn Duplizierung, dann bitte so, dass beide Varianten ähnlich gut für Datennutzer zugänglich sind.

  • Geteilte Bahnsteige (siehe Beitrag #1 von sllh)

Dem Renderer sind die Daten egal. Du meinst vermutlich “Kartenstil”, oder?

Wenn zu mir als Kartenstilautor jemand sagen würde, du musst das neue Tag foo=bar unterstützen, weil es dazu ein akzeptiertes Proposal gibt, würde ich ihm freundlich mitteilen, dass ich gerne abwarten würde, bis es angenommen ist. Der beste Weg, etwas voranzubringen, ist Dinge selber zu machen. So funktioniert Open Source.

Viele Grüße

Michael

Ein bisschen OT, aber warum existiert diese Wiki-Seite noch: https://wiki.openstreetmap.org/wiki/%C3%96PNV_Schema
Ist es nicht Sinnvoll, diese Seite zu löschen und stattdessen eine Weiterleitung zur Public-Transport-Seite zu installieren?

Meiner Ansicht nach schafft diese Siete mehr Verwirrung, als sie ausräumt, da sie bei weitem nicht vollständig ist und keinerlei Verweise auf aktuelle Seiten zum Thema ÖPNV aufweist (außer zu ein-zwei Key/Value-Seiten).

Grüße

Genau hier beißt sich doch wieder die Katze in den Schwanz…

Es gibt nunmal leider viele Mapper hier, die nur das mappen, was auch auf der Karte gezeigt wird. So bin ich immer noch der Meinung, dass die Berliner und Hamburger S-Bahnen sehr schnell auf route=train + service=commuter umgestellt werden würden, wenn die gängigen ÖPNV-Karten route=light_rail nicht mehr grün rendern würden. Diese tun das aber immer noch, mit Verweis auf die aktuelle Nutzung dieser Tags. Im speziellen Fall der ÖPNV-Karte ist ein Umstellen auf die korrekte Tagging-Variante sogar kontraproduktiv, da diese service=commuter gar nicht rendert. Blöderweise ist das auch eine der bekanntesten Karten in dem Bereich.

Und genau deshalb muss man die großen Renderer unbedingt von Anfang an mitnehmen, damit man eben nicht erst am Ende zu ihnen kommt und denen ein neues Schema vor die Füße wirft. Sonst würde ich auch sagen, dass man mir doch bitte erst mal ein paar Beweise bringen soll, dass das tatsächlich relevant ist, das jetzt anders zu rendern.

Anderes Beispiel: Wenn Carto highway=platform nicht mehr rendern würde, wäre dieser Tag schon lange ausgestorben…

Viele Grüße