Openstreetmap-carto: Areas rendering order

[Tomasz-W]

Current rendering order makes some bugs or problems with displaying data.

2641 #2782

Examples:
http://www.openstreetmap.org/#map=19/52.40698/16.96147 (piece of landuse=forest missing on landuse=grass)
http://www.openstreetmap.org/#map=19/52.38318/16.95716 (piece of landuse=residential area protrudes over landuse=meadow)

I took and concider all tags from landuse=* , leisure=* , natural=* and tourism=* keys, which are allowed to map as areas, and analyze them, trying to order logically as layers.

Main assumptions:

• Waters and rock/ stones above green landcovers
• Higher plants above lower plants
• Physical coverage areas above areas describing terrain usage
• Treating parks and village greens as groups of unspecified plants

Problem to solve:
An unavoidable direction which is OSM moving towards is more, and more precision. This means eg. covering an amenity=* areas by physical elements like buildings, grass or pitches. Then this cultural amenity=* or tourism=* areas becomes unvisible, and the only thing left is a label text. The same thing happens with parks overdrawn by certain types of plants, what causes loss of area park-status information, and loss of park borders information.

Examples:
http://www.openstreetmap.org/way/66266360 (barely visible amenity=hospital)
http://www.openstreetmap.org/#map=19/52.38752/16.94985 (amenity=kindergarden with grass pieces missing)
http://www.openstreetmap.org/way/336645782 (barely visible amenity=school)
http://www.openstreetmap.org/way/257507437 (barely visible leisure=park)
http://www.openstreetmap.org/way/4685998 (barely visible leisure=park)

In my opinion, way_area key works good only between physical man-made landcover areas (group 5 on my list) and physical natural landcover areas (group 6). For example: small amenity=parking is rendered above large landuse=forest in the suburbs, but on the other hand, small landuse=grass pieces are rendered above larger amenity=parking area in the cities.

