Render barriers above highway areas

[matthijsmelissen]

Barriers should be rendered above highway areas.

If not, barriers between highway areas become invisible.

Examples:
http://www.openstreetmap.org/#map=18/52.53296/13.37229

See also https://trac.openstreetmap.org/ticket/2807.

[matthijsmelissen]

I think we should be able to change the rendering order, and draw barriers on top of areas.

Should barriers also be drawn on top of buildings, and on top of regular roads?

[Theodin]

I think they should. Like benches and other things I cant think of at the moment :)

[matkoniecz]

Drawing on top of regular roads would result in weird things, as rendered road may take more space that in reality. See this hedge for an example: http://www.openstreetmap.org/?mlat=50.07075&mlon=19.89828#map=18/50.07075/19.89828 (and zoom out).

[matthijsmelissen]

Let's decide on #623 first.

[Theodin]

@mkoniecz: Isnt that "just" a rendering issue as it depends on how you adjust the size with the zoom levels no matter what is rendered first?

[matkoniecz]

Isnt that "just" a rendering issue as it depends on how you adjust the size with the zoom levels no matter what is rendered first?

Yes, but rendering barrier on top of parallel road is uglier and more confusing than hiding barrier under road.

And at this moment barriers are rendered on top of highway areas (original example is gone, but I found http://www.openstreetmap.org/way/200980711#map=19/50.06105/19.93630).

[matthijsmelissen]

And at this moment barriers are rendered on top of highway areas

No, only in this case because the barrier is explicitly defined as inner element of the multipolygon.

[pmailkeey]

This looks like a case of the common breach of common sense that states a rendering order of :
largest areas first to smallest areas;
All lines on top of areas
shorter lines on top of longer lines
points over everything.

As otherwise data will be hidden.

The question is, when will this be implemented ?

[kocio-pl]

What is current status of this issue and how difficult it would be to make it work?

[matthijsmelissen]

I didn't look into it, simply moving layers around might work.

[kocio-pl]

We have 79 layers, so it's not trivial to know where to start, even though they have clear names. I believe important ones for this issue are (in order of appearance):

  - id: "line-barriers"
  - id: "area-barriers"
  - id: "highway-area-fill"
  - id: "roads-fill"
  - id: "turning-circle-fill"

My questions:

1. What is the meaning of layer definitions order - which ones are rendered above?
2. Is it important to have "-" before "id:" in YAML? Some lines miss it.

Wild guess: probably just moving -barriers (probably without touching water-barriers-) after -fill could be the solution?

Hint - current list of all osm-carto layers:

  - id: "world"
  - id: "coast-poly"
  - id: "builtup"
  - id: "necountries"
  - id: "landcover-low-zoom"
  - id: "landcover"
  - id: "landcover-line"
  - id: "water-lines-casing"
  - id: "water-lines-low-zoom"
  - id: "icesheet-poly"
  - id: "water-areas"
  - id: "landcover-area-symbols"
  - id: "icesheet-outlines"
  - id: "water-lines"
  - id: "water-barriers-line"
  - id: "water-barriers-poly"
  - id: "marinas-area"
  - id: "piers-poly"
  - id: "piers-line"
  - id: "water-barriers-point"
  - id: "bridge"
  - id: "buildings"
  - id: "buildings-major"
  - id: "tunnels"
  - id: "landuse-overlay"
  - id: "line-barriers"
  - id: "cliffs"
  - id: "area-barriers"
  - id: "ferry-routes"
  - id: "turning-circle-casing"
  - id: "highway-area-casing"
    id: "roads-casing"
  - id: "highway-area-fill"
  - id: "roads-fill"
  - id: "turning-circle-fill"
  - id: "aerialways"
  - id: "roads-low-zoom"
  - id: "waterway-bridges"
  - id: "bridges"
  - id: "guideways"
    id: "admin-low-zoom"
  - id: "admin-mid-zoom"
  - id: "admin-high-zoom"
  - id: "power-minorline"
  - id: "power-line"
  - id: "nature-reserve-boundaries"
  - id: "tourism-boundary"
  - id: "trees"
  - id: "country-names"
  - id: "capital-names"
  - id: "state-names"
  - id: "placenames-medium"
  - id: "placenames-small"
  - id: "stations"
  - id: "stations-poly"
  - id: "amenity-points-poly"
  - id: "amenity-points"
  - id: "power-towers"
  - id: "power-poles"
  - id: "roads-text-ref-low-zoom"
  - id: "junctions"
  - id: "bridge-text"
  - id: "roads-text-ref"
  - id: "roads-area-text-name"
  - id: "roads-text-name"
  - id: "paths-text-name"
  - id: "text-poly-low-zoom"
  - id: "text-poly"
  - id: "text-line"
  - id: "text-point"
  - id: "building-text"
  - id: "interpolation"
  - id: "addresses"
  - id: "water-lines-text"
  - id: "ferry-routes-text"
  - id: "admin-text"
  - id: "nature-reserve-text"
  - id: "amenity-low-priority"
  - id: "amenity-low-priority-poly"

[matthijsmelissen]

1. What is the meaning of layer definitions order - which ones are rendered above?

The order in which they are defined is the order in which they are rendered.

[gravitystorm]

1. Is it important to have "-" before "id:" in YAML? Some lines miss it.

The - indicates the start of the next item in an array. So sometimes the - appears before the id attribute, sometimes before a different attribute (e.g. name):

  - name: "roads-casing"
    id: "roads-casing"
    class: "roads-casing"

[kocio-pl]

The closer inspection in #2394 shows that it can have nasty side effects on roads, so closing it as wontfix until some sane solution is proposed.

[jeisenbe]

Reopened; while PR #2394 was not a good solution, it may be possible to address this by rendering highway areas earlier, as in #3872

[jeisenbe]

#3872 was closed, so it appears this issue will not be fixed

[BertMule]

I also miss this feature along the sense of pmailkeey.

Examples:

• Hedge on a pedestrian area, like I would expect just like a tree row or trees. All visible in Amersfoort currently.
• Walls on a pedestrian area. As in Makkum.