Hallo, Am Montag, 16. April 2012 17:23:30 schrieb Martin Koppenhoefer: > > wenn sie (evtl. sogar nur teilweise) unter der Straße verschwinden > ist das in der Tat unschön, aber auf der Straße habe ich kein > Problem damit ("Fahrbahn" kann man das was da als Straße gerendert > wird, ja nicht nennen, das ist eigentlich fast immer ein mit > überhöhter Breite dargestelltes Symbol für eine Straße, nicht die > Fläche der Fahrbahn.
Das sieht aber für den Betrachter anders aus. Wenn der Radweg dann auch noch den Abstand wechselt, ist er mal auf und mal neben der Straße. Hör dir mal die Kommentare an, wenn du so etwas renderst. Insbesondere, wenn du auch noch unterscheiden willst, ob die Straße für Radfahrer frei gegeben ist, dort also eine Signatur extra dargestellt werden soll. > > Grundsätzlich ist das ein Konfliktpunkt, wo man (ich übertreibe) sich > unterscheiden muss zwischen einem schematischen Plan (z.B. ein > U-Bahn-Netzplan) und einer topographischen Abbildung (wo in den Daten > möglichst jeder Schlenker enthalten sein sollte, und die Daten > möglichst lagegenau sein sollten). Prinzipiell kann man schematische > Pläne aus lagegenauen Daten konstruieren, während es anders rum > unmöglich ist. Andererseits wird von einigen der Detailgrad, der sich > aus expliziten (Spuren), Fußwegen, Radwegen ergibt, grundsätzlich in > Frage gestellt (Argumente sind z.B., dass das zu unübersichtlich > würde, dass es nicht möglich sein würde, flächendeckend diesen > Detaillierungsgrad einzuführen und aktuell zu halten, etc.). Hinzu kommt noch, dass sich ein überhöhter Detailgrad gar nicht aktuell halten lässt, falls das Luftbild denn so aktuell sein sollte. > > Diese Wege alle mit Relationen zusammenzubringen, könnte eine Lösung > sein, wird allerdings auch das Beitragen verkomplizieren. Die > Relation "street" oder "associatedStreet" bringt dabei allerdings, > soweit ich das sehe, nichts, weil die nicht aussagt, dass das eine > Straße in diesem Sinne ist (in die vg. Relationen werden alle > Straßen mit demselben Namen in derselben Gegend eingetragen, d.h. > gleichnamige orthogonale Zuwegungen, die bei bestimmten > Bebaungstypen (z.B. Zeilen- und Reihenhäuser) oft auftreten, werden > da auch in derselben Relation gesammelt, soweit ich weiss)). In Lübeck haben wir die street dafür benutzt, parallel laufende Wege zusammenfassen zu können, um eben nicht mit der associatedStreet zu kollidieren. Wenn das sich so nicht fortführen lassen sollte, muss man dafür eben auf eine neu zu erfindende Relation speziell für diesen Zweck ausweichen. Bisher war das aber noch nicht erforderlich. > Diese > "street"-Relation ist vorwiegend aus Sicht der Adressen gedacht. AFAIK die associatedStreet, während die street ... Ich sehe gerade, dass das jetzt im Wiki total verwässert wird. Dann muss wohl was Neues her. > Von > den vorgeschlagenen Relationen "könnte" z.B. die area-Relation das > (damit könnte man auch z.B. die Bordsteinhöhe oder sonstige > Trennungen mappen), wird aber nirgends eingesetzt oder ausgewertet > bisher. Auswertung mach ich selbst, das würde mich nicht weiter stören. Aber die area ist ja eigentlich zur Beschreibung der Fläche zwischen 2 Wegen gedacht. Da würde mir wahrscheinlich früher oder später das gleiche wie bei der street passieren. > > > Die Lösung, den Radweg per tag seitenrichtig an die Straße zu > > setzen, ist universeller, denn sowohl der Router als auch der > > Renderer können das tag auswerten. > > wobei man halt Lageinformationen (vor allem Detailverläufe) verliert > und das tagging von eigenen Eigenschaften (anderer > Abbiegerestriktionen, partielle Barrieren, Spurbreiten, Oberfläche, > Maxspeed, etc.) nicht nur wesentlich komplizierter und > intransparenter wird, sondern auch (wenn der Mapper viele Details > eintragen will) zu extremer Aufsplitterung der Straße führt, sobald > einer der impliziten Ways (Fußweg, Radweg) seine Eigenschaften > ändert, also z.B. die Breite eingeengt ist oder ähnliches. Das passiert jetzt auch. Wenn ich in kleinem Maßstab den Radweg neben die Straße setzen will, muss ich die Straßen an den Stellen auch unterbrechen, wenn ich die Eigenschaften jeweils an der Straße darstellen will. Das ist derzeit die einfachste Möglichkeit. > > D.h. bei sehr hohem Detaillierungsgrad sind explizite Ways von den > Mappern viel einfacher zu durchschauen und weiterzubearbeiten, > während das Sammeln von Ways in einer Straße > > Zusätzlich gibt es topologische Probleme bei Objekten, die sich > zwischen dem Radweg und der Straße befinden, z.B. Geländer und > Absperrgitter, Telefonzellen, Grünstreifen und Pflanzbeete, und > ähnliches. Ja, aber dann ist der Abstand auch häufig groß genug, um von einer baulichen Trennung zu sprechen, die dann wieder zu einer separaten Darstellung führt. > > > Die Straße hat meistens nicht nur einen Radweg, sondern auch einen > > Fußweg. Wenn der separat ist, sollte das auch so eingetragen > > werden. Sonst täuscht man eine Genauigkeit vor, die in > > Wirklichkeit nicht erreicht wird und betreibt eine Art > > "Klientelmapping". > > "Klientelmapping" ist völlig in Ordnung, man kann niemandem in OSM > verbieten, Hundekottütenspender zu mappen, nur weil z.B. noch keine > Universitäten eingetragen sind. Jeder trägt das ein, was ihm wichtig > ist. Wo kämen wir hin, wenn jeder anfinge, Zeugs zu löschen, nur weil > anderes Zeugs noch fehlt? Habe ich irgenwo gefordert, etwas zu löschen?? Wenn jemand den Hundekottütenspender einträgt und die Uni, vor der er steht, nicht, würde ich den auch fragen, ob er nicht etwas vergessen hat. Wenn die Uni aber im anderen Stadtteil liegt, passt das Beispiel nicht. Aber wenn man schon gründlich mappt, dann sollte das auch möglichst vollständig sein. Was nützt es, wenn das Routing für die Radfahrer funktioniert und für die Fußgänger das ganze noch mal erfunden werden muss. Dann heißt es doch wieder mal "Immer die Radfahrer" ;-) Abgesehen davon, dass dann auch für die Radfahrer unklar ist, ob die Fußgänger jetzt auf dem Radweg anzutreffen sind oder einen separaten Weg haben. Ab einer gewissen erstrebten Geschwindigkeit ist das wichtig für die Routenwahl. Im übrigen, siehe mein vorheriges Posting, weiß ich, dass das Rad nicht zurückzudrehen ist. Selbst wenn die Radwege im Mapnik jetzt (endlich) kommen sollten, kommen sie zu spät. Gruß, Wolfgang _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de