[Talk-de] Neues ÖPNV-Schema - Linien(varianten)relationen

Tirkon tirkon33 at yahoo.de
Mi Aug 19 22:26:26 UTC 2009


Jochen Topf <jochen at remote.org> wrote:

>> Eine Endhaltestelle ist gleichzeitig Starthaltestelle für die
>> Gegenrichtung. Ich muss jetzt zwei Relationen erstellen mit
>> from:A-Stadt to:B-Stadt, sowie from:B-Stadt to:A-Stadt. Diese beiden
>> Relationen erscheinen lediglich unter dem lapidaren Namen "Relation".
>> Wenn jetzt an dieser Haltestelle mehrere Buslinien abfahren, habe ich
>> mehrere solcher lapidar beschrifteter Relationen, ohne nur die
>> geringste Ahnung zu haben, welche dieser Relationen jetzt zu welcher
>> Buslinie gehört. 
>> Wie also soll das funktionieren, insbesondere wenn jemand Anderes
>> diese Relationen erstellt hat und ich diese nicht nachvollziehen kann?
>
>Ich nehme an, die Editoren zeigen den Namen einer Relation da an, wenn
>es einen hat. Dann vergib halt einen Namen. Schad ja nicht.

>>Wenn aber schon eine popelige zweiseitige
>> Bushaltestelle eine Relation benötigt und die Linienrichtungen weitere
>> zwei Relationen und die Gesamtlinie nochmals eine Überrelation, wie
>> soll man dann beim Editieren dem Punkt noch die Buslinie zuordnen
>> können?
>
>Das ist zugegebenermassen schwierig. Aber es gibt halt keine einfache Lösung.

Es ist nicht so, dass ich das neue System nicht schätze. Bei meinem
Tagging der Düsseldorfer Linien konnte ich mit dem alten System einen
variantenreichen Bus einfach nicht taggen, so dass momentan einfach
alle Routen in einer Relation eingesammelt wurden. Dann hat es jemand
mit Varianten versucht. Die Folge davon war, dass jetzt in der ÖPNV
Karte auf dem langen Rattenschwanz von Linien in der Nähe von einem
Bahnhof obendrein die Buslinie mehrfach aufgezählt wurde. Hier würde
das neue ÖPNV Schema durchaus das Problem lösen. 

Das größte Problem dabei ist aber der notwendige aber von den
Editierwerkzeugen nicht bereitgestellte Blick zur übernächsten
Relation, weil zur nächsten explizit im Schema gesagt wird, es solle
nur "from" und "to" getaggt werden. Wenn sich jemand ans Schema hält,
wird es später sehr schwierig für ihn selbst und Andere, welche die
Buslinie fortführen. Der Nutzen, wenn nur ich neben "from" und "to"
auch die Namen dranschreibe, ist  minimal. Es hilft eigentlich nur,
wenn es alle Nutzer des Schemas tun. Im Moment werden sie aber zum
Gegenteil aufgefordert. 

Wenn die Datenstruktur im Falle der Haltestellen zwingend komplex sein
muss, wäre es eine Alternative, den Editierwerkzeugen beizubringen,
damit umzugehen. Hierzu müssten sie auch die übernächste Relation
anzapfen und in geeigneter Form in die Anzeige der nächstniedrigen
einbinden. Dann blieben solche Konstruktionen leicht handhabbar und
würden im Zuge dessen automatisch konsistent gehalten: Der User
bekommt beispielsweise ein Formular für Haltestellen präsentiert, in
das er an nur einer Stelle "bus" eingibt. Sobald ein weiteres Mitglied
in die Relation aufgenommen wird, werden die Daten dort übernommen und
es wird vom Editor automatisch richtig eingetragen und somit
konsistent gehalten. Man kann die Sache jetzt weiterspinnen, wie man
das Ganze am besten gestaltet. 

