Diskussion über Public Transport Version 2.1

Für 2 von die 3 Unternehmen in Belgien haben wir Zugang auf ihren Daten. Das bekommen 5 Tabellen und damit ist es ganz einfach um Routerelationen zu erfassen für jede Variation ihre Linien. Das funkzioniert aber nur wenn alle Haltestellen in die Routerelation sitzen bleiben.

Für mich ist es auch praktisch sofort zu sehen an welche Routevarianten Nodes teilnehmen.

Die ways füge ich dann nachher zu. Jetzt benutze ich dazu ein Skript das ways sucht die nahe zu die HS sind. Die Route ergänzen muss dann manuell gemacht werden. Diese Arbeit wäre viel einfacher wenn ways schon zusammengefasst wären in Segmentroutes. In viele Fälle würde das sogar sofort korrekt sein. In andere würden vielleicht noch Segmente getrennt werden mussen. Abhängig davon wie “klug” man war beim erfassen des Segmentes. Das ist auch der Grund warum ich route_ref auf die Haltestellen hinzufüge. Dann wird es viel einfacher um das intelligent zu tun, d.h. zu wissen wo am beste diese Segmente zu trennen, beim erfassen.

Polyglot

Ich hab mal wieder einen Entwurf gemacht … zumindest kann man von ihm sagen, dass er viel einfacher ist als der letzte :slight_smile:

https://wiki.openstreetmap.org/wiki/User:Weide#Vorschlag_P3

bis dann
Weide

Hallo Weide,

Tipp für andere Foristen: Fangt oben auf Weides Userpage an zu lesen.

Auch es nichts mit deinem Vorschlag zu tun hat – die Vergleichstabelle finde ich richtig gut!

Aber nun zu deinem Vorschlag
(1) Du möchtest eine Rolle für die Relationsmitglieder einführen, die ein Stück des Fahrwegs repräsentieren.

(2) Das Tagging von Routen ist in großen Teilen vom bisherigen Tagging verschieden. Charakteristisch ist “p3”. Das fängt schon beim wichtigsten aller Relationstags an, dem type=*. Du schlägst type=p3 statt type=route vor, damit die Routen, die nach deinem Vorschlag gemappt werden, von nicht angepassten Programmen nicht ausgewertet werden.

(3) Bei PTv2 sind die möglichen Verkehrsmittel auf ein enges Set beschränkt, welches u.a. keine light_rail enthält. Du schlägst stattdessen kind=rail/road/water/other vor und überlässt die Einführung von Subtags der künftigen Entwicklung.

(4)In deinem Schema müssen nicht mehr sowohl stop als auch platform in die Routenrelation. Stattdessen kommen nur noch Bahnsteige/Wartebereiche mit der Rolle halt hinein. Wenn eine Station einen mehrteiligen Bahnsteig hat (z.B. ein Teil des Bahnsteigs liegt auf einer Brücke), dann bekommt der zweite/dritte Bahnsteigteil die Rolle +halt. Bahnsteige der Spanischen Lösung bekommen die Rolle halt#. Wenn man die Plattform nicht kennt (z.B. weil Grasbahnsteig im hohen Gras oder von Bäumen verdeckter Bahnsteig), dann fügt man bei PTv2 nur die stop_position ein. Bei dir muss man dann die stop_position einfügen und ihr die Rolle halt_fixme zuweisen.

(5) Wenn eine Linie eine Schleife fährt, dann sollten die Schleifenstücke mit den Rollen tour_ccw und tour_cw in die Relation aufgenommen werden.

(6) Für die Routen schlägst du noch optionale Zusatztags wie next_ref, prev_ref, var_ref, active usw. vor.

(7) Dein Schema trennt zwischen den bekannten Stop-Area-Relationen und “Gesamthaltestellen”. Sobald eine Steig-/Bahnsteignummernkollision droht (z.B. Gleisnummer der U-Bahn-Station mit der Gleisnummer im DB-Teil des Bahnhofs), sind zwei getrennte Stop-Area-Relationen anzulegen. Eine Gesamthaltestellen-Relation verbindet dann alle Teilhaltestellen.