I very like the way, how landuse=military is rendered. That half-transparent color overlay (even without skew stripes) allows to show both things - physical landcover and area usage information - at once (example: http://www.openstreetmap.org/way/236175277 ). I think we should discuss using this method for all areas from groups 3 and 4, or, at least, discuss darker outlines like there are now around amenity=zoo areas (example: http://www.openstreetmap.org/way/480832184 )

List description:
I divided all of tags (treated only as areas, not points or labels) to 8 main groups. If something is listed in one string, it means that this elements are equal, and shouldn’t be mapped one on another. Proposed layers list begins from the highest to lowest level.

1. Waters:
   1.1. Natural=wetland
   1.2. Landuse=basin, Landuse=salt_pond, Leisure=swimming_pool, Natural=hot_spring, Natural=water

2. Rocks, stones etc.:
   2.1. Natural=rock, Natural=stone
   2.2. Natural=sinkhole
   2.3. Natural=scree, Natural=shingle
   2.4. Natural=bare_rock
   2.5. Landuse=quarry
   2.6. Natural=glacier

3. Partly-physical, man-made areas:
   3.1. Amenity=* (all amenity areas excluding 5.2. group), Landuse=cemetery, Landuse=military, Leisure=dog_park, Leisure=golf_course, Leisure=miniature_golf, Leisure=sports_centre, Tourism=*

4. Partly-physical, natural areas (unspecified type of landcover/ plants):
   4.1. Landuse=village_green, Leisure=park

5. Physical, man-made landcovers:
   5.1. Landuse=landfill, Leisure=fitness_station, Leisure=pitch, Leisure=playground, Leisure=stadium, Leisure=track
   5.2. Amenity=bicycle_parking, Amenity=motorcycle_parking, Amenity=parking, Amenity=shelter, Amenity=taxi

_In case of collision between groups 5 and 6: way_area key, taking the highest one tag from each group (if there are more than 2 areas overlapping)_

1. Physical, natural landcovers (certain types of landcover/ plants):
   6.1. Landuse=forest, Natural=wood
   6.2. Landuse=orchard, Landuse=vineyard
   6.3. Landuse=farmland
   6.4. Natural=heath, Natural=scrub
   6.5. Landuse=meadow, Natural=grassland
   6.6. Landuse=plant_nursery, Leisure=garden
   6.7. Landuse=grass
   6.8. Natural=mud
   6.9. Natural=beach, Natural=sand

2. Non-physical landuses:
   7.1. Landuse=allotments, Landuse=brownfield, Landuse=commercial, Landuse=construction, Landuse=depot, Landuse=farmyland, Landuse=garages, Landuse=greenfield, Landuse=greenhouse_horticulture, Landuse=industrial, Landuse=port, Landuse=railway, Landuse=recreation_ground, Landuse=religious, Landuse=residential, Landuse=retail

3. Geographical regions:
   8.1. Natural=bay, Natural=cape, Natural=fell

Some of these tags are not rendered now, but I included them on a list, because they could be rendered in a future (eg. Leisure=fitness_station). I’m not sure is it everything, so if I missed some rendered tag - let me know in a comment.
What are your thoughts about this order proposal?

[matthijsmelissen]

So if I understand you correctly, you propose ordering landuse first by feature type, and only then by area size. Water and natural features should always be rendered on top. So for example if we have a small commercial area in an otherwise bare_rock landscape, the commercial area will be hidden by the bare_rock area. Do I understand that correctly?

I'd recommend you to set up the rendering chain and start playing with the code for yourself, if you immediately see the results of your ideas it's much easier to see what works and what works not. If you have any problems in getting it working, or if you need help in what to change to accomplish what you want, we'll gladly help.

[Tomasz-W]

So if I understand you correctly, you propose ordering landuse first by feature type, and only then by area size. Water and natural features should always be rendered on top. So for example if we have a small commercial area in an otherwise bare_rock landscape, the commercial area will be hidden by the bare_rock area. Do I understand that correctly?

Yes, exactly.

[pnorman]

I've done this with some styles, and to evaluate the order proposed it really takes some demo code.

[matthijsmelissen]

So for example if we have a small commercial area in an otherwise bare_rock landscape, the commercial area will be hidden by the bare_rock area.

I don't think this is desirable. There are also some more similar problems in the proposal. I'm therefore going to close this issue. However, any new proposals are always welcome.

[jidanni]

Also note https://github.com/gravitystorm/openstreetmap-carto/issues/3435 .
I think addresses should be given the highest priority.
E.g., a house's address shouldn't be blocked by a water tank without one.

[matkoniecz]

#3435 is open. It means that it is known problem waiting for someone to handle it. If you are interested you may either discuss problems mentioned there (if any) or write the necessary code - if you need help write why you are stuck.

But please immediately stop spamming the same message across the entire issue tracker.

[BjornRasmussen]

I would really like to see a fix for this. I think that landcover should be rendered above all landuse, and with a 0.5 opacity, similar to Wikimedia maps.


This would solve the current issue of hideous rendering in many places.

[matthijsmelissen]

I would really like to see a fix for this. I think that landcover should be rendered above all landuse, and with a 0.5 opacity, similar to Wikimedia maps.

Where do you see a difference in landcover ordering between the two maps you link?

hideous rendering

Insulting the project is probably not the best way to convince people of your viewpoints.

[matkoniecz]

landcover should be rendered above all landuse

What you consider to be landuse and what you consider to be landcover?

Have you considered cases where given area is tree covered and at the same time is university/industrial area/etc?

[BjornRasmussen]

I meant "confusing" , not "hideous", and did not mean to insult the project. 😞 I just chose the wrong words.

Where do you see a difference in landcover ordering between the two maps you link?

OSM Carto renders smaller landuse / landcover polygons on top of larger ones, regardless of type. Some other renderers render landcover as a transparent overlay, with landuse (e.g. Parks) underneath. This ensures that both landcover and landuse are always visible. Osm Carto can sometimes completely hide certain features, which can be confusing.

[BjornRasmussen]

What you consider to be landuse and what you consider to be landcover?

I consider things that represent the cover of the earth to be landcover. This includes wood, scrub, grass, meadow, farmland, and beach. I consider landuse to be for describing what the land is used for. This includes nature reserves, parks, residential landuse, commercial landuse, industrial landuse, etc. Landuse often aligns with parcel boundaries (the outline of a public park), but not always.
Landuse and landcover are usually not connected, but can be in some cases.

[BjornRasmussen]

Have you considered cases where given area is tree covered and at the same time is university/industrial area/etc?

Those cases are the issue. The smaller of the two (wood VS industrial area) blocks the other.

[matkoniecz]

The smaller of the two (wood VS industrial area) blocks the other.

Can you give example of place where both wood full colour and wood pattern is blocked?

[BjornRasmussen]

The wood pattern will always show, so no. The color can become blocked very easily, though, as can be seen in the image above.
Entire parks becoming invisible is possible, however.

[dieterdreist]

sent from a phone

On 24. Dec 2018, at 05:56, Leif Rasmussen [e-mail] wrote:

I consider things that represent the cover of the earth to be landcover. This includes wood, scrub, grass, meadow, farmland, and beach. I consider landuse to be for describing what the land is used for.

from this list I would consider beach and farmland not landcover, the latter a landuse, beach neither. Meadow can be both, landuse and landcover

[pnorman]

a 0.5 opacity, similar to Wikimedia maps.

We don't use opacity like that because it leads to confusing colours. In fact, this was identified as a problem with the wikimedia style, where you'd end up with all sorts of shades of green, all slightly different, with no obvious difference in meaning.

This issue is about a specific order. As I noted above,

I've done this with some styles, and to evaluate the order proposed it really takes some demo code.

If you have a proposed order, please provide some demo code so we can consider it.

[jidanni]

All I know is road names should always be readable. On https://github.com/gravitystorm/openstreetmap-carto/issues/2796#issuecomment-449655047 only in the second photo are road names readable, on all devices, I suppose.