Bedarfshalt: wie mappen?

Ich wollte gerade einen Bedarfshalt (railway=halt, an dem die Bahn nur auf Wunsch hält) eintragen. Eine Suche im Wiki ergab

  • request_stop=yes/no,* das immerhin zweimal in der Kombination mit railway verwendet wird
    Dieses Tag lässt sich aus anderen Tags/Vorschlägen ableiten¹:
  • stop_on_demand=yes/no*
    wird aber nicht verwendet.

Mich wundert ja, dass die als so detailversessen beschriebenen Bahner dieses Detail allem Anschein nach nicht berücksichtigt haben.

Kurz und knapp: welches der beiden Tags sollte man verwenden – oder ist ein anderes, das ich nicht fand, schon weit verbreitet?

¹ 1, 2, 3, 4

Laut Protokoll des Treffens vom Mai 2014 soll es nicht im Zusammenhang mit der Infrastruktur gemappt werden, weil ob ein Zug stets, gar nicht oder nur nach Bedarf an einer Station hält, eine Eigenschaft des jeweiligen Fahrplans und nicht der Infrastruktur ist:

Es kann natürlich an Bedarfshalten spezielle Infrastruktur geben (beispielsweise Taster, die über ein Signal dem Triebfahrzeugführer einen Zustiegswunsch signalisieren - daher auch beim Signal-Tagging stop_demand-Signale), aber grundsätzlich scheint es tatsächlich sinnvoller, derartiges, wenn überhaupt, eher in die Route-Relationen von Linien aufzunehmen, die diese Haltestelle ansteuern.

Aber ohne dass man das vernünftig dokumentiert, wäre das ziemlich sinnfrei. Das ist ohnehin schon der kritische Punkt bei allem, was mit public_transport zusammenhängt, dass es im Wiki auf den entsprechenden Seiten keine aktuelle und umfassende Dokumentation gibt, sondern Stückwerk verschiedenen Alters, welches sich nicht selten auch noch widerspricht. Und jeder macht es dann, wie er denkt. Die Wartbarkeit und Auswertbarkeit ist entsprechend beschränkt…

Ich kenne Bedarfshalte eher als Eigenschaft der Infrastruktur.
Bei manchen Busgesellschaften sind die Bedarfshaltestellen in Stadt- und Linienplänen und auf dem Haltestellenschild durch andere Symbole als Zwangshalte gekennzeichnet.
An den Bedarfshaltestellen der Bahn, die ich kenne, steht eine deutliche Beschilderung und ein einschaltbares Lichtsignal.

Für OSM wäre es sinnvoller, Bedarfshalte als Eigenschaft der Infrastruktur zu erfassen, da die Infrastruktur meist sehr gut, die Linien aber unvollständig und vielfach nicht auswertbar gemappt sind.
Ich sehe die Erfassung der Linien inzwischen als nutzlosen Aufwand und beschränke mich auf die Infrastruktur.

Gerade im Stadtverkehr ist es allerdings oft so, dass nahezu jede Haltestelle nur ein Bedarfshalt ist. Dort stellt sich dann schon fast wieder die Frage der Sinnhaftigkeit einer separaten Erfassung.

Das Problem daran ist halt, dass Bedarfshalte nicht unbedingt immer Bedarfshalte sind. Es kann von den Linien abhängen, es kann sogar von der Uhrzeit abhängen, ob eine Station regulär oder per Bedarfshalt bedient wird. Beispielsweise bedient die RB 27619 zwischen Straubing und Neufahrn 4 Unterwegshalte nur per Bedarf, während die nachfolgende RB 27621 (Schülerverkehr) an sämtlichen Stationen regulär hält. Bei der Oberhavel-Verkehrsgesellschaft ist es so, dass z. B. auf der Linie 838 zu nachfrageschwachen Zeiten ganze Kurse nur nach Bedarf bedient werden (telefonische Anmeldung), während die Haltestellen sonst regulär bedient sind.