(8) Um die Abwärtskompatibilität zu wahren, schlägst du vor, währen einer Übergangszeit zwei Routenrelationen zu pflegen.

Meine Meinung
(1) Ich habe die leere Rolle bisher nicht als Problem wahrgenommen. Ich glaube, dass eher JOSM das Problem ist, weil er das anmeckert.

(2) Bisher gibt es das (von JOSM/JOSM-Entwicklern vorgeschlagene) public_transport:version=2, welches aber bloß von den Programmen ausgewertet wird, die auch danach suchen. Programme, die vor Urzeiten geschrieben wurden und seither verstaubt sind, tun das nicht und interpretieren PTv2-Routen als PTv1-Route. Das ist in meinen Augen gar nicht so schlimm. Die mir bekannten Tools, die nicht mit PTv2 (oder das ca. 2010/2011 diskutierten Oxomoa-Schema, welches zurückgezogen wurde bzw. in PTv2 aufging) auswerten, widmen sich i.d.R. nur der grafischen Darstellung von Routen.

Eine Unterscheidung benötigen zwischen PTv2 und deinem Entwurf nur bei Routenrelationen. Alle anderen Bereiche könnte man beim bestehenden Tagging lassen und damit Arbeit einsparen. Denn bloßes Ergänzen von p3*=* ist keine Tätigkeit, mit der man Mapper hinter dem Ofen hervorlocken kann.

(3) Diese Flexibilität gefällt mir. Dafür braucht es aber kein grundlegend anderes Schema. Das liese sich jedoch auch an PTv2 anflanschen (z.B. mit type=route, route=train, route:train=tram+train für Zwitter wie die Karlsruher Zweisystemstadtbahnen). Man kann allen komischen Verkehrsmitteln (Rufbus, Schwebebahn, Transrapid usw.) immer irgendein ähnliches System zuordnen.

(4) Mir gefällt das nicht. Derzeit kann der Relationseditor in JOSM (bzw. auch jeder andere Editor könnte es, wenn er es könnte) anhand der Tags des einzufügenden Objekts entscheiden, ob er ihm automatisch die Rolle stop oder platform zuweist. Wenn ich mehrere Bahnsteige an einer Station habe, dann ist im PTv2 die Reihenfolge egal. Mit deinem Schema kann der Editor nicht automatisch eine Rolle vorschlagen. Was die Zerbrechlichkeit angeht, gibt sich das mit PTv2 aber nichts. Wenn ich von einem dreigeteilten Bahnsteig (Damm–Brücke–Damm), den ersten Teil entferne, dann werden mit deinem Schema die beiden übrigen Teile der vorherigen Station zugeordnet. Bei PTv2 muss man hingegen eine stop_position aus der Route entfernen und schon hat man eine Fehlzuordnung. Für mich rechtfertigt das kein neues Schema.

Stattdessen handelst du dir durch den Verzicht auf die stop_positions weitere Probleme ein. Eine stop_position im Straßenway signalisiert dem Pkw-Router, dass da ein Bus anhalten und den Autofahrer zum Halten zwingen könnte (ich kenne noch kein Tag wie bus_passing_place=yes). Im Schienenverkehr (im Busverkehr nur auf Busbahnhöfen mit einer langen Bussteigkante) spielen Haltepositionen eine wichtige Rolle.
Ob meine kurze Regionalbahn in Köln Hbf (Gleis 4/5 486 m) [1], Essen Hbf (Gleis 7, ca. 685 m = ca. 27 Wagen [2]) oder Gößnitz (588 m)) vorn oder hinten am Bahnsteig steht, macht für das Routing beim Umsteigen einen großen Unterschied (1,5 Min./100m bei 4 km/h!). Daher möchte man im Bahnverkehr die Halteposition mit erfassen und in die Route aufnehmen, wenn sie konstant ist bzw. konstant von der selben Routenvariante genutzt wird.

