Am 4. Februar 2012 00:46 schrieb Tirkon <tirko...@yahoo.de>: > Bernd Wurst <be...@bwurst.org> wrote: >>> Möglicherweise bietet eine zukünftige API Features, die das Mappen von >>> Linienbündeln vereinfachen. Wer sie also in OSM möchte, möge sich >>> Gedanken machen, wie das geschehen könnte. >>Nein, bitte nicht. >>Die API muss so minimal wie möglich sein. Wir haben unsere primitiven >>Datentypen und mit den Tags können wir daraus lustige Dinge machen. Aber >>die API muss das alles nicht verstehen, nicht bewerten und auch nicht >>beschränken.
+1 > Die API kann dem Weg eine Richtung geben. es ist das Datenmodell, das eine Richtung kennt, die ergibt sich automatisch, weil ein way eine geordnete Reihe von nodes ist. Die API muss die Reihenfolge nur beibehalten, sie muss sie nicht prüfen und z.B. fragen: "Du hast eine Straße umgedreht, die einen oneway-tag hatte, willst Du das wirklich?". > Wenn > dasselbe für Tags (und eventuell für Relationselemente) möglich ist, > ist das keine Beschränkung, sondern die Aufhebung einer Beschränkung. ist doch bereits umgesetzt: die Reihenfolge von Relationselementen wird beibehalten, das war am Anfang nicht garantiert (soweit ich mich erinnere). Tags haben dann eine Richtung, wenn die Mapper sie so verstehen. Dazu braucht man auch keine gesonderten API-Funktionen. > Auch für Punkte wäre eine Richtungsangabe sinnvoll, z.B. bei > Ortseingangsschildern mit beidseitig verschiedenen Beschriftungen. ich mache da einfach 2 Schilder, je eins je die Richtung, für die es gilt (neben die Straße, sonst wäre m.E. nicht klar, welche Richtung gemeint ist, habe das aber auch oft schon anders gesehen), analog zu den anderen Verkehrschildern wie maxspeed, maxweight, etc. Man könnte aber auch Punkten zusätzlich eine Richtung mittaggen, z.B. vector=NNE (nord-nordost). Oder vector=3h (3 Uhr). Oder vector=45° (wenn man z.B. festlegt, dass Norden 0 Grad ist und man in oder gegen den Uhrzeiger zählt). Persönlich wäre mir die Uhrangabe am liebsten, finde ich schön einfach und eindeutig. > Derzeit braucht man dazu Relationen. braucht man nicht. > Beim algorithmischen Zerlegen einer solchen Idee zeigt sich häufig, > wie gut und flexibel sie wirklich ist. Insofern ist das Schreiben > eines grafischen Editors sicherlich keine schlechte Gewährleistung > dafür. wenn sich das durchsetzen wird, dann werden vermutlich die gängigen Editoren wie JOSM, PL2 und Merkaartor das irgendwann auch grafisch umsetzen, aber als Voraussetzung für die Einführung würde ich das nicht sehen. Als die Relationen eingeführt wurden gab es praktisch keine Unterstützung dafür und die Multipolygone werden immer noch nicht wirklich userfreundlich (=transparent, indem ein Area-Datentyp "simuliert" wird) präsentiert, trotzdem werden sie von vielen Mappern verwendet. > Die Linienbündel (mit Abstrichen auch den ÖPNV) sehe ich als einen > bisher einmaligen Sonderfall in OSM. ich sehe das als einen weiteren Baustein im Puzzle, der zudem m.E. nicht besonders interessant ist, weil Spurassistenten eigentlich nur für Autofahrer relevant sind. Andere Dinge, die wir mappen (z.B. Routen, die Straßen- und Adressrelationen, ÖPNV, die Küstenlinie, Multipolygone, zeitlich oder anders begrenzte Beschränkungen, etc.) sind ebenfalls jeweils Sonderfälle, die jeweils eigene Mechanismen und Regeln haben. > Schon bei dem ÖPNV-Schema war das in ähnlicher Hinsicht problematisch, > wenngleich man den ÖPNV noch ignorieren kann. kann man eigentlich nicht. > Bei Linienbündeln geht > das nicht mehr, weil sie kein Additiv mehr sind. Sie ERSETZEN > vorhandene Wege und Kreuzungen und sie kommen nahezu in jedes Dorf. ich dachte, der hier diskutierte Vorschlag wäre eine Ergänzung zum bisherigen, baulich getrennte Wege würden ja nach wie vor mit eigenem Way gemappt, so dass sich da nicht so viel ändern wird, oder sehe ich das falsch? Gruß Martin _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
