Da muss ich mal schauen 
Meine Daten zu turn:lanes stammen von Netzwolf, den wir ja leider hier vergrault haben. Zum Glück lässt er seine Auswertungen noch laufen.
Vielleicht kann dir da einer unserer Auswertungs-Gurus da weiterhelfen. Mir fehlt dazu Equipment und knowhow.
Ich wäre sehr traurig wenn wir den lieben Netzwolff vergrault hätten.
Es ist ja normal, dass wir in einem so komplexen Projekt unterschiedliche Meinungen zu verschiedenen Themen haben. Die Diskussionen unter alten Mapper sollten ja eher sachbezogen und nicht persönlich sein.
Viele Grüße,
Marek
Das wir ihn vergrault haben, ist wohl von mir etwas pauschal gesagt. Ich erinnere mich an die damalige Diskussion. Wenn wer auch immer so mit mir in der Forumsöffentlichkeit umgesprungen wäre, hätte ich wohl ähnlich reagiert.Er schweigt hier zwar konsequent. Aber gänzlich ohnes Interesse an OSM auch hier im Forum scheint er nicht zu sein.
Auch ich vemisse seine sachliche und fachlich fundierte Art, sich hier einzubringen.
Unser Kollege Netzwolff hat die Frage gestellt, in welcher Reihenfolge man die a:h erfassen sollte.
Nun denke ich, dass vor Allem die Kreuzungen die als gefährlich in einer Stadt gelten, die kann man schnell googeln.
Danach die innenstädtischen motorway, primary, trunk road Kreuzungen. Bis man bei den secondary und tertiary roads ankommt wird dies wohl eine Weile dauern.
Und wenn ihr schon dabei seid, schaut doch bitte gleich nach, ob die Fahrspuren, Ampeln und Zebrastreifen vollständig und richtig erfasst sind. Ohne die ist die Information über die Flächendarstellung nur halb so viel (oder noch weniger) wert. Kreuzungen sind meist nur gefährlich, weil Ortsunkundige Orientierungsprobleme haben bei der Suche, wie es wo weitergeht.
http://wiki.openstreetmap.org/wiki/Proposed_features/area_highway/mapping_guidelines#Parallel_ways
warum können wir so nicht machen?
Solange das den Regeln widerspricht, muss man es aus “mapping guidelines” entwerfen. Meiner Meinung nach ist es besser, diese “Kapitel” gar nicht schreiben, als schlechtes Beispiel zeigen.
+1 wobei ich a:h=divider besser fände.
Es wird halt zunehmend schwerer zum auswerten. Daher würde ich darum bitten, wenigstens kein Multipolygon anzulegen.
Sieh Dir bitte diese Strasse an:
https://www.openstreetmap.org/way/223981874
teoretisch müsste man sie in der Mitte mit der Straße https://www.openstreetmap.org/way/364988566 verbinden und daraus eine Strasse machen. Es gibt aber viele Mapper die sagen, dass sich das für eine so kurze Strecke sich nicht lohnt und die Karte ist übersichtlicher, wenn man diese Straße genau so zeichnet, wie sie gezeichnet ist.
Die Frage, wie lange müssen solche Strecken sein, damit man sie miteinander verbindet ist eine Grauzone.
Für solche Abschnitte würde ich den existierenden Vorschlag empfehlen.
Es gibt noch ein weiteres Problem: Das richtige Taggen solch komplexer Strecken mit lanes und turn:lanes. Es ist sehr einfach hier Fehler zu machen. Und das richtige Rendern von lanes ist kaum möglich:
Im Gegensatz zu den komerziellen Karten fehlt uns hier nämlich in der lanes Definition der Übergang. Hätten wir die Kategorie “Gabelung” von z.B. zwei lanes zu drei für eine Strecke, dann wäre das Problem vom Tisch.
Eine Straße:
Es fehlt eine durchgezogenen Linie - sogar Doppellinie wird als eine Straße behandelt. Warum an kurzen Stücken “Ausnahmen” machen? Es wird mit Detailmapping immer schwieriger alles an einen way zu taggen - auch die Auswertung wird dadurch auch nicht einfacher.
Klar ist es verständlicher, wenn der Verlauf dem tatsächlichen Verlauf entspricht - aber das ist in OSM nicht gewollt.
Ich bin der Meinung den tatsächlichen Verlauf zu mappen - auch sollten z.B Verkehrsinseln als Fläche mit getrennten ways gemappt werden (dürfen) - und nicht wegen Navis nur als node in den way.
Hier sind aber flüchtig betrachtet noch Fehler:
- an der südöstliche Parkplatzstraße fehlt die Verbindung zu der nördlichen “Fahrbahn”.
- am nördlichen Radweg fehlt m.E. foot=yes (oder taggen wie südlichen way)
Warum denn?
Und handelt es sich nur um Multipolygone mit inner-Teilnehmern oder um überhaupt alle Multipolygone?
Also es geht mir konkret nur um Straßenflächen und Multipolygone mit inner-Teilnehmern.
Für meine Zwecke ist die Haupt-Herausforderung bei Straßenflächen das Berechnen von Spuren in der Fläche. Das ist an sich schon recht herausfordernd, weil man ja in einer Fläche erst mal keine Richtung hat. D.h. man muss auf Basis der Highway-Ways eine Liniensequenz der Fläche zuordnen (wobei es Stolperfallen gibt, wie z.B. einmündende Wege ohne junction area), und dann die Fläche praktisch umrechnen in einen Breitenverlauf längs der Straßenlinie. Machbar ist es denke ich. (Sicher weiß ich das erst, wenn ichs mal programmiert habe.)
Wenn jetzt aber noch Multipolygone hinzukommen, erschwert sich diese Aufgabe nochmal. Dann stellt sich ja z.B. die Frage, welche Spuren rechts und welche links am Loch vorbeigehen. Auch wird die Spurberechnung (weil die Spuren ja nicht als Geometrie eingezeichnet sind) sicher nicht hundertprozentig mit den Löchern etc. zusammenpassen. Letztlich wird so halt ein bereits anspruchsvolles Problem nochmal schwerer und kaum mehr sauber zu lösen.
Ich hoffe ich habe das einigermaßen verständlich beschrieben…
Den Einwand von User edward17 kann ich durchaus nachvollziehen.
Ich habe ein (nicht mehr ganz frisches) Beispiel aus München (schon 2012 von Marek).
Hier muss (müßten) eine Durchfahrt, innere Parkflächen und innere Sperrflächen gleichzeitig zum a:h getaggt werden. Lohnt hier eine Aufsplittung der a:h, um ein MP mit “inner” Flächen zu vermeiden?
http://www.osmapa.pl/w/areade/?lat=48.22028&lon=11.58863&zoom=18&ol=BPN
Ich meine auch, das durchaus MP mit Inner “verbaut” worden sind in der letzten Zeit, finde es jedoch nicht auf Anhieb (Polen?).
Und wenn MP nicht gewollt sind, sollte das eindeutig im Proposal beschrieben werden.
Das würde ich von dem Straßentyp abhängig sehen. Eine Residential mit 2 Fahrspuren ohne Mittelstreifen würde ich nicht mit lanes rendern wollen, sprich auch so lassen wie sie in dem obigen Beispiel ist. Und bei größeren Straßen erübrigt sich meistens diese Frage.
Lass uns Mal nach weiteren “kniffligen” Beipielen suchen.
Bitteschön: Ein MP mit inner in Nürnberg.
http://www.osmapa.pl/w/areade/?lat=49.46638&lon=11.05624&zoom=18&ol=BPN
Erg.: Ich bin der Meinung, innerhalb dieses Schemas sollten MP mit “Inner” Anteilen nicht “verboten” werden. Manchmal ist es fast gar nicht anders lösbar. Es handelt sich ja auch nicht um komplexe MP. Und die Straßen- und Wegeführung bleibt ja erhalten. Hier braucht niemand irgendwelche Routingfunktionen. Man kann letztlich vielleicht irgenwann mal die Fläche mit den Way-Routing visuell, z.B. in einer zukünftlichen App, vereinen und sieht die Straßenflächen (womöglich in 3D) mit den entsprechenden Spuren und Hindernissen… (Science Fiction OSM)
Auch in Hamburg sind nun die a:h sichtbar:
http://www.osmapa.pl/w/areade/?lat=53.54746&lon=9.99742&zoom=19&ol=BPN
OsmAnd unterstützt Darstellung von area:highway=*:
http://wiki.openstreetmap.org/wiki/File:Highway_area_rendering_on_OsmAnd_2.2.2.png
Vielleicht kann dieses Beispiel in entsprehende Teil des Proposals (nähmlich hier) hinzugefügt werden.
Hoffentlich kann man das auch irgendwo wieder abschalten. 
Ist das Absicht, diese Flächen auch mit Namen zu versehen, so wie hier? Wenn ja, welchen der beiden bei junction=yes?
Falls der Name dran bleiben soll, müsste man beim Rendern berücksichtigen, dass man den wieder wegbekommt, sonst steht der an jeder Strasse mehrmals:
Grüße, Max
Nein, Namen haben jetzt an a:h nichts zu suchen. Das sind wohl noch alte Daten, zu Anfang wollten wir noch die Namen dran haben.