Im Proposaltext von PTv2 findet man übrigens auch das Argument für die Einführung der stop_position – kürzere Verarbeitungszeiten für Auswerter, da man kein Lot mehr auf den Fahrweg fällen muss. Im Rahmen der Qualitätssicherung kann man ja den Abstand von stop_positon und platform (bei Flächen die Außenkante) bestimmen. Wenn dieser das verkehrsmitteltypische Maß überschreitet (Bahnoffset = Lichtraumprofil + 1 Meter Bing-Ungenauigkeit, Busoffset = lanes/2 + 3 m (für Radweg auf dem Bürgersteig zwischen Bordstein und Wartehäuschen)), dann kann ein Validator Alarm schlagen.

(5) Das gefällt mir. An das Problem habe ich bisher noch gar nicht gedacht.

(6) Die Gedanken hinter dem Zusatztags kann ich nachvollziehen. Dafür braucht es aber keine PTv3.

(7) Das gefällt mir. Im Oxomoa-Schema gab es auch ein Gesamthaltestellen-Konstrukt. Diese war aber deutlich komplexer und sehr abstrakt. Seine Mitglieder waren die einzelnen Stop-Area-Relationen, also eine Relation, die Relationen referenziert hat.

Du schreibst: “Die räumliche Zuordnung zum Gebiet (z.B. Bäckerei im Bahnhof) ist kein Grund zur Aufnahme des Objekts in die Relation.” Dem kann ich voll und ganz zustimmen. In Haltestellenrelationen und Gesamthaltestellenrelationen sollten nur Bahnsteige, Haltepositionen, Stationsnode und andere ÖPNV-Kernelemente sein, keine Bäcker, Sitzbänke und Fahrkartenschalter!

(8) Das nenne ich mal Optimismus! Ich habe meine Zweifel, wie lange das gut geht. Wann endet die Übergangszeit? Wie wird man hier reagieren, wenn nach einem Jahr Umstellung ich ankündigen würde, die ersten alten Routen zu löschen, und ein Nutzer sich hier meldet mit dem Argument “Meine Software kann das aber noch nicht.”. Warten wir dann noch länger? ÖPNV ist ein schwieriges Thema. Man kann die Abwärtkompatibilität nicht immer ermöglichen. Wer sich auf kostenlose Daten verlässt, muss damit leben, dass er sich dann an die Daten anpassen muss. So ist das halt. OSM bietet auch keine Premium-Extrakte für Navihersteller an.

Zusammenfassung
Eigentlich gibt es nur drei Gründe, weshalb du einen Entwurf für PTv3 geschrieben hast. Du möchtest allen Mitgliedern eine Rolle zuweisen, Schleifen im Fahrweg erfassen und stop_positions nicht mehr in der Route haben. Sorry, dass ich dir deinen zweiten Entwurf für eine Public-Transport-Reform zerede, aber ich frage mich, ob das den Aufwand einer erneuten Umstellung rechtfertigt. Die Schleifen sind das einzige, was ich für wichtig halte und mit dem Proposaltext von PTv2 inkompatibel ist. Alles andere kann man abwärtskompatibel “anflanschen”.

Können wir uns darauf einigen, erst einmal die Wochenaufgabe voranzutreiben? Danach werde ich dann mit der light_rail-Frage auf der Tagging-Liste aufkreuzen. Roland hat Recht, eins nach dem anderen.

Viele Grüße

Michael

PS Meinst du mit “einfacher als der letzte” den da? :slight_smile:

[1] Doppelbelegung durch mehrere Züge hintereinander
[2] Mehr als 12 bis 14 Wagen haben selbst die längsten Reisezüge nicht.

