Reviewing layer stack (ground-based non-point features)

[dch0ph]

As discussed in #5021, it would be useful to review layer contents rather than pushing leisure=track and attraction=water_slide into the first suitable option.

The current layer stack in project.mml is listed below ([] for layers / groups of layers not being considered). A, B labels for potential oddities that can be discussed / resolved.

[landcover-low-zoom]

landcover - A This is a surprisingly busy layer ranging from landcovers (where ordering by descending area makes perfect sense) to "built" items such as leisure=track, leisure=pitch, leisure=swimming_pool where it is less obvious. This leads to odd situation where leisure=track mapped as an area is drawn much earlier than leisure=track as a line feature. Features where you couldn't sensibly stack another landcover item above may be better drawn later along with buildings?

landcover-line - Currently just man_made=cutline. Seems OK. Features such as streams, tree symbols will go on top rather than being "cut" by a green stripe.

[ice sheets, water layers]

landcover-symbols - Tree symbols etc.

bridge - man_made=bridge buildings - B These two layers could be potentially combined, as it is fairly common to find bridges that are over buildings or buildings that are on bridges. This might become a "built environment" layer incorporating leisure=track etc? This would allow layering e.g. sports pitches on the roof of a building.

tunnels

landuse-overlay - military areas etc. Fine. Makes sense to "cover" buildings, but not roads.

barriers - D hedges, walls etc. This also seems late. Move forward with same logic as cliffs?

cliffs - C This seems quite late, e.g. a bridge over a cliff edge will look strange. A more logical place would seem to be after landcover-symbols?

road layers waterway-bridges - Arguably best combined with road bridges, but fine for now. Logical place for attraction=water_slide? bridges (road bridges)

aerialways - E seems too early, given that these will be above all ground features.

guideways - [should be part of roads layers]

roller-coaster

entrances

aeroways - F seems too late. Belongs with "misc roadways"?

golf-line

admin

amenity-line - This is problematic for the two features, water-slide and track that are rendered as lines rather than point symbols.

power lines

tourism / protected areas boundaries - G These seem a bit late. Before power lines?

trees - H This seems very late given they are non-blocking features. Surely they belong better with landcover symbols?

[place names, symbols, text]

[imagico]

There are a few general principles and specific issues that we would like to address that should be considered.

• We have the general principle that point symbols are rendered on top of line signatures and those on top of polygon fills when no other factors suggest something different. Reason in to avoid things getting fully hidden by other things and this way ensure a comprehensive feedback to mappers. This is why things like cliffs, line barriers and trees are shown comparatively late.
• blocking features need to be drawn in the order of their priority - mapnik does not allow anything else.
• roads need to be drawn after buildings to have a meaningful and readable display of roads between z14 (when buildings start) and z17-z19 (when roads move from being drawn wider than on the ground to less wide than on the ground).
• All polygons fills that we want drawn in a order base on size with smaller ones after larger ones need to be rendered in the landcover layer.
• Drawing order of landcover fills and water features in discussed in #3854
• For road polygon and road line ordering we have the two conflicting ideas in #2046 and #3281.
• And of course: Everything that needs to be drawn in a specific order needs to be rendered in a single layer.

Regarding some of the oddities you observe:

• B: If you want to combine buildings with anything else that only makes sense if you want to sort across feature types by either size or layer tag.
• E: Yes, aerialways IMO should be moved above all road layers
• F: aeroways have been moved out of the road layers in #2841 - some discussion can be found there. Note in the road polygons they are still combined with the highway polygons and sorted according to layer - which is inconsistent with how it is done for the linear ways.
• G: could be worth considering, have not thought about this yet.
• H: trees are currently deliberately rendered after the roads to avoid roadside trees being hidden by the road.

[dch0ph]

Thanks for pulling together these considerations. I imagined that there would be some principles behind the current ordering.

With that in mind, the queries refine to

• A Is there any merit in pulling some "small man-made features that will always be on the top", such as leisure=track into a later layer where they are ordered by layer rather than area?
• B Yes, if merging bridges and buildings (and other man-made areas from A?) ordering would be primarily by layer. Current ordering on buildings is layer primary, area secondary.
• C/D Noting the point above, cliffs/line-barriers still seem late i.e. should be before bridges/buildings (which are layer-oriented polygons, rather than area-oriented landcovers)
• E Move aerialways above all roadways. Before power lines?
• F Move aeroways after waterway-bridges to keep all "road-like things" together?
• H Good point about roadside trees. Move trees after "road-like things" (i.e. below overground features)?