Das ist also gar nicht so einfach, dort ein sinnvolles Schema zu finden. Es ist aber eben nicht in jedem Fall eine Eigenschaft der Infrastruktur, dass nur bei Bedarf gehalten wird, sondern teilweise eben auch fahrplanabhängig. Vielleicht ist es damit sogar außerhalb der derzeitigen Zielstellung von OSM.

Das Problem ist auch, dass wenn man dort etwas Neues einführt, was einfach nur mittels “quick and dirty” den schnellen Erfolg sucht, das einem später oft wieder böse auf die Füße fällt. Daran krankt dieser ganze ÖPNV-Bereich, dass sehr häufig komplette Tagging-Schemata eingeführt wurden, die sich einige Zeit später als ungenügend herausstellten und wieder etwas Neues kam und so ein Flickwerk verschiedenster Erfassungsstände mit zusätzlichem individuellem Wildwuchs entstanden ist, was zu Unsicherheit beim Mapping und in der Fläche zu einem ziemlich unverwertbaren Stand führt.

Meiner Meinung nach ist es bei der Infrastruktur aus obigen Gründen nicht gut aufgehoben. Das wird auch nicht dadurch verlockender, dass das Chaos beim Rest so groß ist, dass man es dort freiwillig schon nicht mehr ranpappen will.

Ich stimme Dir zu, dass der Zustand schlecht ist. Die Gründe für den schlechten Zustand sind aber andere.

Wir haben nur einen einzigen beschlossenen Vorschlag (PTv2: http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726), der nur leider nie gründlich gelesen wird. Der ist auch nicht “quick and dirty”. Er hat Mängel, aber im Vergleich zu den Mängeln der Taggingpraxis sind die unbedeutend. Dieser Vorschlag wird andauernd mit der davor üblichen Praxis (PTv1) durcheinandergewirbelt.

Weide

Das ist auch kein Wunder, denn wenn man ins Wiki geht, wird man an jeder Ecke mit den vorherigen Varianten konfrontiert:

Relation:route: Großartige Dokumentation mit forward_stop und backward_stop für verschiedene Richtungen, obwohl das mit zwei getrennten Routen und master_route zu mappen wäre. Fehlt nur noch forward_stop_entry_only usw. :smiley:

Tag:route=bus und Tag:route=train: Auch hier kann man vorwärts und rückwärts angeblich in eine Relation schreiben und dann ggf. forward/backward-Keys verwenden.

Und dann gibt es selbst Sachen, die nicht einmal auf der Seite Public_transport konsistent sind, die angeblich das neue Schema beschreibt. Da heißt es beispielsweise im Abschnitt Busse, dass highway=bus_stop durchaus für einfache Haltestellen noch verwendbar ist (und zwar sogar ohne paralleles Tagging nach public_transport-Schema, denn das “sollte” nur sein, muss aber eben nicht). Da sollte offenbar mal wieder niemandem auf die Füße getreten werden. Unter Tag:highway=bus_stop heißt es dann, ein solcher Knoten sei links oder rechts des Weges am weitesten verbreiten (schon an sich wieder eine extrem “verbindliche” Formulierung). Aber wenn man das nun macht, dann wird es spätestens beim Abschnitt “Strecken/Linien/Kurse” unter Public_transport wieder interessant, denn nun soll man auf einmal Haltepositionen mit der Rolle “stop” mappen und sogar verpflichtend. Oben stand aber, dass man das gar nicht erfassen muss und stattdessen auch einen simplen highway=bus_stop verwenden kann. Wie man das Problem löst, dass man “stop” braucht, wenn man zumindest einen “bus_stop” hat, liegt auf der Hand…

Wenn man selbst als äußerst umsichtiger Mapper, der sich vorher im Wiki umfassend informiert, letztlich völlig ratlos zurückbleibt, weil man ständig auf widersprüchliche Informationen trifft, braucht es niemanden wundern, wenn das Mapping dann auch entsprechend ausfällt und aus jeder Menge Improvisation und Inkonsistenz besteht. Verbunden mit dem oftmals als ungeschriebenes Gesetz angesehenen Grundsatz, dass jeder beim Mappen nach seiner Facon glücklich werden soll, hat man dann eben auch ein sehr “heterogenes Werk” (sehr vornehm ausgedrückt).

