Jochen Topf <joc...@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. _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de