Rendering boundary=forest_compartment and boundary=forest

[StC-OSM]

In various countries, forests are subdivided into compartments and the compartment numbers are painted on trees (see https://p6.storage.canalblog.com/60/26/692115/131709412_o.jpg) and/or displayed on signage (see http://fontainebleau-foret.fr/SiteEncyclo/images/img_reperes/01.jpg).

The original goal of this is for forestry workers. But it has uses for hikers and other forest users, including:

• locating yourself
• analyzing temporary information that is displayed in the forest about hunting areas, ongoing works, regulations

That is, if these boundaries and reference numbers are displayed on maps. Which is the case for instance of this public map in France (see the light green numbers and thick lines):

Rendering boundary=forest_compartment (and, optionally, boundary=forest) in the Topo map would definitely help for this. See https://overpass-turbo.eu/s/1CT9 for an example of such tags, in the same area as the example pictures above.

[Penegal]

Pretty good idea for orientation in forests with compartments!

[sylvain-m]

Very useful: I've been waiting for this for years! 👍

[quinncnl]

Should be a good addition. Will render the boundary with ref.

[quinncnl]

Will be something like this. For low zoom I'll need to check a few more cases

[StC-OSM]

wow!

[StC-OSM]

Maybe a couple of attention points, though:

• it looks like the red of paths combines with the green of boundaries to give something brownish. Maybe you'll prefer the paths to retain their color.
• it may be hard to distinguish between forest boundaries and (here) the natural reserve boundary that crosses compartments 163 to 166.

[Penegal]

* it may be hard to distinguish between forest boundaries and (here) the natural reserve boundary that crosses compartments 163 to 166.

Maybe using a dashed outlines for compartments could do it?

[waterced]

it looks like the red of paths combines with the green of boundaries to give something brownish. Maybe you'll prefer the paths to retain their color.

I was also noticing this. Keeping uniform path color would help maintaining good readability :)

[Penegal]

I was also noticing this. Keeping uniform path color would help maintaining good readability :)

It looks like a problem with rendering priorities: the roads are also under the green outline. I would say that all highway=* features should be rendered after/above compartments; these should be rendered above natural/landuse areas, but under linear features such as highways.

[quinncnl]

It looks like a problem with rendering priorities: the roads are also under the green outline. I would say that all highway=* features should be rendered after/above compartments; these should be rendered above natural/landuse areas, but under linear features such as highways.

Currently boundary and texts are rendered in label layer and roads are rendered in background layer. I would prefer adding compartments in label layers as other boundaries, which are on top of roads. We can also add some offset to the boundary to avoid covering the path between two boundaries. I'll give both a try.

[quinncnl]

Dashed boundary is too noisy I think. I added offset and only render compartments from z15.

Edit: offset still not good when there is not way in between :(

[quinncnl]

There is a temporary limitation: only relation compartments are rendered and way are not. This is due to the lua transformation script (https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.lua#L56) needs to be changed to recognize compartment as polygon. A full database reload will be needed for this.

[quinncnl]

@Penegal It's indeed better with compartment under roads. There is a minor issue with label overlapping (see "HSA 02"). I tend to keep it as is. I'll render this area for preview.

[quinncnl]

I've manually refreshed this part of map for preview: https://tracesmap.com/#15/48.4171/2.5138/topo If you have more suggestions please reply.

[StC-OSM]

I tended to like the green numbers more than the black ones.

As for boundaries, now it's the red paths that change how we see the green boundaries. The way visual perception works is sometimes frustrating :-) But overall, as soon as you zoom enough it works well!

Edit: I've tried this with OsmAnd on my iPhone. I believe that the boundaries should appear in one or even two more zoom levels, because currently it is hard to see more than one compartment at a time.

[Penegal]

Agree with @StC-OSM: green labels would be better, I think, even if it's only to highlight the logical link between labels and green boundaries.

[quinncnl]

As for boundaries, now it's the red paths that change how we see the green boundaries. The way visual perception works is sometimes frustrating :-) But overall, as soon as you zoom enough it works well!

Overlapping elements are hard to visualize in general. We have to make a choice and sacrifice something :)

Edit: I've tried this with OsmAnd on my iPhone. I believe that the boundaries should appear in one or even two more zoom levels, because currently it is hard to see more than one compartment at a time.

I've made it appear from z14 and ref from z15.

Green label doesn't blend very well. I prefer using slightly darker boundary color.

[quinncnl]

For now it'll be like this. I'll close the ticket. The updated source code will be synced later.