Ich habe ihn gar nicht gelesen, sondern nur überflogen und nach “request” und “demand” gesucht – ohne Ergebnis.

Ich lebe in eher ländlichem Gebiet und die nunmehr zwei Bedarfshalte an Eisenbahnen, die ich kenne, gelten für alle dort vorbeikommenden Züge.

Meine Anfrage startete ich, weil ich die Winkanforderung an diesem Bahnhalt mappen wollte.
Das stop_on_demand=yes habe ich mehr oder weniger vorläufig rangeschrieben, damit es im Laufe der Diskussion nicht aus den Augen verloren wird.

Der Bedarfshalt ist so beschildert:


Ich halte es für wenig zielführend, vier Transport-Relationen anlegen zu müssen (es gibt vier unterschiedliche Fahrpläne, abhängig vom Datum), um die Eigenschaft “Bedarfshalt” an einem Punkt zu mappen.
Dann müsste ich erstmal fragen, ob ich die aushängenden/im Netz veröffentlichten Fahrpläne verwenden darf – und die Relationen dann vermutlich jedes Jahr überarbeiten.

“Keep It Simple” ist was anderes…

In dem Falle, dass es so beschildert ist, spricht aus meiner Sicht nichts dagegen es an die Infrastruktur zu hängen. Allerdings gibt es auch gute Gründe das in den Relationen zu erfassen. Insbesondere bei Rufbussen die einmal am Tag auf teilabschnitten auch eine Festbedienung für Schüler haben. Überhaupt sind alle Bushaltestellen und die meisten Straßenbahnhaltestellen nur bei Bedarf bedient. Es genügt aber einfach da zu stehen oder einen Knopf zu drücken.

Das halte ich für die beste im Moment nutzbare Lösung. Es steht an der Haltestelle und ist daher eine Eigenschaft der Haltestelle. (In den PTv2-Routen könnte man es auch nicht unterbringen.)

Weide

Das muss dokumentiert Sein, denn es ist zulässig und man will die noch vorhandenen Daten ja verstehen können. Die alten Routen kann man auch nicht immer ohne Ermittlungen vor Ort in neue transformieren. Z.B. bei einer X-förmigen alten Route: Fährt da ein Bus von rechts unten nach rechts oben? Das geht aus der alten Route nicht hervor … da steht nur, dass da überall Busse fahren.

Ja. Die Routen sollten abgelöst werden. Bei den Haltestellen sollten nur neue Möglichkeiten hinzu kommen. (Sonst hätte man auch die ganze Welt in einem Änderungssatz umstellen müssen)

Man kann dieses sehr alte Tag ja nicht nachträglich umdefinieren … dafür gibt es zuviele Daten. Als es noch nicht normal war, alle Straßen der Gegend in der Datenbank zu haben, da reichte die Möglichkeit. Man pappt einen Node dahin und der bedeutet “Hier ist ne Haltestelle”. Wenn die beiden Haltestellen auf der Landstraße einander gegenüber lagen, hat man einen Node auf die Straße gesetzt und sonst zwei neben die Straße, damit man wenigstens die Richtung sieht. Viele haben sie aber auch auf die Straße gesetzt und die Richtung als Tag “direction=E” oder so drangeschrieben.

Das ist tatsächlich falsch. “stop” und “platform” sind gleichwertig. Es wäre für Programme einfacher, wenn einer der beiden verbindlich wäre – aber das ist nicht so. Verbindlich ist nur, die gemappten auch in die PTv2-Routen aufzunehmen. (Durch diese Regel kann man aus den Relationsmitgliedschaften der Objekte die Liste der dort haltenden Linien ermitteln. Deshalb dürfen Platforms auch nicht doppelt gemappt werden, denn dann funktioniert das alles nicht mehr.)

Weide

