Am 16. April 2012 15:59 schrieb Wolfgang <wolfg...@ivkasogis.de>:
> Wenn Radwege in einem kleineren Maßstab gerendert werden sollen, stößt
> diese Lösung auf Probleme, weil die Signatur der Straße häufig breiter
> ist als die Fahrbahnbreite und die Radwege dann entweder unter der
> Fahrbahn verschwinden oder auf die Fahrbahn gemalt werden müssen.
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.
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.).
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)). Diese "street"-Relation ist vorwiegend
aus Sicht der Adressen gedacht. 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.
> 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.
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.
> 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?
Gruß Martin
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
