Diskussion über Public Transport Version 2.1

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

Ich möchte gerne wissen was nicht v2 dran ist. Eine Routerelation pro Variante, check, Platforme sind gemapt mit public_transport=platform/bus=yes. check. Der Validator von JOSM ist froh damit. Und ich kann die alle verwalten mit ein Pythonprogramm, weil es ausreichend konsistent ist für automatische Verwaltung.

Jo

Es werden sicher auch stop_position gemappt. Das wichtigste sind aber die highway=bus_stop/public_transport=platform/bus=yes. Die sind jetzt alle da.

Wenn public_transport=stop_area gemacht werden, werden auch die stop_position erfasst. Wenn etwas anderes am highway gemappt werden muss, werden die auch gemappt. In die Routerelationen sind die aber nicht notwendig. Sie machen es nur schwieriger und als die jedenfalls nicht alle da sind…

Als es eine stop_area pro highway=bus_stop/public_transport=platform/bus=yes gibt, ist es einfach zu ermitteln welche stop_position(en) dazu gehört/en.

Grüsse,

Jo

Each route relation has all the stops at the end.

Ist im direkten Gegensatz zu dem im PTv2 angegebenen.

To keep the number of variants limited we only have a variant for the longest…

Nach PTv2 sollen alle Varianten gemappt werden.

Stop-Areas sind völlig anders. Die im PTv2 haben mehr Ähnlichkeit mit Euern stop_area_groups, nur ohne die zweite Relationsebene dazwischen.

To keep things simple and manageable all bus and tram stops in Belgium are mapped on nodes.

In case a platform is present, this can be entered as a way or an area.

Dann sind die Platforms doppelt vorhanden.

These nodes don’t get extra information like name…
Dann kann man sie nicht in die Routen stecken, was ausdrücklich von PTv2 gefordert wird. Würde man sie dann doch dort erfassen, dann hätten sie daher einen anderen Namen und wären getrennte Haltestellen. Die Haltestellenliste wäre dann falsch.

Es wird auf die Beschreibung des Bus- und Tram-Linien-Mappings für Belgien verwiesen. Dort steht:
*Stops don’t need roles. *

Das ist ein direktes Verbot der Aufnahme von Way-Platforms. Die könnte man dann nicht mehr von Fahrwegen unterscheiden.

Weide

Bin mal auf wiki gucken gegangen, sogar die Historie angesehen und es steht da tatsächlich. Erst Stops, dann Ways. Damals habe ich das nicht gesehen. Schade es gefällt mir wie wir es jetzt machen. Die Haltestellen werden automatisch erfasst. Die Ways manuell, es ist praktisch die erst zu haben.

Was alle Varianten angeht. Ich bin ein Minimalist der auch den Aufwand für die Wartung zu ein minimum zurückbringen will. Deswegen diese Entscheidung. Es gibt etwa 1000 Linien für das Norten des Landes alleine. 2-50 Variante für jede Linie (wie ich die zähle). Es gibt nicht soviele Leute die sich mit ÖPNV beschäftigen wollen, also jede gesparte Aufwand ist eine gute Sache.

Was die stop_area Relation angeht war ich sehr froh mit ihrem Vorschlag für v3. Wir machen es schon so.

Ich habe die andere Seite nicht mehr nachgelesen. HS bekommen jetzt alle die Rolle platform, weil alle umgewandelt sind auf highway=bus_stop,public_transport=platform, bus/tram=yes.

Vielleicht wäre es besser wenn die Nodes die jetzt public_transport=platform bekommen, public_transport=pole bekommen würden, wenigstens wäre das deutlicher. Mir macht es kein Unterschied dass zwei mal platform vorhanden sind. Wenn gemappt auf way, area oder MP ist das ein Steig. Wenn gemappt auf ein Node ist das der Node der alle Details enthalt für diese HS.

Welche Version sollte ich drauf kleben? 1.5, 2.5, 3.5, BE3.14? Ich benutze jetzt 2. Mein Skript considers alle Routes mit Version über 2 wo die Ways nicht unterbrochen sind als golden, und kopiert Wege davon wenn die Reihenfolge des HS übereinstimmt. Ich habe endlich eine Hilfe um die Wartung zu ermöchlichen.

Jetzt werde ich mal eine Relation in Aachen ‘verbessern’. Auch dort sind die Ways erst, dann die HS, und ich hatte die noch nicht vorher bearbeitet.