Das Problem ist, dass diese Schemen von denjenigen entworfen werden, die täglich mit Daten umgehen. Für die überwältigend große Mehrheit der Feierabend Mapper, die z.B. tagsüber Brötchen backen oder verkaufen, und die man im (technophilen) Forum nicht findet, ist das zu kompliziert. Die kennen die Route, auf der der Bus fährt und die Haltestelle. Wenn man sich an eine Haltestelle stellt, hält der Bus auf der Route genau davor. Warum also reicht es nicht, an die Stelle des Haltestellenschildes einen bus_stop zu setzen, sowie die Haltestellen und die Route in eine Relation pro Fahrtrichtung einzusammeln und fertig? Wenn man dann noch die Technik der Routenplaner/Navis benutzt, um die Route herzustellen, wäre es leicht. Man markiert Start- und Ziel- Haltestelle, lässt routen und schiebt dann solange, bis die Route stimmt. Alles andere wie die stop_position kann eine ÖPNV Anwendung daraus automatisch konstruieren - genau so, wie der Busfahrer ohne stop_position am Busschild anhalten kann,. Wie das geht, zeigt der OSM Inspector im “Adressen” Tab, wo er eine Linie vom Adress-Node auf den nächsten Punkt der Straße zeichnet und damit die stop_position erzeugt. Die beiden erforderlichen Techniken existieren also schon. Dann kann es auch nicht passieren, dass jemand den in der Realität wahrgenommenen bus_stop verschiebt und die stop_position aus Unwissenheit nicht.

Die Beschreibung der entwickelten Schemen kann Otto Normalmapper nicht verstehen und somit nicht diskutieren und abstimmen. Es stimmen also nur Insider ab. Folglich kommt es dann zu dem Chaos, das wir jetzt haben. Und das wird so bleiben, wenn wir nicht zu einem einfachen Schema zurückfinden.

Eine Beschreibung eines ÖPNV Editors könnte so schön kurz sein:
*Mappe alle Haltestellen an der Stelle, wo das Schild oder Wartehäuschen steht, mit highway=bus_stop.
*Markiere in der Kartenansicht die Start- und Ziel-Haltestelle.
*Klicke auf “Hinfahrt routen”.
*Schiebe die Route, bis alles stimmt.
*Klicke auf “Rückfahrt routen”. (Dabei wird die Pfeilrichtung der Hinweg Route umgekehrt angezeigt.)
*Schiebe die Route, bis alles stimmt.
*Trage den Verkehrsverbund und die Liniennummer ein.
*Klicke auf Fertig. (Damit steht das Grundgerüst einer Buslinie).

Das reicht ja. Ein “name” wäre natürlich auch noch schön.

Es gibt kaum Buslinien ohne Varianten (früh morgens über Industriegebiet Ost). “pro Richtung” muss man schon durch “pro Variante” ersetzen – aber dann gehts.

Wie Du ja geschrieben hast, müssen die Einträge noch gemäß Realität sortiert werden.

Das funktioniert nicht einmal bei kompletten Daten und die hat Otto Normalmapper praktisch nie. Bei einem X-förmigen Weg kann man durch Verschieben von Linien auf dem Bildschirm die Streckenführung nicht angeben. (Es geht, wenn man die Route in ein paar unverzweigte Teilstücke aufteilt … das hab ich für P3 vorgeschlagen. Da muss man die Wege dann garnicht mehr sortieren und sie gehen durch andere Editiervorgänge daher auch nicht mehr kaputt.)

Wozu? Wir brauchen eigentlich keine zusätzlichen stop_positions. Wir benutzen sie im Moment nur, weil viele Steige als Wege oder Flächen gemappt sind und die alten Routen nur Nodes können. Außerdem kriegen wir das H-Zeichen auf vielen Karten nur an Nodes.

Das was wir haben ist wesentlich besser als sein Ruf. Aber wir haben ein massives Beschreibungsproblem und ein massives Gerüchteproblem. Otto Normalmapper richtet sich nach dem, was er in seiner Umgebung findet. Und das ist leider oft Mist. Dieser Kram wandert dann sogar bis in die Wikis.

Weide

Hallo Weide,