Das mit den stop_positions hast Du falsch verstanden. Die fallen auch unter “halt”. Ein typischer “halt_fixme” wäre der “railway=station”-Node aus dem keiner sehen kann, ob bei der Ankunft ein Aufzug verfügbar ist. Und ich sehe auch überhaupt keinen Grund, z.B. bei zwei einander gegenüberliegenden Bushaltestellen den einen Node auf der Straße um Steige zu ergänzen.

Es sind schon noch ein paar mehr. Der optionale Route-Master in PTv2 macht z.B. eine Karte mit Richtungspfeile an der passenden Stelle noch schwieriger als ohnehin schon. Einige Kleinigkeiten – z.B. was optional ist und was nicht – erlauben anderen Checks und andere Programme.

Ich nicht. Es ist Pessimismus, weil ich gesehen habe, was aus dem PTv2 geworden ist und noch mehr aus dem PTv1. Wir haben im Gegensatz zu den ÖPNV-Anbietern keine Karten mit Richtungspfeilen mehr.

bis dann
Weide


Der Pessimist sagt: Das Glas ist halb leer.
Der Optimist sagt: Das Glas ist halb voll.
Der Techniker sagt: Man hätte ein halb so großen Glas nehmen können.

Nein. Es geht in PTv2 gar nicht, weil es mehrere Haltestellen wären. Zwei Halte an verschiedenen Steigen einer Haltestelle kommen bei Bussen sogar ziemlich oft vor. Nur das Päärchen stop mit direkt darauf folgendem platform bildet einen Halt. Egal was man danach dran hängt – es ist ein neuer Halt.

Weide

Ich kann deine Auffassung sehr gut verstehen! Aber es ist eben nicht möglich einer Route immer eine eindeutige Halteposition zuzuweisen!
Hier bei der S und Straßenbahn in Berlin verkehren Züge unterschiedlicher Länge auf der gleichen Route. Und allein diese Zuglänge entscheidet wo der Zug halten wird.

Wenn man die Haltepositionen wirklich nutzen wollte, dann bräuchte man aber noch ein Tag “diese_stop_position_ist_ausnahmsweise_ernst_zu_nehmen” :slight_smile:

Und wir haben auch noch solche Sachen wie die “Untersteignummern” in Mainz Hbf, jwd-Steige in Essen Hbf, ungenutzte(?) lange Steigteile, die eigentlich nur einen Ausgang anbinden sollen in Duisburg Hbf oder die zentrale Steiginsel vieler Busbahnhöfe, die eigentlich 6 oder 8 Steige haben müsste, aber als ein Steig gemappt wird. Ich hab da mal was eingebaut, was ohne große Änderungen rein ging.

bis dann
Weide

Hallo Weide, hallo viw,

Kannst du das mal bitte mit einem Zitat aus dem Proposal belegen? Der Proposal-Text trifft dazu keine Aussage. Meiner Meinung nach wäre stop1–platform1–stop2–platform2a–platform2b–platform2c–stop3–platform3–… erlaubt und platform2a, platform2b und platform2c würden zu stop2 gehören.

Solltest du doch recht haben, so kann man immer noch in einem PTv2.1 eine Rolle “+platform” einfügen.

Wir sind uns aber einig, dass unterschiedliche Zuglängen zu unterschiedlichen Tageszeiten keine Duplikation von Routen rechtfertigen, oder? Die Haltepositionen von Schnellbahnen orientieren sich oft an den Bahnsteigzugängen. Wenn der Bahnsteigzugang hinten ist, wird mit Haltetafeln (bei EBO-Bahnen das Signal Ne5 [1]) gekennzeichnet, wo die Züge welcher Länge halten sollen. Nur Züge voller Länge (in Berlin 4/4-Züge) halten auf der ganzen Länge.

Da ist Intelligenz vom Auswerter und Fahrgast (Nutzer) gefragt, sodass er erkennt: “Ah! Langer Zug, da muss ich für’s schnelle Umsteigen am nächsten Bahnhof hinten einsteigen.”

