Hi, ich möchte jetzt nicht auf jedes Detail deines Vorschlages eingehen, da ich mich auch nicht in jedes einzelne mögliche Problem eindenken möchte, aber dennoch ein paar Anmerkungen von mir:
* Grundsätzlich finde ich die Vorstellung einer Sammelrelation für Haltestellen sinnvoll. Das kann helfen, Probleme, die man beim derzeitigen modellieren von ÖPNV-Strukturen hat, zu beheben. * Grundsätzlich muss man dabei aber IMHO auch eine Flexibilität erlauben, die womöglich auf Kosten der 100%igen Spezifikation geht. Warum? Nach meiner Erfahrung mit OSM, bin ich der Meinung, dass ein Tagging-Schema nur maximal so komplex sein sollte, wie es der konkrete Anwendungsfall absolut notwendig macht. Kein Anfänger ist bereit, für das schnelle Hinzufügen einer einfachen Haltestelle, sofort das Anlegen einer komplexen Relation zu erlernen. Unsere Editoren sind außerdem nicht so weit, mit solchen Problemen umzugehen und außerdem können wir jetzt noch nicht alle Anforderungen an eine solche Relation abschätzen, die zukünftige mögliche Anwendungen haben könnten. Vielleicht kommt es ja mal tatsächlich zu einem automatischen Nahverkehrsrouting, das dann ganz andere Notwendigkeiten noch haben könnte? Deshalb glaube ich, dass es besser ist, nicht allzu viel zu genau (und ich sag mal zu "ungewohnt") vorzuschreiben. * Konkret meine ich damit zwei Punkte, die mir an deinem Vorschlag so nicht ganz gefallen: Zunächst finde ich es wichtig, dass ein solcher Vorschlag einigermaßen abwärtskompatibel zum derzeitigen Vorgehen sein sollte: Ein node sollte IMHO nicht unbedingt platform heißen müssen, um die physikalische Repräsentation dieser Haltestelle darzustellen, denn es kann und würde vermutlich sehr lange dauern, Vorlagen in Editoren und Renderen das neue Verhalten beizubringen. IMHO ist es deutlich sinnvoller, wenn ein Renderer etwas wenigstens altmodisch rendert, als dass er es gar nicht rendert. Konkretes Beispiel dafür: Dass die cyclemap immer noch nicht das path-Tag so rendert, wie es von vielen erwartet würde, hält denke ich immer noch eine Reihe von Leuten ab, es überhaupt zu verwenden. Ich verstehe nicht, warum nicht einzelne nodes mit "bus_stop" zu einer Relation zusammengefasst werden können sollen. Platform kann man meinetwegen trotzdem verwenden, wenn man findet, dass es etwas besser abbildet und ein Renderer das dann auch unterstützt. * Ähnlich halte ich es auch für nicht unbedingt sinnvoll, "vorzuschreiben", dass bus_stops ein node des Ways sein sollen. Das ist oftmals nicht die gängige Praxis und das wird vermutlich auch niemals so "auszurotten" sein. Außerdem kann ich mir auch vorstellen, dass es Fälle geben mag, in denen man es nicht verwenden mag (so wie es mir schon manchmal widerstrebt bei Straßenbahnen - wo das Setzen des Nodes auf die Linie eher gängige Praxis ist - dies zweimal zu tun, wenn zwei Einzelhaltestellen der jeweiligen Gegenrichtung sehr weit voneinander entfernt sind.), oder man es auch aus versehen nicht verwendet (und sei es, weil in Potlatch der Node versehentlich neben statt auf dem Weg landet). * Da wir unglaublich viele Menschen haben, die unsere Daten bearbeiten und dabei so unglaublich viele Wissensstände vorhanden sind, werden unsere Daten in gewisser Hinsicht immer Inkonsistenzen aufweisen, ich bin der Meinung, dass unsere Router, Renderer und andere Werkzeuge, mit solchen kleinen Unzulänglichkeiten lernen müssen umzugehen. Und da glaube ich ist - auch dank Route-Relationen und Algorithmen mit bisschen mehr Toleranz - es einfacher, dem Router beizubringen, mit solchen Dingen umzugehen, als den Datenbestand komplett anzupassen. Denn wie ein Grundsatz aus der Softwaretechnik sagt: In einem komplexen IT-System sind Daten immer beständiger als Funktionen. Vielleicht teilt ja manch einer meinen grundsätzlichen Standpunkt. Ich glaube aber, dass wir nicht weit voneinander sind und ich deinen Vorschlag im wesentlichen begrüße. In Kurzfassung glaub ich nur, dass es womöglich schwierig wird, die Nodes _auf_ der Straße zu "wollen", und von highway=bus_stop zu highway=platform wechseln zu wollen. grüße, Patrick _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
