Diskussion über Public Transport Version 2.1

Ä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.

Es ist doch gut wenn man sehen kann, dass jemand die Relation kaputt gemacht hat. Die JOSM-Sortierung auf die Haltestellen anzuwenden ist immer Quatsch. Bei den Wegen funktioniert es nur bei einfachen Routen. Und ich kenne viele Routen bei denen es richtig viel Arbeit ist, sie nach einer automatischen Sortierung wieder zu berichtigen.

Ich würde die JOSM-Leute eher fragen, ob man die Sortierung nicht abschalten kann, wenn Haltestellen mit sortiert würden und ob sie nicht die Sortierung total verweigern könnten, wenn es keine eindeutige Lösung gibt.

Weide

Ich benutze die Sortierung innerhalb Relation Editor nicht mehr für eine ganze Route. Für Teile ist sie aber wohl praktisch. Also Klik, Shift-Klik etwas weiter, dann sortieren. Die HS werden normalerweise nicht berurt. Die Reihenfolge sollte gleich bleiben. Üblicherweise selektiere ich aber nur Ways.

Mein Skript fügt Sequenznummer ein für Ways die es hinzufügt. Das macht es auch etwas einfacher.

Vielleicht möchtest du es mal ausprobieren. Hast du irgendwo eine Route von welche alle HS auf Nodes gemappt sind?

https://github.com/PolyglotOpenstreetmap/Python-scripts-to-automate-JOSM/blob/master/FindWaysBelongingToRoutesStartingFromStops.jy

Wenn du Lust hast, will ich es auch mal demonstrieren in eine Google Hangout. Es fängt an recht praktisch zu funktionieren… Findet Ways in andere Routen wenn die schon auf Version 2 stehen und ihre Wege nicht unterbrochen sind. Wenn keine andere Routen vorhanden sind, fügt es nur die anliegende Ways zu. Wenigstens hat man dann schon diese Ways in richtige Reihenfolge und versehen von Sequenznummer. Wenn man damit anfängt, muss man dan diese Ways noch verbinden, aber einmal eine Gegend gute Referenzrouten hat, kann das Skript stehts mehr selber zusammenstellen.

Jo

Mal deine letzte changeset angeguckt:

https://www.openstreetmap.org/changeset/27592324#map=16/51.2864/6.3710

Jetzt verstehe ich wieso es kein Reaktion kommt auf meinem Skript. Ihr mappt PT grundsätzlich anders als wir/ich. Ich habe es in Belgien alles konsistent auf ein System umgewandelt. (In Brüssel bin ich noch nicht ganz fertig) Ein System das aber wohl funkzioniert. Wenn ich mir das so ansehe, seit ihr noch halbwegs zwischen PT v2 und PT v1. Ich habe natürlich nur ein Beispiel gesehen. Hast du vielleicht irgendwo bessere Beispiele? Damit meine ich, die HS neben der Weg gemappt, am liebsten auf Nodes.

Hier in Belgien sind wir so angefangen, weil jede HS ein Referenznummer hat, das auf die Schilder angedeutet steht (wenigstens in Flandern). Deswegen hat es für uns nie Sinn gemacht HS als Node auf dem Weg zu mappen. Und deswegen sind alle Details auch auf diesen Nodes neben dem Weg.

Vielleicht müsste ich mal in England gucken gehen. Sehen wie die es machen.

Grüsse,

Jo

:slight_smile: So schlecht liegen wir garnicht im Rennen. Mein Programm liefert jetzt für den Regierungsbezirk Düsseldorf in Nordrhein-Westfalen noch 6408 Fehlermeldungen und für Belgien 16231 :slight_smile: Aber Belgien ist ja auch deutlich größer. :slight_smile:

bis dann
Weide

Edit: falsche Zahl korrigiert

Kann ich die Fehlermeldungen irgendwo mal sehen? Oder das Programm?

Ich komm mal in Düsseldorf schauen, wenn ich fertig bin mit dem korrigieren von Linien 1-9 in Brugge.

Jo

Wenn Du mir eine Nachricht schickst, dann kann ich per E-Mail-Antwort mit Attachment die Liste schicken. Das Programm kannst Du auch haben; ich habe aber nur Executables für Linux (x86-64). Für die Quellen bräuchte man einen Ada-Compiler.

bis dann
Wilhelm

Ich habe mal dokumentiert wie wir das hier in Belgien mappen, basiert auf dem Artikel im Wochenaufgabe:

http://osm.be/nl/content/mapping-public-transport-belgium#

Hallo Polyglot,

Was das Tagging der Routen betrifft, finde ich bloß zwei Unterschiede. Ihr habt die Haltestellen am Ende der Relation eingereiht, wir am Anfang. Bei euch gibt es keine stop_positions (mit der Rolle stop) in der Route, bei uns schon.

Sehe ich es richtig, dass ihr keine stop_positions mappt?

Kennst du schon das Tag fee_zone=*? Im Gebiet des Verkehrs- und Tarifverbunds Stuttgart (VVS) wird mit diesem Tag (an Bahnhof-Nodes, Haltepositionen, Bushaltestellen, stop_area-Relationen) die Tarifzone(n)/Tarifwabe(n), in denen die Station liegt angegeben. Es scheint das Stuttgarter Äquivalent zu zone:De_Lijn=85 zu sein, oder?

Im Karlsruher Verkehrsverbund (KVV) wird das Verbundsgebiet als (Multi-)Polygon erfasst:
abbreviation=KVV
boundary=public_transport
name=Karlsruher Verkehrsverbund
type=boundary
wikidata=Q1733986
https://www.openstreetmap.org/relation/3157173/history

Viele Grüße

Michael

Das ist kein PTv2. Es wäre gut, wenn ihr es irgendwie markieren könntet.

Weide