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.
Es kann auch Edit-Wars geben, weil verschiedene Mapper sich auf verschiedene Quellen berufen.
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?
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.
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.
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.
Was die stop_area Relation angeht war ich sehr froh mit ihrem Vorschlag für v3. Wir machen es schon so.
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.
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
- Eine für die Büsse von De Lijn:
https://www.openstreetmap.org/relation/4299252 - Eine für die Trams von De Lijn:
https://www.openstreetmap.org/relation/4299241 - Und das Bahnhof von NMBS:
https://www.openstreetmap.org/relation/4299253
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 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
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