Hast du dir mal das Mapping der Bahnsteige in Euskirchen angeschaut? Diese Konzept wäre mein Vorschlag. Bahnsteige mit Unternummern (eigentlich auch Bahnsteige mit mehr als einer Kante, d.h. die meisten Inselbahnsteige [2]) sind Multipolygone. Alle Tags außer die Gleisnummer hängen am Multipolygon. Das Multipolygon hat mehrere outer-Ways (Rolle outer) – die Bahnsteigkanten und die “kurzen Seiten”, an denen keine Züge halten. Die Bahnsteigkanten-Ways erhalten ref=. Bahnsteigabschnitte (A, B, C,), wie es sie in Deutschland, der Schweiz und anderen Ländern gibt, können als Node auf die Kante gemappt werden, wenn nur die Position des Schilds [3], aber nicht dessen Gültigkeit genau bekannt ist. Diese Konzept ist auf dem Mappingwochenende in Köln im Juli entstanden.

Viele Grüße

Michael

[1] https://github.com/Nakaner/railway-signals/blob/master/DE/EBO/Ne5_DS301.svg und https://github.com/Nakaner/railway-signals/blob/master/DE/EBO/Ne5_DV301.svg
[2] Manche Inselbahnsteige haben nur eine Kante, z.B. Möckmühl Gleis 2 und 3.
[3] Die Schilder werden häufig dort montiert, wo es gerade geschickt ist, z.B. an Trägern der Bahnsteigüberdachung. Daher ist ihre Lage nicht die genaue Mitte des Abschnitts.

Wie willst du das bei Bahnsteigen ohne H-Tafel machen? In Dortmund-Hörde hält die Eurobahn, wo sie will. Mal zu weit vorne, mal zu weit hinten und bei Doppeltraktion gaaanz weit hinten.

Ähm genau das habe ich jetzt aus deinem Vorschlag nicht so richtig entnehmen können. Welchen Vorteil hat die Stopposition, wenn Sie doch nicht genau bestimmt werden kann? Du hast recht das es für die Umsteigewege von Vorteil ist hinten oder vorne einsteigen zu können, aber wo ist denn jetzt bei einen 2/4 Zug vorne und noch schlimmer wo ist denn hinten?

Each stop is included with two elements (if available): first the stop_position tagged with role stop and immediately followed by the corresponding platform tagged with role platform.

bis dann
Weide

Ok, danke. Du hast deine Aussage belegt.

Äh, ja, gefällt mir nicht. Wenn die Routen auf die outer-Stücke zeigen, dann zeigen sie nicht auf platforms und das sollte Fehlermeldungen triggern. Man sollte auch den Namen eintragen können und wenn der mal dargestellt wird, dann sollte er auch im Stil von Platforms dargestellt werden. Taggt man sowohl die Stücke als auch das MP als platform, dann sind zuviele Platforms in dem Bahnhof. Da würde ich schon eher die Bahnsteigfläche als highway=pedestrian machen (wo möglich ohne MP) und an den passenden Stücken über dieselben Nodes oder etwas nach innen versetzt die Platforms als Linien. Das wäre auch auf die Bahnsteiginseln der Busse anwendbar, die gewöhnlich keine MPs sind.

bis dann
Weide

PS: area=yes an den MPs ist falsch (steht so im PTv2, aber PTv2 zählt da nicht)
PPS: Es sollten zwei stop_areas sein, da die Namen verschieden sind.

Es wird sich aber allermeist eine Stelle am Bahnsteig finden lassen wo sich garantiert ein Zug befindet, oder? So Regel: “der Mittelpunkt der kürzesten Zugvariante”?

Hallo Weide,

Ja, klar. In so einem Fall sollten die platform-Member-Einträge in den Routenrelationen auf das Multipolygon zeigen. In Euskirchen ist kein Bahnsteig Teil einer Routenrelation. (habe gerade eben extra nachgeschaut)

