[Talk-de] Wiki Nicht-Streitpunkt public_transport name/ref

Wilhelm Spickermann osm at spickermann-d.de
Mo Jul 22 06:23:39 UTC 2013


Am Mon, 22 Jul 2013 02:20:25 +0200
schrieb Tirkon <tirkon33 at yahoo.de>:

> Bei Bahnsteigen mit Gleisen auf beiden Seiten wird nicht klar, auf
> welcher Seite der Fahrgast seine Bahn zu erwarten hat.

In der betreffenden Variante unbenutzte Steige kommen ja nicht in die
Relation.

> Die Values für Komplettheit müssten noch einen Wert für "fraglich"
> zulassen, möglicherweise "?".

Das ist der Default. Aber vielleicht sollte ich einen expliziten Wert
vorsehen. 

> >To be able to map platform nodes with unknown properties, the tag
> >>public_transport=any_platform is added to the set of values. This
> >>tag corresponds to highway=bus_stop and alike even in the case of
> >>nodes. 
> >For ways and areas it's the same as public_transport=platform.
> 
> Verstehe ich nicht. Was sagt "public_transport=any_platform" aus? Und
> zu welcher Menge von Werten wird das hinzugefügt. (eventuell Beispiel)
> Der Key "public_transport" kann doch nur einen Wert haben. Und wann
> wird stattdessen "highway=bus_stop" oder "public_transport=platform"
> getaggt. Was passiert dann mit der erwähnten Menge von Werten? 

Es sollen nicht mehrere Werte zum Key angegeben werden -- es gibt einen
zusätzlichen Wert. Zur Menge der zulässigen Werte (platform,
stop_position) wird also einer hinzugefügt. Dann haben wir
(any_platform, platform, stop_position).
Der Unterschied zwischen "platform" und "any_platform" ist, dass
any_platform nichts über die Art des Steigs aussagt. "Platform" besagt
ja laut Public Transport Proposal bei einem Node, dass dort kein Steig
vorhanden ist. Man kann also zur Zeit die ganzen alten highway=bus_stop
Nodes neben der Fahrbahn nicht durch ein "public_transport=irgendwas"
ergänzen, da keine der bisherigen Möglichkeiten passt. Dann können die
verarbeitenden Programme aber auch nicht umgestellt werden.

> 
> >pt2_subname A name as found on the splot ...
> Die Bedeutung der Vokabel "splot" konnte ich nicht ergründen.

"vor Ort". Man soll sich da nichts ausdenken, sondern nur nehmen was da
vor Ort angegeben ist. 

> 
> >pt2_subname=? value is unknown, but there is one
> >....
> >pt2_subname omitted: unknown
> Wo ist der Unterschied zwischen den beiden Alternativen? Weiß ich beim
> der zweiten weder den Wert, noch dass ein Wert existiert?

Genau.

> >vehicle The vehicle kind(s) used. 
> Vehicle macht mir etwas Bauchschmerzen, weil es von der "Acess"
> Wikiseite stammt, die ihrerseits inkonsistent ist. Geht aber
> vermutlich.

Man könnte es umbenennen. Aber eigentlich definiert der Relationstyp
die Bedeutung seiner Tags und was woanders ist, beißt sich damit nicht.
Das ist eigentlich nicht anders als bei "name". Da definiert der
Objekttyp ja auch, was da benannt wird.

> 
> >*_exit_only and role : *_entry_only are not really useful as first 
> >and last stop markers and for intermediate stops they are not 
> >needed as time table routing doesn't use them.
> Hmm, man sollte aber schon wissen, dass man an einer Haltestelle nicht
> einsteigen kann - insbesondere wenn es nicht die letzte ist.

Ja, da gibt es drei Fälle.

1.: Anfang und Ende der Linie. Das wird von vielen Mappern weggelassen,
ist aber relevant bei Folgelinien "Sie können sitzen bleiben, wir
fahren weiter als 456". Das habe ich in "follow_up_ref" gesteckt.

2.: Reine Ausstiegshaltestellen. Da sollte es an der Haltestelle
vermerkt sein.

3.: Restriktionen der Tickets. Bei Schlafwagen gilt oft die Regel, dass
nur Übernachtungspassiere zugelassen sind. Bei allen
Abend-Haltestellen darf man nur einsteigen und bei allen
Morgenhaltestellen nur aussteigen. Das sind aber eigentlich
Bestandteile des Fahrplans/Ticketverkaufs.


> Variants - Member roles
> haltvar bis part+ sind Rollen von ways der Route, halt sowie +halt
> sind Rollen von nodes der Haltestellen. Ist das richtig? Wenn ja,
> könnte das im Text - eventuell durch Überschriften - noch
> verdeutlichst werden.

Also die Überschrift "Member Roles" ist ja da. Ich wollte die einzelnen
Roles eigentlich deutlicher markieren (und in meinem LaTeX-Original hab
ich das auch) durch glossarartige Einrückungen. Ich habe es aber nicht
hinbekommen, dass da auch weitere Absätze mit eingerückt werden. Wenn
mir da jemand sagen kann, wie das geht, dann mach ich das sofort.


