Open dch0ph opened 2 weeks ago
There are a few general principles and specific issues that we would like to address that should be considered.
Regarding some of the oddities you observe:
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
leisure=track
into a later layer where they are ordered by layer
rather than area?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.cliffs
/line-barriers
still seem late i.e. should be before bridges/buildings (which are layer-oriented polygons, rather than area-oriented landcovers)waterway-bridges
to keep all "road-like things" together?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?
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.
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.
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
amenity-lines
)[Moved/new layers in italics. Addresses queries E/F.]
In terms of leisure=track
(line render), and respecting the "polygons before lines" principle perhaps:
amenity-lines
)P.S. #4726 probably also needs a layering tag.
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 withwaterway-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.
To be absolutely clear, the proposed order is:
I would consider this a sensible order under the premise that the layers themselves are as they are. But i am not tied to this - any arguments why a different order is preferable would be welcome.
As discussed in #5021, it would be useful to review layer contents rather than pushing
leisure=track
andattraction=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 whereleisure=track
mapped as an area is drawn much earlier thanleisure=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 incorporatingleisure=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]