erstmal vorweg: Ich wollte hier kein allumfassend funktionierendes Schema aufzeigen, sondern einfach die Richtung verdeutlichen, in die es gehen müsste. Es muss vor allem gesichert sein, dass man das Mapping eines einfachen und häufigen Falles einer Busverbindung von A nach B ohne Firlefanz (sozusagen das “Hello World”) nicht ergründen kann, ohne sich durch eine Beschreibung zu quälen, die alle möglichen Sonderfälle abdeckt, die man in der Realität nicht erlebt hat, und von daher nicht nachvollziehen kann. Mir ist klar, dass da noch gefeilt werden muss, z.B. auch Teilstreckenedits möglich sein müssen. Ich weiß, dass Busse wie der VRR 781 Varianten haben, temporär Schleifen fahren, manchmal Unterfeldhaus links und manchmal recht umrunden etc. Aber die muss man nicht zu verstehen, wenn man solche Linien nicht mappt oder nicht kennt. Darum gehe ich nicht explizit auf diesbezügliche Punkte ein, mit denen Du natürlich recht hast.

X-förmige Wege? Was meinst Du damit? Sowas: Ein Bus fährt auf gerader Strecke von A über B nach C. Lediglich an Punkt B verlässt er die gerade Strecke, fährt eine Schleife, die ihn zu B zurückführt. Er kreuzt also seinen eigenen Linienweg. Sowas kann ich mit dem OSRM Router erstellen, indem ich bei falscher Richtung der Schleifendurchfahrung einen weiteren Punkt dort hineinziehe, sclimmstenfalls also zwei Punkte in der Schleife - nicht bei osm.org, aber auf deren Seite: http://map.project-osrm.org/

Beispiel, in dem eine Schleife einmal links und einmal rechts herum durchfahren wird:
http://map.project-osrm.org/?hl=de&loc=51.164543,6.866129&loc=51.165813,6.867269&loc=51.166752,6.867206&loc=51.164600,6.867223&z=16&center=51.164241,6.869513&alt=0&df=0&re=0&ly=-1171809665
http://map.project-osrm.org/?hl=de&loc=51.164543,6.866129&loc=51.166752,6.867356&loc=51.165798,6.867367&loc=51.164600,6.867223&z=16&center=51.164241,6.869513&alt=0&df=0&re=0&ly=-1171809665

Die Schleife muss in den alten Schemen mindestens aus zwei Wegen mit angegebener Reihenfolge bestehen, weil man sonst nicht weiß, in welcher Richtung die Schleife durchfahren wird. Wie das in P3 ohne Reihenfolge gehen soll, muss ich mir mal ansehen.

Ich weiß nicht genau, wozu das gebraucht wird. Mir erzählen die Eisenbahnfreaks, es sei unverzichtbar z.B. in Bahnhof X auf Gleis Y. Ich glaube, es waren zwei Züge auf einem Bahnsteig. Ich verstehe nicht so viel von der Bahn, weil ich erst einmal deutlich umwegig 180 km fahren muss, um einen ICE zu sehen. Die 20 km Busanbindung zum nächsten Bahnhof ist zudem grausam und teuer. Dann benutzt man sie eben selten.

Nach dem neueren Schema gemappte Linien sind kaum zu analysieren. Im Umfeld zu gucken, funktioniert da nicht. IMHO sollte ein neues Schema von den Machern im Wiki erklärt werden, bevor es abgestimmt wird, damit jeder versteht kann, was abgestimmt wird. Dann muss auch nichts Falsches beschrieben werden. Dazu gehört zumindest ein einfacher variantenloser Bus ohne Firlefanz, und dann ein weiterer, der ihn an einer Umsteigehaltestelle kreuzt - sozusagen ein “Hello World”.

Ich war der Meinung, Du hättest das Schema aufgegeben. Schön dass Du jetzt doch wieder aufgetaucht bist. Ob Du das ohne stop_position bei den Eisenbahnfreaks wirklich durchsetzen kannst? Die war nämlich IMHO das größte Manko am Modell.