P.S. I was carefully avoiding the roads layers. But a quick scan through #2046 and #3281 suggests that they might not be conflicting. #3281 ends with comment from pnorman "With what I was looking at for merging the layers was to have the areas as part of the road layer. Keeping areas as their own layer before other road layers would be much simpler." So there may be scope for incrementally simplifying the roads code?

[imagico]

This should have broader input from people knowledgeable in the respective fields.

In general i would be very careful with rendering different feature types in changing order relative to each other based on layer. This can be highly confusing for mappers because we of course can do that only in a very limited way. For roads we do that and it works reasonably well - because the principles are well established and largely also followed by many other maps. But already with roads we are having consistency issues because we order road lines and road polygons each among themselves by layer but not relative to each other. If we'd now add that for bridges vs. buildings but not for bridges vs. roads (which is the massively more common case) or for bridges vs. water polygons that would add to the confusion probably more than it would provide helpful feedback.

W.r.t. cliffs/line-barriers - keep in mind the general principle to render line features on top of polygon features unless there are specific reasons not to.

But a quick scan through https://github.com/gravitystorm/openstreetmap-carto/issues/2046 and https://github.com/gravitystorm/openstreetmap-carto/issues/3281 suggests that they might not be conflicting.

They are - you can either combine the road lines and polygons into common layers and commonly render them according to the sorting principles we have - or you move the polygons all to be rendered flatly before all linear roads. You cannot do both at the same time. Much of the past discussion of this can be found in #3872. See also the other issues mentioning #2046 and #3281.

[imagico]

I have created a new https://github.com/gravitystorm/openstreetmap-carto/labels/layering label to collect the issues that are related to the layer structure and order in the style.

[dch0ph]

If we'd now add that for bridges vs. buildings but not for bridges vs. roads (which is the massively more common case) or for bridges vs. water polygons that would add to the confusion probably more than it would provide helpful feedback.

Yes, I can see this. It only makes sense to merge layers where there is a positive case for doing so. For example, with attraction=water_slide, I thought that might combine with waterway-bridges. But then you would need a consistent drawing order. Introducing a "priority" of one feature over another would then defeat any additional flexibility of combining in the same layer.

In terms of "after roads layers", perhaps a sensible order would be

• waterway-bridges
• bridges
• guideways [moved forward. End of water/road-related layers]
• aeroways [still road-like]
• water-slide (currently poorly located in amenity-lines)
• roller-coaster
• entrances
• golf-line

[Moved/new layers in italics. Addresses queries E/F.]

In terms of leisure=track (line render), and respecting the "polygons before lines" principle perhaps:

• tunnels
• leisure-track (currently poorly located in amenity-lines)
• landuse-overlay
• barriers
• cliffs

P.S. #4726 probably also needs a layering tag.

[imagico]

If we'd now add that for bridges vs. buildings but not for bridges vs. roads (which is the massively more common case) or for bridges vs. water polygons that would add to the confusion probably more than it would provide helpful feedback.

Yes, I can see this. It only makes sense to merge layers where there is a positive case for doing so. For example, with attraction=water_slide, I thought that might combine with waterway-bridges. But then you would need a consistent drawing order. Introducing a "priority" of one feature over another would then defeat any additional flexibility of combining in the same layer.

In terms of "after roads layers", perhaps a sensible order would be

* waterway-bridges

* bridges

* _guideways_ [moved forward. End of water/road-related layers]

Should IMO go immediately after the road casing/fill layers (as long as it is a separate layer) - bridges should go after guideways.

* _aeroways_ [still road-like]

Yes, this needs to go after bridges and should be before entrances.

* _water-slide_ (currently poorly located in `amenity-lines`)

Yes, before roller-coaster is a sensible location - before bridges would also be possible.

In terms of leisure=track (line render), and respecting the "polygons before lines" principle perhaps:

* tunnels

* _leisure-track_ (currently poorly located in `amenity-lines`)

* landuse-overlay

* barriers

* cliffs

That would definitely be an improvement relative to the status quo. The ultimate question - as indicated in https://github.com/gravitystorm/openstreetmap-carto/pull/5021#issuecomment-2450636235 - would be if to combine the polygons and lines to be both rendered after buildings. But that is a bigger question which relates also to #2046. So yes, for the moment this seems a sensible choice.

P.S. #4726 probably also needs a layering tag.

Done.