Du meinst also, dass man den Bahnhofsnamen an das Bahnsteig-Multipolygon taggen können sollte? Das ist doch möglich. Das wird dir im JOSM-Routeneditor dann als “Multipolygon (Euskirchen)” angezeigt.

Das Taggen von Gleisnummern an die Bahnsteigkante ist auch kein Problem für Renderer, die die Gleisnummer mitten in der Bahnsteigfläche rendern wollen. Die müssen einfach nur schauen, welche Gleisnummern auf die Mitglieder des Multipolygons getaggt sind (ref=* [1]) und diese sortieren und zu einem Label-String verketten.

Ja, genauso wie ich bei einem Wald-Multipolygon mit zwei Outer-Mitgliedern (jeweils nicht geschlossene Ways, die zusammen einen Ring ergeben) nicht die beiden Ways zusätzlich zum Multipolygon mit landuse=forest tagge.

Ich bin keine Freund von highway=pedestrian auf Eisenbahnsteigen. Bei der DB sind wir es gewohnt, dass man Bahnsteige einfach so betreten kann. In anderen Ländern gibt es jedoch Bahnsteigsperren (AFAIK gibt es im Hamburger Verkehrsverbund sogar noch “Bahnsteigkarten”). highway=pedestrian sollte von einem Mappingschema nur vorsichtig empfohlen werden, da es von Routern gegenüber railway/public_transport=platform bevorzugt wird.

Das Taggen der Gleisnummer an die Bahnsteigkante erleichtert das Blindenrouting in Bahnhöfen. In den Fahrplandaten ist vermerkt, auf welchem Gleis der Zug hält. Bei einem Inselbahnsteig gibt es jedoch meistens zwei Bahnsteigkanten. In welche Richtung soll nun der Blinde gehen, wenn der den Treppenaufgang hochkommt? Mit Gleisnummern auf der Bahnsteigkante kann das Smartphone sagen: “Benutzen Sie den Aufzug zur Gleisebene hoch und halten Sie sich dann nach links.” Außerdem erleichtert es die Kartenanzeige eines Indoor-Routingergebnisses für sehende Nutzer.

area=yes ist entweder Mapping for the Renderer oder Mapping for Osm2pgsql. Ich habe beobachtet, dass Multipolygonbahnsteige ohne area=yes als Linie statt als Fläche gerendert werden. Du hast aber trotzdem recht.

Viele Grüße

Michael

[1] local_ref=* wäre vielleicht besser, da ref=* durch eine netzweit einheitliche Bahnsteigkanten-ID belegt sein könnte.

Schade das Segmente nicht in dieser Version aufgenommen werden. Muss ich noch mal etwa 10 Jahre warten um das reifen zu lassen, oder doch einmal selber ein Vorschlag machen.

Ich habe Begriff dafür das Relationen in Relationen einige zusätzliche Komplexität bringen, andererseits würde es die Wartung ungeheuer viel vereinfachen. Ich habe versucht eine MapCSS zu erstellen die mit Segmente arbeiten kann, aber ich kann keine tags von Grosseltern betrachten.

Nah gut. Ich bin damit beschäftigt ein Skript zu bauen das v2 Routerelationen erfassen kann:

https://github.com/PolyglotOpenstreetmap/Python-scripts-to-automate-JOSM/commit/791a38b2b30d27b2e7d5453a9c681806ab4d581f

Es benutzt der scripting-plugin und Jython. Es läuft im JOSM.

Ich weiss nicht ob ihr in Deutschland angriff habt auf der Daten des Operators?

Das Skript fängt an mit eine geordnete Reihenfolge von Haltestellen. Es geht davon aus das alle Haltestellen auf Nodes gemappt sind. Ist das noch so in ihren Vorschlag?

  • Es versucht zuerst eine Relation zu finden die eine gleiche Reihenfolge von HS hat. Wenn es die findet, benutzt es die Ways von der mit der längste Reihenfolge.