Ein neues Schema sollte IMHO sehr gut vorbereitet werden und nicht nur von den Insidern im Wiki abgestimmt. Den existierenden ein weiteres Modell zuzufügen, macht die Sache IMHO nur noch schlimmer. Es sollte ähnlich wie bei der Lizenzumstellung ein Datum geben, an dem Schicht ist. Alle Editoren und ÖPNV Karten sowie alle beteiligten ÖPNV Unternehmen sollten einbezogen werden und an diesem Tag umstellen. Am besten wäre es, wenn es an diesem Tag auch schon den passenden ÖPNV Editor gäbe. Ich denke, die Programmierung desselben kann auch Schwachstellen im Konzept aufzeigen. Beschreibungen im Wiki von alten Schemen müssen eine Box haben, die sie als veraltet beschreiben. Der bus_stop beliebig auf der Straße oder daneben muss Vergangenheit sein und verbindlich neben der Straße sein. Man sollte ihn zwar auf der Straße tolerieren, aber nicht so publizieren. Viele Mapper wünschen sich da etwas Eindeutiges. Die stop_position kann dann von der Anwendung konstruiert werden, umgekehrt geht das nicht. Es darf nicht mehr zwei verschiedene Keys für dasselbe Objekt geben. Von daher muss das Modell auch eindeutig die Erfassung der Haltestellen beschreiben und nicht nur die Linienerfassung. Das Modell muss vor seiner Diskussion auch für Anfänger verständlich ausreichend dokumentiert sein. Das Thema muss möglichst von allen Stellen, auch der OSM Foundation und ihren Workinggroups thematisiert werden. Wenn die alten Modelle verschwinden, brauchen für die Keys auch nicht neue, weniger intuitive Bezeichnungen erfunden werden. Ein neues Schema muss es für den Anwender möglich machen, eine in der Realität verschobene Bushaltestelle neben der Straße zu verschieben, ohne zu wissen, dass man auch die stop_position verschieben muss, Ansonsten funktioniert die Zusammenarbeit zwischen Relationsersteller und dem Mapper mit den Vor-Ort Kenntnissen nicht.

Auf jeden Fall Danke für Deinen Mut, im jetzigen Chaos einen neuen Weg zu suchen.

x förmig bedeutet das die Buslinie 4 Endpunkte A-D hat. jetzt kann der Bus von A nach C oder von A nach D fahren genau sowie er von B nach C oder D fahren könnte. Allein aus einer Relation in der alle Wege drin sind die von der Linie benutzt werden (PTV1) lässt sich also nicht herausfinden ob es die direkte Fahrmöglichkeit A-C gibt. Das wird erst mit PTV2 anders, wenn alle Linienvarianten ihre eigene Relation bekommen.
Auch die Schleife ist ein schönes Beispiel. Es kann genauso gut Busse geben, welche A-C fahren ohne in B dann diese Schleife zu durchfahren. Das würde man erst wissen, wenn man nach PTV2 zwei Relationen hätte oder eben nur eine.

. O.K. x-förmig bedeutet also eine Linie mit Varianten. Und diese Varianten kreuzen sich, wenn ich es richtig deute, daher also das X. Hättest Du mal einen Link auf einen entsprechenden Gesamtfahrplan einer X-förmigen Linie bei einem Verkehrunternehmen oder Verlehrsverbund, damit man sich ein Bild von so etwas machen kann? Mir erschließt sich nämlich nicht, warum man eine Linie sowohl beispielsweise von A nach C, als auch von B nach D, also zwei vollkommen voneinander entkoppelten Linienwegen fahren läßt und warum man da nicht zwei Linien draus macht.

Das ist auch nur sehr vereinfacht. Zwischendrin liegen natürlich auch noch gemeinsam benutzte Abschnitte. Ein Beispiel wäre die Linie 66 der DVB in Dresden.
https://www.dvb.de/de-de/fahrplan/linienfahrplaene/

Die Zusammenlegung hat man vorgenommen um den Fahrgast auf dem langen Abschnitt zwischen Südhöhe und Prohlis zu signalisieren hier fährt deine Linie im für 60er Linien üblichen Takt. Früher waren das mal zwei getrennte Linien.

Ahja, jetzt wird ein Schuh daraus. Ein X-förmige Linie ist eine Linie mit Kernstrecke, die sich an beiden Enden verästelt. Bei mir läuft das unter Doppel-Y oder Einfach-Y, wenn nur eine Seite Äste hatte. Solche Linien sind natürlich eine geläufige Struktur, bei schienengebundenen Fahrzeugen auch gerne als Flügelung.