Manche HS waren neben der Weg gemappt, andere als Node auf dem Weg im Route 21. Es wird noch nicht einfach sein diese 2 Schemata zu einigen für Routes die über die Grenze gehen.

Ja, es wäre genauso gut gewesen, wenn es im PTv2 anders herum gestanden hätte. Aber jetzt ist es so und das hat Folgen.

Jetzt darf z.B. ein Programm zum Extrahieren der Haltestellen den Rest der Relation überspringen wenn der erste Fahrweg-Eintrag kommt. Das zu tun ist sogar sinnvoll, denn in PBF-Dateien ist das Überspringen sehr zeitsparend. Viele Programme bei OSM laufen täglich und da ist es ein riesiger Unterschied, oft sie 2 Stunden oder 20 Stunden brauchen.

Es kann auch Edit-Wars geben, weil verschiedene Mapper sich auf verschiedene Quellen berufen.

Wenn ein Mapper entscheidet, dass er abgekürzte Varianten nicht eintragen will, dann ist das völlig OK. Auch wenn viele Mapper das tun, ist es völlig OK.

Ein Problem ist es aber, das zu verbieten. Nach PTv2 darf und soll man es. Wenn ein Mapper sieht, dass eine Variante fehlt und sie einträgt (richtig nach PTv2) und ein anderer löscht sie, weil es so in dem Papier steht, dann haben wir einen Edit-War. Und da muss man klar sagen: solange PTv2 dran steht ist das Eintragen des ersten Mappers richtig und das Löschen durch den zweiten falsch.

Nein. Beispiel: Ein Bahnhof “Pusemuckel” hat 4 Bahnsteige (1 bis 4). Auf der einen Seite ist ein Busbahnhof “Pusemuckel Bahnhof” mit 8 Bussteigen (1 bis 8). Auf der anderen Seite ist ein Busbahnhof “Pusemuckel Bahnhof/Westseite” mit 3 Bussteigen (1 bis 3).

-Nach PTv2BE sind es 15 Stop-Areas und ? stop_area_groups.
-Nach PTv2 sind es 3 Stop_Areas.
-Nach meinem Vorschlag sind es drei Stop-Areas und eine Stop_Area-Group.

Wenn eine zweite Platform da ist, dann darf ein Mapper sie auch in einer Route benutzen. (Er darf nicht beide Platforms benutzen, das wären dann zwei Halte und falsch.) Jetzt kann man aber an der einzelnen Platform eventuell nicht mehr alle Routen erkennen, weil einige auf der anderen Platform liegen.

Man kann nicht vorhersehen wie die Datenbank benutzt wird. Deshalb sollten die Sachen stimmen – egal ob man einem ein Problem mit falschen Einträgen einfällt oder nicht.

Weide

M.E. ist das meist wichtige dass es bequem ist für Mapper um die zu überarbeiten. Es gibt nicht viele Mapper die sich am PT interessieren, für die Wenige die es gibt muss es so angenähm wie möglich sein. Ein Komputerprogramma würde ich nie so schreiben dass es aufhört mit dem Processing in der Mitte von eine Relation. Es gibt immer die Möglichkeit das ein iD-Benutzer eine HS am Ende hinzugefügt hat, meistens ohne es sich zu realisieren. Die Optimalisazion für Programme sollte darin bestehen die Datenmenge so klein wie möglich zu halten. Das machen wir aber sowieso nicht mit unsere lange Tagnamen und vielfalt duplizierte Daten.

Da hast du Recht. Das ist ein Problem. Wäre es möglich um die Reihenfolge für v3 um zu drehen? Oder ist sowas ausgeschlossen?

