Wilhelm Spickermann <[email protected]> wrote: >Ok, was solls, ich hab gerade auf meiner Wikiseite mal das Pre-Draft für >ein Public Transport Amendment zum Abschuss freigegeben. > >Wilhelm (Weide, http://wiki.openstreetmap.org/wiki/User:Weide)
Sieht auf den ersten Blick ganz gut, konsistent und einfacher als das jetzige Proposal aus. Was mir bisher aufgefallen ist: Bei Bahnsteigen mit Gleisen auf beiden Seiten wird nicht klar, auf welcher Seite der Fahrgast seine Bahn zu erwarten hat. Die Values für Komplettheit müssten noch einen Wert für "fraglich" zulassen, möglicherweise "?". >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? >pt2_subname A name as found on the splot ... Die Bedeutung der Vokabel "splot" konnte ich nicht ergründen. >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? >Other tags traditionally used in such relations (like network, >operator, ...) may of course be used. Network wäre hier wohl zwingend, da es in jedem Verkehrverbund Linien mit der gleichen Nummer geben kann. Ich weiß nicht, ob wir auch noch ein DE (respektive andere Länderkennung) brauchen, da möglicherweise ein gleichlautendes Network im Ausland existieren könnte. >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. >*_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. 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. 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? Was mir unklar bleibt: Wie weiß man jetzt, wo ein Umsteigepunkt zu einer ebenso einfach gestrickten Linie besteht, wenn Du die stop_area abschaffst? 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. 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. Bin jetzt zu müde und muss mir das noch einmal ausgeschlafen anschauen. Vielen Dank für Deinen Arbeitsaufwand, den Du in das Proposal gesteckt hast. _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