wobei im Schienenverkehr mit Flügelung immer beide Äste bedient werden. Hier und wie von Weide angesprochen geht es aber um Fahrzeuge die immer von einem Endpunkt zu einem bestimmten anderen fahren.
Es wird kein Bus von Coschütz nach Lokwitz fahren und keiner von Mokritz in Richtung Luga.

Zusammenfassung:
stop_on_demand=yes am railway=halt oder railway=station ist die einfache Lösung, der auch andere zustimmen.

Knifflig wird es, wenn mehrere Linien verkehren, von denen einige planmäßig, andere nur nach Bedarf halten.
Ich würde das als nicht-PT-Mapper mit einer Notiz festhalten.

Theoretisch wird zwar empfohlen, den Bedarfshalt an der entsprechenden PT-Relation festzuhalten, aber das ist nicht/schlecht dokumentiert, mit dem aktuellen Schema wohl auch nicht kompatibel und zudem nicht praktikabel, wenn man “nur einen Bedarfshalt” mappen will und noch keine Relationen vorhanden sind.

Das gilt nur für PTv2, also das Public Transport Proposal.

In PTv1 gilt das nicht. Da kommt alles in eine Relation, jede Straße kommt nur einmal vor und die Reihenfolge der Angaben ist egal. Zu der Straße wird über die Rolle angegeben, ob die Busse der Linie da immer nur von links kommen (“forward”) oder immer nur nur von rechts (“backward”) oder mal von links und mal von rechts (leere Rolle). Bei so einer Schleife, die in beiden Richtungen benutzt wird, trennt man also nichts auf und nimmt die leere Rolle. Im Grunde ist eine PTv1-Route nichts anderes als ein Linienplan. Man malt auf einer Karte alle genannten Straßen grün an und macht bei denen mit “forward” oder “backward” auch noch Pfeile dazu. Da kann man aber nicht sehen, dass die im Uhrzeigersinn durchfahrenden Busse hinterher über “Rathaus” fahren und die anderen statt dessen über “Marktplatz”.

Da wird alles in Segmente aufgeteilt, so dass jedes Segment ein eindeutiges Wegstück ist und keine Reihenfolge der Wege braucht. Wenn keine Reihenfolge gebraucht wird, kann sie auch niemand versehentlich kaputtmachen. Die Haltestellen sind da auch drin und haben die da angegebene Reihenfolge.
Bei so einer Y-förmigen Buslinie mit den Enden A, B, C und der Mitte M hätte man z.B. die Segmente A=>M, B=>M, C=>M, M=>A, M=>B, M=>C und die Varianten werden dann nur aus den Segmenten und nicht mehr aus Wegen und Haltestellen zusammengesetzt. Von A über B nach C wäre dann z.B. “A=>M, M=>B, B=>M, M=>C”.

Hab ich auch. Das war ein anderer Entwurf. P3 ist einfacher und viel editierfreundlicher, hat aber eine Relationsebene mehr in den Routen. Die Linien bestehen aus Varianten, die Varianten bestehen aus wiederverwendbaren Segmenten, die Segmente bestehen aus Wegen und Haltestellen.

Ich glaube nicht, dass man sowas schaffen kann. Es ist ja nicht einmal möglich, alle PTv1-Routen ohne Ermittlungsarbeiten vor Ort auf PTv2 umzustellen.

Aber man kann es schaffen, dass das neue Schema von Anfang an von Renderern, Editoren und anderen Programmen voll und ganz unterstützt wird und insbesondere keine Fehlermeldungen durch die “Schemenverdopplung” verschlechtert werden. Es ist ebenfalls machbar, dass dabei nichts doppelt dargestellt wird. Man kann es auch schaffen, dass das Doppeltagging von Haltestellen entfernt werden kann, wo die Umstellung der Routen schon gemacht wurde. Genau das war – neben dem Vermeiden der versehentlichen Zerstörungen und dem Ergänzen einiger jetzt nicht mappbarer Sachen – das Hauptziel von P3.

Weide