> Ich fasse das Ganze für eine einfache Standard-Buslinie ohne Varianten
> in Kurzform zusammen. Wir packen die Haltestellen und die Route pro
> Fahrtrichtung in dieser Reihenfolge und in Fahrtrichtung sortiert in
> jeweils eine Relation: type=pt2, pt2=variant. Die beiden sich
> ergebenden Relationen kommen wieder in eine Elternrelation: type=pt2,
> pt2=master. Richtig?

Ja.

> Was mir unklar bleibt: Wie weiß man jetzt, wo ein Umsteigepunkt zu
> einer ebenso einfach gestrickten Linie besteht, wenn Du die stop_area
> abschaffst?

Die stop_area existiert nach wie vor, an der hat sich nichts geändert.
Sie wird aber nicht mehr von der Routen direkt gebraucht -- z.B. um
Haltestellennamen zu ermitteln.

> Zuletzt: Was mir die größten Bauchschmerzen bereitet, ist das
> parallele Existieren derselben Linien in zwei Relationsmodellen. Das
> könnte für die Mapper verwirrender nicht sein. 

Das ist jetzt lustig. Ich habe das ganze hauptsächlich deshalb gemacht,
weil die Mapper und die Programme die beiden (mindestens zwei)
bisherigen Relationsmodelle nicht klar unterscheiden konnten und so
verwirrt waren, dass die eingetragenen Informationen oft nicht
analysiert werden konnten.

Beispiel: Die ÖPNV-Karte hat früher klasse Karten mit Pfeilen über die
Benutzungsrichtung der Straßen geliefert. Jetzt geht das nicht mehr.
Keiner weiß, ob die Rolle "" an einem wie früher "bidirektional
benutzt" heißt, oder nach Public Traffic Proposal "monodirektional gemäß
Nachbarways". Wir haben früher gedacht, dass man die ja leicht
unterscheiden kann: Nur die PTP-Routen haben "from", "to", "via",
"platform" und "route_master"-Mütter. Das ist aber total in die Hose
gegangen.

weiteres Beispiel: Der JOSM-Validator (und der Rest vom JOSM) steht vor
demselben Problem. Wenn er wüsste, ob das PTP oder klassisch gemeint
ist, dann könnte er massenweise hilfreiche Fehlermeldungen bringen.
Jetzt geht das nicht.


> 
> Nach den letzten Reinfällen würde ich für eine konzertierte Aktion
> aller Beteiligten und der Foundation plädieren, die nach entsprechend
> guter Vorbereitung einen relativ harten Schnitt macht. Dabei sollte
> der Umstellungszeitpunkt schon zuvor auf jeder Seite des Wikis, auf
> osm.org und möglicherweise per E-Mail angekündigt werden. Zu der guten
> Vorbereitung sollte dann auch gehören, dass diesmal eine möglichst
> breite Masse der Community gebeten wird, Stellung zu beziehen und die
> wasserdichte Konsistenz abklopft. Die existierenden ÖPNV Karten
> sollten das neue Schema zum Zeitpunkt der Umstellung schon
> unterstützen. Es sollten möglichst eine Videoanleitung,
> aussagekräftige Beispielgrafiken, eine beispielhaft gemappte Region in
> OSM und vielleicht auch ein Editor-PlugIn existieren. Alle User werden
> aufgerufen, bevorzugt an der schnellen Umstellung der nach dem alten
> Proposal gemappten Linien ab dem angekündigten Termin mitzuwirken.
> Möglicherweise kann man dabei mit Bots arbeiten, wobei der Bot schon
> im Vorfeld abklopfen könnte, was botgestützt umgestellt werden kann.
> Es hat keinen Sinn, wenn das letzte Fiasko noch einmal wiederholt
> wird. Diesmal muss es einfach gelingen.

Ich glaube nicht, dass man das schaffen kann. Deshalb habe viel Arbeit
rein steckt um die ganzen Tags und Strukturen so zu machen, dass beide
nebeneinander her existieren können und wir die benötigte Übergangszeit
bekommen.

Wir können Erfahrung mit dem PT2 (oder besser gesagt: mit
PT2-Relationen und dem ansonsten praktisch gleich gebliebenen
PTP) sammeln, Programme können angepasst werden. Wenn dann irgendwann
der Wille dazu da ist, dann können Dinge als deprecated erklärt werden.
Ausreichend Druck wird auch da sein, den man hat ja die doppelte
Pflege bei den Relationen ...
Wenn der Wille nicht da ist, dann werfen wir sie irgendwann wieder weg
und machen ein PT3.

> Vielen Dank für Deinen Arbeitsaufwand, den Du in das Proposal gesteckt
> hast.

Danke für die Blumen. Inhaltlich gesehen, war es mir wirklich ein
Vergnügen. Arbeit im Sinne von "Mist, das muss ich auch noch machen"
war die Umstellung von LaTeX auf Wiki und z.B. der Verzicht auf Bilder
-- das war mir einfach zu aufwändig.

Wilhelm

PS: Ich hab auch mal ein preset für JOSM gebastelt -- jeder kann es
haben, man muss nur gut aufpassen, dass man nicht hochläd. Ich nehm
dafür einen zweiten JOSM, der das Passwort nicht kennt. :-)




Mehr Informationen über die Mailingliste Talk-de