area:highway welche Flächen genau?

das hat mit dem mapping nichts zu tun. Wer rendert entscheidet, was wie dargestellt wird.

das wäre mapping für den Renderer, eine Art von. Wir malen keine Karte sondern bilden die Welt ab. Absichtlich Lücken zu lassen weil man es bei bestimmter Darstellung sowieso nicht sieht, das haben wir jetzt schon gelegentlich (wasser polygone und landuse unter Brücken wird manchmal so abgebildet), das sehe ich aber als Fehler und nicht als Anregung, die Straßenflächen auch so zu machen

Hab jetzt doch mal überlappende Flächen gebaut, hat mich dann doch interessiert :wink:
overpass

P.s. diese overpass-turbo-instanz is ma geiler Scheiss, weil man das mapcss reloaden kann.
(css ändern und rechts neben Ausführen den refresh-button)

… sehe trotzdem nur graue Pampe - allerdings bin ich an Render-Simulationen per MapCSS auch schon verzweifelt;-)

Was mir auffällt: Der way der L ist unter der Brücke gesplittet, und Du hast dem Teil ein covered=yes spendiert - was ein Renderer auch einfach nutzen kann.
Beim entsprechenden area:highway ist demgegenüber eine derartige Flächenteilung nicht vorgesehen - das soll ein Renderer so hinkriegen, nur über layers?


Nachtrag:

Hab auch mal eine Überlappung gemalt (teilweise vereinfacht, ohne shoulder)
https://overpass-turbo.eu/s/1daU
… scheint mir (zweistöckig) zu funktionieren - ganz und gar ohne layers - wer findet den Trick?-)

Was ein layer nicht ersetzt.

ja natürlich, layer=1 ist über layer=0. Was ein Renderer daraus baut ist seine Sache, nicht meine.

P.s. zu covered noch, das ist erst mal nur eine Info, ob man irgendwo im Trockenen steht, was der Renderer daraus macht ist auch wieder seine Sache.

Naja, das scheint mir bei carto nicht einmal bei einfachen Straßen-ways zu klappen,
daher bin ich da skeptischer,
daher mein Ansatz, von unten zu denken, die verdeckten Flächen zu markieren statt die sichtbaren.

Will das layer-Tagging aber nicht madig machen, stört ja eine KISS-Auswertung nicht:
https://overpass-turbo.eu/s/1ddf

Könntest Du denn mit covered=yes - zwecks Optimierung der Render-Möglichkeiten - zusätzlich zu den layers leben?

?
Ist das jetzt nur mal so behauptet oder hast Du ein Beispiel dafür?
Ich habe da noch keine Probleme bei Straßen-ways untereinander gesehen.

Meine sowas
https://www.openstreetmap.org/#map=19/51.32117/9.28420
Die Brücke (layer=1) ist zwischen A (layer=1) und B - ersichtlich ist das nicht wirklich…

vs.

Mit “Die Brücke” meinst Du wahrscheinlich https://www.openstreetmap.org/way/377749666.
Das ist aber ein man_made=bridge und eben kein einfacher Straßen-way

Und das ist dann eben:

OSM-carto legt seinen Schwerpunkt auf die Darstellung der Straßen. Daher werden Straßen grundsätzlich über andere Objekte gerendert, solange es sich nicht um einen anderen highway=* mit einem höheren layer handelt. Selbst Tunnel, die werden nur anders dargestellt, aber dennoch über die darüberliegenden Gebäude und hier eben man_made=bridge drüber gerendert. Mit covered=yes könnte man noch experimentieren, ändert aber grundsätzlich nichts am Rendering.

Ein einfacher Straßen-way für “Die Brücke” wäre dann https://www.openstreetmap.org/way/25588220
wobei es nur darauf ankommt:

highway=motorway
bridge=yes

Und diese Brücke wird korrekt über der Bundesstraße gerendert.

@Mammi71 sind wir uns einig,
dass carto ohne Hilfestellung (covered=yes) einfache Straßen-ways unter Flächen (wir reden hier über Flächen) mit höherem layer-Wert nicht differenziert (verdeckt) darstellen kann?

Auch an dich meine Frage aus #20 “Gibts denn einen realexistierenden Renderer, der layer-Tags bei area:highway auswertet?”

covered

ohne covered:

Irgendwo in den Carto-tickets las ich, dass es überdurchschnittlich kompliziert wäre das ohne covered schön zu malen und sinngemäss: “covered mappen ist kein mappen für den renderer, weil is ja covered”

ja, kann ich mir gut vorstellen, eine unbekannte Stapelung (-1+0 oder 0+1 oder …) zu analysieren ist was anderes als eine simple Subtag-Auswertung - das ist ja der Hintergrund meiner KISS-Auswertungs-Gedanken …

Ich habe schlicht keine Ahnung, was technisch machbar ist, insbesondere ob das area:highway beim Rendern transparent gehalten werden kann. Die Behandlung der Reihenfolge halte ich für eher unproblematisch: highways mit niedrigerem layer kommen unter diese Fläche und highway mit gleichem oder höherem layer kommen darüber. Ob das “schön” aussieht halte ich zumindest bei mehr als zwei Ebenen für problematisch.

Da mich persönlich als Auswertung vorallem die Karte und das Routing interessiert erwarte ich keine “verdeckte” Darstellung von Straßen unter Brücken. Insofern habe ich mir über Renderer-Alternativen auch keine Gedanken gemacht. Wenn ich mir ansehen möchte, wie es aussieht, wenn die darunterliegende Straße verdeckt wird, dann schaue ich mir direkt das Luftbild an. :smiley:

Isja mal wieder typisch!!1 Die Radfahrer lässt man weiter im Regen stehen!!11 :rage: :stuck_out_tongue:

die Frage sollte sein: kann man das automatisch feststellen oder ist es erforderlich, dass Mapper das von Hand dazu packen. Und da ist die Antwort: klar ist es möglich. Man könnte für alle Brücken und building analysieren, ob sie Wege mit niedrigerem layer überdecken, dann mit den Wegen verschneiden und an die überdeckten Teile covered=yes setzen, vollautomatisch.
Allerdings bei einem live system wie OpenStreetMap carto eher nicht, weil das zu teuer wäre (glaube ich).

Wenn man darauf verzichten kann, dass der verdeckte Weg überhaupt dargestellt wird, dann wird es einfacher und das ginge auch in OpenStreetMap carto, z.B. indem man zusätzliche layer für Brücken auf unterschiedlichen layers einfügt, oder die Brückenflächen im selben layer rendert wie die Straßen, und das dort dann entsprechend sortiert

… eben, nur layers zwingen zum “Preprocessing” an jeder Über-/Unterführung.
Daher hätte ich Bedenken (im Hinblick auf eine pot. “best practice”-Dokumentation im OSM-Wiki) nur eine Methode zu propagieren, welche die Zugänglichkeit/Nutzbarkeit von “Open”-Daten etwas aus den Augen verliert.
Stand meiner Tests auf datensimpler covered-Basis:
https://overpass-turbo.eu/s/1dfC