Das derzeitige area:highway entstand damals erstmal nur aus dem Grund, dass man eine Straßenfläche erfassen wollte, um Straßen von den ungerichteten Plätzen unterscheiden zu können. Größere Gedanken ans Rendern hat man damals nicht verschwendet. Problematisch sind bspw. die Kreuzungsflächen, wenn man die highway-Klasse rendern möchte. Ebenso der Straßenname bzw. die oneway-Pfleile müssen aus dem Way gerendert werden, an Stellen mit area:highway sollte der Weg ansonsten aber transparent sein.
Man müsste als erstmal alle Straßen ohne besondere Merkmale rendern, dann die area:highway-Flächen und dann die besonderen Merkamale der Straßen (Name, Einbahnstraßenpfeile). Für das Problem mit den Kreuzungen muss aber erst noch eine Lösung im Datenmodell gefunden werden. AFAIK ist da Marek dran, sich etwas auszudenken. Das sollten wir dann aber wenn in einem separaten Thread diskutieren.
Hmmm
Wie wäre es, wenn highway:area=* etwas heller oder teiltransparent in dem highway=entsprechender Farbe unter den highway= liegen würde. Dann sähe man beides, aber könnte auch den Unterschied und die Erfassung erkennen.
Oder wie bei highway=pedestrian über gleichem area wie z.B. hier: http://www.openstreetmap.org/browse/way/40444087
Die Karte lässt für den schneidenden Weg die schwarzen Außenlinien weg (oder legt den unter die Fläche?). Potlatch stellt den Weg mit gestrichelten Außenlinien dar.
Die aktuellen Versuche die Brücke durch “highway=service” und “area=yes” oder durch nicht existierende Tunnel hübsch zu malen, sind völlig sinnlos und führen in diversen Anwendungen zwangsläufig zu Fehlern.
Benachbarte Brücken hat es noch schlimmer erwischt. Sie sind als “building=bridge” mit gleichem layer wie die Straße bezeichnet.
So etwas gehört auf eine Spielwiese, aber nicht in die Hauptdatenbank. Ein lokaler Mapper sollte dort aufräumen.
Das genügt allgemein nicht, da die Brücke breiter als die Fahrbahn ist. Oft läuft mehr als ein Weg über dieselbe Brücke (Fahrbahn, Gegenfahrbahn, Rad- und Fußweg, evtl. Bahngleise). Dann braucht man eine Relation, um diese Wege zusammenzufassen.
“area:highway” ist eine bloße Hilfsfläche für den Renderer. Detaillierte Angaben zu den Fahrspuren [1] sind wichtig für gutes Routing, Fahrspurassistenten, evtl. Verkehrsanalysen und ermöglichen eine relativ gute Abschätzung der Fahrbahnfläche.
Also besser:
Erst “lanes” erfassen und rendern (vielleicht mit 3m Breite pro Spur) und für Brücken auch die Relation der darüberführenden Wege auswerten.
Dann überlegen, ob “area:highway” einen zusätzlichen Nutzen bringt, der den Aufwand rechtfertigt.
Die Versuche zum Hübschmachen werden vom lokalen Mapper durchgeführt.
Die benachbarten Brücken waren auch schon länger verhunzt. Auch lokale Mapper.
Ich stehe mit einem lokalen Mapper in Kontakt.
Mit Relationen hier zu Arbeiten macht erst Sinn, wenn aufgeräumt wurde.
Die Funktion von area:highway war mir auch vor deinen Ausführungen schon klar.
Und an der Erfassung von lanes nach http://wiki.openstreetmap.org/wiki/Lanes wird schon offline gearbeitet. Schwierig wird es in dem Bereich auch, weil die ganzen über die Spur-highways verstreuten Relationen wieder zurechtgerückt werden müssen.
Die Mischung aus Mappen nach http://wiki.openstreetmap.org/wiki/Lanes und der Verwendung von area:highway scheint mir für die Zukunft nicht nur hier viel versprechend, um den Konflikt zwischen den Ansprüchen des Routers und des Kartenlesers im Mikrobereich gerecht werden zu können.
Mit der Anwendung von area:highway=* als auch von http://wiki.openstreetmap.org/wiki/Lanes werden zwei Dinge passieren: 1. eine hinreichend saubere Darstellung der Straßensituation auf der Karte (das, was man sieht) und zum 2. ein hinreichend sauberes Routing der Strecke (da, wo man hin will). Denn es sind ja auch zwei verschiedene Dinge (die im Kopf des Menschen zusammengehören): Die Kartendarstellung: das was ich sehe und die Pfeile des Navis, die mir anzeigen, wohin ich will. Streng genommen würde es darauf hinauslaufen daß es eine Routingebene geben müsste oder muß oder gibt, die die Wege- und Straßeninformationen zur Zielfindung endhält und das es zum anderen eine Ebene der Kartendarstellung gibt, die man z.B. im Web-Browser sieht. Beides ist gleichermaßen wichtig.
In mir keimt auch so die Vermutung daß auch Renderer diese Dinge unterscheiden werden müssen. Übrigens könnte und müsste man diese Dinge auch auf Eisenbahn-, und Wasserwege-Ebene betrachten. Da hat man ja auch z.B. Waterway=riverbank für die Fläche und Waterway=river für die Linie (so wende ich es an) oder landuse=railway für die Fläche und railway=* für die Strecke als solches… in All diesen Fällen vermeide ich es, der entsprechenden Linie einen gemeinsamen Stützpunkt mit der Fläche zu geben, da wo ich es vorfinde, trenne ich es. Linie ist Linie und Fläche ist Fläche…
Genau so ist es Sven! Eigentlich gibt es zu dem oben beschriebenen Ansatz meiner Meinung nach keine Alternative wenn wir noch mehr aus der Karte machen wollen. Es bleibt sich auf ein Schema zu einigen.
In diesem Sinne ist das dann auch kein Fehler. Ein Fehler wäre es, wenn sich zwei Straßenlinien schneiden, ohne einen gemeinsamen Stützpunkt zu haben. Eine Straßenlinie, die einene Fläche als area:highway=* schneidet und keinen gemeinsamen Stützpunkt haben, ist für mich kein Fehler. Ebenso, bei Gewässern: ein Waterway=river und schneidet die abgegrenzte Fläche Waterway=riverbank und der Schnittpunkt hat keinen gemeinsamen Stützpunkt. Ja, JOSM meckert… Sehe ich aber nicht als Fehler. Wenn man an diesen stellen Stützpunkte verwendet, müßte man, um Routingfähig zu bleiben, diesen Stützpunkten Restriktionen auferlegen, also “Route auf dem Linienobjekt weiter” oder aber Linien, die eine Fläche umgrenzen werden generell beim Routing ignoriert. bei ersterem würde das einen erhöhten Tagging-Aufwand bedeuten, den ich aber für unsinnig halte, bei letzerem weiß ich nicht, ob diese fixe Idee überhaupt funktioniert.
Nein. Es ist eine klar spezifizierte, begrenzte Sache. Wr müssen nur dafür Sorge tragen, dass es an richtegen Stellen ankommt, damit auch andere Qualitätstools diese Feature unterstützen.
Oder aber, man würde einfach wie bisher auf Flächen mit area:highway (oder waterway=riverbank, etc.) nicht routen. Wo ist genau das Problem? Nur weil zwei Linien einen gemeinsamen Punkt haben, heißt das ja noch lange nicht, dass ich von der einen auf die andere routen darf. Oder lotsen wir demnächst Autofahrer über Fußwege, nur weil die gemeinsame Punkte haben.
Das war auch noch nie hier die Idee, darüber zu routen. Im Gegenteil, das dient der klaren Unterscheidung zu highway=* in Verbindung mit area=yes, was einige Programme dazu verleitet über die Kanten des area zu routen. Siehe thread-Beginn.
Gut. Dann bin ich mit dem Thema im reinen.
area:highway ist gut.
highway=* mit area=yes ist böse.
Ich habe mich bisher darum gedrückt, eine der beiden Varianten selbst anzuwenden, bin ja noch nicht so lange bei und taste mich an einiges Schritt für Schritt ran…
So krass kann man das nicht sehen.
Es gibt Straßenflächen (vor allem bei highway=service), auf denen überall gefahren werden darf und kann.
Nicht jede Fußgängerfläche ist ein highway=pedestrian z.B. Schulhöfe. Die sind besser mit highway=footway + area=yes getaggt.