*Das skript geht auch davon aus das alle Ways zusammen stehen, und alle HS auch. Das ist wie JOSM solche Routerelationen automatisch sortiert, deswegen schien mir das eine gute Konvention. Irgendwie wäre es natürlich einfacher HS mit ways zu verknupfen wenn die HS dazwischen stehen. Dan kann man aber nicht mehr visuell nachschauen ob die Ways eine ununterbrochen Sequenz sind.
*

*Wenn keine vergleichbare Route gefunden werd, dann versucht es mit dem letzten Way die nächste HS zu bereichen anhand irgendeine andere v2 Route. Die Büsse haben jedenfalls tendenz alle dieselbe “Korridors” zu benutzen.

*Wenn das nichts aufbringt, noch mal neu von alle Seitstrassen.

*Als letzte Lösung wird versucht einen gültigen Way zu finden neben die HS. Entweder mit Hilfe von Stop_area Relation, oder der näheste stop_position. So war ich etwa 2 Jahre her angefangen und es hilf, nur ist es sehr langweilig alle Variante so hinzuzufügen.

Das andere Problem ist natürlich die Wartung. Diese Variationen von Routen änderen sich ziemlich oft und die Relationen werden von andere benutzer ständig kaputtgemacht. Auch dafur (ver)suche ich eine halbautomatisierte oder so weit wie möglich automatisierte Lösung (zu entwickeln).

Könnt ihr mich befestigen ob meinen Ahnnahmen stimmen?
*HS nur auf Nodes
*Alle Wege zusammen im Route. Wenn der bus zwei mal über demselben Weg fährt, kommt er 2x vor im Relation
*Dann eine sortierte Reihenfolge des HSs? Wenn der bus zwei mal an dieselbe HS vorbeifährt, kommt sie 2x vor im Relation

Polyglot

Dann hab ich das total missverstanden. Ich dachte, die Routen sollen auf die Teile zeigen.

Da bin ich Fundamentalist. MPs sollten nichts mit dem Inhalt ihrer Member zu tun haben. Nur die Geometrie der Linien zählt. Irgendwann beim nächsten API müssen wir die MPs automatisch durch Flächenobjekte ersetzen und das beisst sich damit.

Technisch ist es sehr einfach: Man definiert einen Segmentrelationstyp ohne eigene Eigenschaften und eine “include_halts”- und eine “include_tour”-Rolle innerhalb der p3=variant - Relationen.

Ähm ja es gibt eine Stelle Am Bahnsteig wo garantiert ein Wagen eines S-Bahnzuges halten wird. Aber das ist eben nicht die zwangsläufig die Mitte. Und bei Straßenbahnen ist es ohnehin sehr fraglich. Dort gibt es das Phänomen der Doppelhaltestellen.

Ich weiss, nur wenn die Möglichkeit nicht im Vorschlag aufgenommen wird, wird überhaupt keiner Datennutzer das auch benutzen/auf der Karte darstellen. Mit dem Skript das ich jetzt entwickle wird die Wartung schon etwas niedriger. Nicht mit Routesegmente arbeiten hat das Vorteil dass man sofort visuell beobachten kann, ob die Linie nicht unterbrochen würde. Das kann ich aber viel schneller automatisiert entscheiden.

*Segmente könnten aber (langweiliger) Mapperarbeit sparen
*Es wäre auch möglich um Spiderdiagramme ab zu bilden, wenn auf die Segmente einige zusätzliche tags gesetzt werden wie route_ref und colour. Sogar in JOSM mit MapCSS. Das ist etwas das wir bis jetzt noch nicht machen konnten.

Ist es bitte möglich erst die ways und danach die HS in Routerelationen auf zu nehmen? Das ist wie JOSM die sortieren würde. (Oder die JOSM-entwickler davon überzeugen es umgekehrt zu tun.) Ich mag es aber das ich sofort aur die Ways arbeiten kann. Die HS werden hier automatisiert hinzugefügt.