Dass so etwas funktioniert, zeigt sich beispielsweise in
Musikverwaltungen.  Man trägt beispielsweise bei einem Album den Namen
des Interpreten nur einmal ein. Dennoch vervollständigt sie die
Einträge soweit, dass in jeden MP3Tag der MP3-Dateien dieses Albums
der Interpretenname eingetragen wird. Im Falle eines Samplers
unterbleibt dieses natürlich. Der Editor der Musikverwaltung und die
Form der Formulare sorgt für ein konsistentes Tagging. 

Wäre dies nicht auch in OSM zumindest in Bezug auf unvermeidliche
verschachtelte Konstruktionen wie beispielsweise bei Haltestellen
möglich? Um den User nicht einzuschränken, bleibt die Formularmethode
optional. Ich bin aber sicher, dass bei einer guten Implementierung
die große Mehrheit kaum mehr etwas Anderes benutzen möchte. 

Dies könnte womöglich auch dazu beitragen, dass die derzeitigen hier
in der Liste diskutierten automatischen Checking-Läufe weniger
horrende Fehlerzahlen ausspucken. Momentan entwickelt man Software,
die Fehler ermittelt, die dann von Hand repariert werden. Warum nicht
mit dem Arbeitsprinzip der Check-Software schon zum Editierzeitpunkt
die Konsistenz bewahren? Das Ergebnis bleibt dasselbe und daher auch
der - mir fällt kein treffenderes Wort ein - "Bevormundungsgrad" des
Users gleich. Ein Beispiel wäre möglicherweise, ein einheitliches "ID"
für die Verwaltung der Variantenrelationen sicherzustellen, so dass
der Renderer dies einfacher erkennen kann. Dies ist zumindest besser,
als wenn nachher mit Checkprogrammen und mühsamer Handarbeit
nachgebessert werden muss.

>> Es ist auch nicht verständlich, wieso ich mehrfach "bus" taggen muss.
>> Es reicht doch, wenn eine Haltestelle Member einer Buslinie ist.
>> Daraus geht dies doch schon hervor. Ferner befürchte ich Probleme beim

>Aber wenn dann die Buslinie verloren geht, kann ich auch die Haltestelle
>nicht mehr zeichnen.

Man könnte eine solche Haltestelle genau so behandeln, wie eine
"disused" nach dem neuen Konzept. ;-) Möglicherweise also mit einem
rot durchkreuzten "H". So würde der fehlende Bus in der grafischen
Darstellung dem Ortskundigen sofort auffallen. Ferner würde auch
auffallen, wenn jemand Haltestellen getaggt, aber noch keinen Bus
zugeordnet hätte. In einem konkreten Fall hat ein User bei einer für
lange Zeit verlegten Haltestelle die Relation auf die zwischenzeitlich
genutze verlegt und in einer Note "currently unused" angegeben. Auch
hier würde das Schema nach dem Entfernen sämtlicher Busse-Relationen
aufgehen. ;-) 

>Und ein Renderer, der keine Buslinien einzeichen
>will, sondern nur Haltestellen, wird viel einfacher. Redundanz ist gut.

Auch dieses Problem wäre mit der oben beschriebenen Formular Methode
gelöst. 

>> Abschließend wollte ich noch auf das Problem aufmerksam machen, dass
>> im Wiki das Problem auch diskutiert wird, ohne dass vermutlich dort
>> jemand eine Ahnung davon hat, dass dies in der Mailingliste ebenfalls
>> geschieht. Möglicherweise kennt man nicht einmal Mailinglisten und
>> insbesondere diese.
>> http://wiki.openstreetmap.org/wiki/DE_talk:Relation:route
>
>Ja, das ist ein Problem bei OSM, dass es viele Stellen gibt, wo man solche
>Sachen diskutieren kann: Wiki, Mailing-Listen, Foren. Und natürlich alles
>in verschiedene Sprachen. Das ist uns allen hier bewußt und da gibts halt
>keine gute Lösung für.

Und da mir diese Probleme bewusst sind, wollte ich diese weitere
Diskussion auch hier zur Kenntnis bringen. 





Mehr Informationen über die Mailingliste Talk-de