Verboten habe ich es ja nicht. Das Skript das die Daten umwandelt, stellt die kurzere Variante von “Teleskoplinien” aber nicht zur Verfügung. Dieses Skript spart Mapper soviel Zeit (weil es nicht mehr notwendig ist, stundenlang Fahrpläne zu bestudieren um aus zu finden welche Variante es gibt. Es wäre wenig sinnvoll nicht gebrauchzumachen von die praktische Lösung. Ich kenne genau 1 Mapper der das vor einige Jahren für 2 Linien gemacht hat. Er hat das aber zeitdem nicht mehr neu gemacht und De Lijn ändert das ständige kleinere oder grossere sachen dran. Desto mehr Varianten wir beschreiben, desto mehr Arbeit der oft nicht gemacht wird.

Nein. Beispiel: Ein Bahnhof “Pusemuckel” hat 4 Bahnsteige (1 bis 4). Auf der einen Seite ist ein Busbahnhof “Pusemuckel Bahnhof” mit 8 Bussteigen (1 bis 8). Auf der anderen Seite ist ein Busbahnhof “Pusemuckel Bahnhof/Westseite” mit 3 Bussteigen (1 bis 3).

Für mich ist es einfacher um das zu illustrieren an Hand Beispiele.

Also habe ich mal Bahnhof in Oostende und Haltestellengruppe Gent Zuid überarbeitet.

In Oostende gibt es 3 Bahnhofe

Die sind dann wieder zusammgefasst in:
https://www.openstreetmap.org/relation/4299254

Es gibt auch ein Ferryterminal. Darüber fehlen mir aber die Daten, sonnst würde der auch ein Eintrag bekommen in die letzte Relation.

Gent Zuid hat Gleise für Tram und viele Steige für Büse.

Die sind durchnumeriert, also reicht eine Relation um die zu grupieren:

https://www.openstreetmap.org/relation/4307993

(In Oostende ist es eine Ausnahme dass die Gleise vom Tram ihre eigene Sequenz für Numerierung haben. Das ist historisch so gekommen und es wird warscheinlich nicht mehr so sein nachdem das ganze in welche Jahren umgebaut wird zu einem völlig integrierten Bahnhof.)

Wenn man in ein ganzes Land der Regel hat um die Platforme die auf Ways un MPs gemappt sind nicht in die Routerelationen auf zu nehmen, dann ist da keine Verwirrung möglich. Wir sind hier angefangen HS nur auf Nodes zu mappen und es wäre sehr schwierig um das jetzt noch zu ändern. Ich bleibe dabei dass es besser gewesen wäre um diese Nodes nicht public_transport=platform zu vergeben.

Jetzt haben wir Nodes getaggt mit highway=bus_stop, public_transport=platform, bus/tram=yes welche alle Details enthalten.
Und Ways und MPs getaggt mit public_transport=platform, bus/tram=yes, highway/railway=platform, die angeben wo es in der Wirklichkeit Steige (Platforms) gibt.
Etwas verwirrend dass 2x public_transport=platform dafür benutzt wird, aber es ist unproblematisch um die 2 auseinander zu halten.

Das einzige Problem ist denn aber wo Routes über die Grenzen gehen, sowie in Aachen, Breda, Dunkerque. Da wird eine stop_area benötigt um die zu verbinden. Das funkzioniert natürlich nur, wenn es genau 1 stop_area pro HS gibt. Ist es möglich um das so vor zu schlagen für V3?

Die Segmentrouten habe ich jetzt selber auch aufgegeben. Ich entwickle einen Skript dass die Arbeit um die zu Warten/Unterhalten (maintenance) ungeheuer leichter macht. Es ist noch nicht völlig fertig, aber es spart schon viel Zeit.

Der nächsten Schritt ist dann eine Art webservice der angibt wo Wartung benötigt ist.

Frohe Weihnachten,

Jo

ausgeschlossen ist bei OSM nichts. Aber die Frage ist ob man die “abwärtskompatibilität” einfach so aufgeben möchte. Die Frage ist welchen Aufwand macht es dein Programm anzupassen? vielleicht kann man mit Version 3 einfach die Position der Haltestellen am “anderen Ende” einfach zu lassen, ohne es explizit zu fordern.

Weihnachten ruft … deshalb nur ganz kurz…

Beim Bus gäbe es nach PTv2 nur eine stop_area mit allen 28 Platforms und allen 14 stop_positions. Alle 42 Elemente und die stop_area hätten “name=Oostende Station”. Der Busbahnhof wäre also eine stop_area und nicht eine stop_area_group mit 14 stop_areas.

frohe Weihnacht und guten Rutsch
Weide

Ich weiss. Wenn das aber alles so auf einem Häufen geschmissen wird, kann nicht mehr daraus abgeleitet werden was zueinander gehört. Dann kann man auch einfach keinen stop_area machen und alles geometrisch ableiten (versuchen).

Jo

Da ist nichts ausgeschlossen, wir bestimmen das ja alle zusammen.

In meinem Vorschlag ist aber zentral, dass die alten Relationen bleiben bis zumindest die wichtigsten Renderer beides können. Das Problem mit der Reihenfolge bleibt also – egal ob ich das in meinem Vorschlag ändere oder nicht.

Weide