Use a random symbology for forests

[pnorman]

This adds a random symbology for forests, lightens forests, and unifies natural=wood and landuse=forest rendering.

The colours for landuse=forest and natural=wood have been unified and slightly lightened.

z10

At higher zooms, a randomized symbology has been added, designed to not imply a particular type of forest.

z15

z16

As the new symbols are an overlay, they show even if there is another landcover within the forest.
z15

They are a repeating 512x512 pattern, which is hopefully large enough that the repeating nature of the pattern can't be seen.

z16, original not shown

With woods and forests no longer being primarily one colour, the name text and halo was reworked

z17

Unfortunately I was unable to find a tree symbol that does not imply something about the type of tree, but this does open up the door to using different symbols for different types of forests (#822)

landuse=forest and natural=wood now render the same. For some mappers there was a difference between what they meant - unfortunately the difference varied among mappers, making the two different tags effectively the same globally (#647 (comment)) and the distinction between them useless. This was also not captured in the existing cartography.

Fixes #938
Fixes forest part of #937
Closes pnorman#6

Thanks to @SK53 for symbol selection and @imagico for the point generation tool.

[pnorman]

Some more examples

streams

lower-zoom footways

narrow woods and military/wood combo

[HolgerJeromin]

IMO the "icons" are to turbulent if there are large areas shown. Probably because it is sharper than the old version.

[pnorman]

IMO the "icons" are to turbulent if there are large areas shown. Probably because it is sharper than the old version.

How would you suggest improving it?

[kocio-pl]

New icons are too visible for me - comparing to the old ones it is bigger and consists of pair of symbols. I would make it the same size as before and use only one symbol instead of a pair (512x512 box gives us a comfort of using both symbols semi-randomly, we don't have to squeeze them all in every point).

As the new symbols are an overlay, they show even if there is another landcover within the forest.

Is there a way to avoid it or we're bound to it by the nature of the overlays?

I think that for example glades/clearings should be clean. It is easy to recognize them as part of the forest just because they are completely surrounded by it.

Also some residential areas can be placed inside the forest/woods, but if we need to show the trees there, we should just extend the forest area to cover it.

[EdLoach]

I might have misunderstood the comment above, but glades/clearings where there aren't trees will be holes in the existing multipolygon (or need fixing). Similarly for residential areas inside such areas.

[kocio-pl]

Maybe I got it wrong - the icons will be visible only if the other landuse is NOT an inner relation element (forest being the outer one)? I would support it then, since sometimes included landuse is so full of trees, that you can't really say the forest stops on the edge of it, yet it is useful to see this landuse being there.

[imagico]

First of all the color seems an improvement from the examples shown and unifying it with forest seems a good idea as well.

Now the critical remarks:

• Color needs to be tested against other vegetation landcovers, in particular scrub. Also how does it look together with trunk roads?
• Contrast between wood and water still seems suboptimal - maybe considering the radical idea of darkening the water color would be an option.
• The pattern appers somewhat strong in many cases which could be both due to the symbols, their relatively large size and the choice of color.
• I do not really like the paired rendering of tree types since it introduced a regular arrangement into an otherwise irregular pattern. It would be better to randomly vary the symbols i think. jsdotpattern already supports this. You can specify an array of strings instead of a single SVG string in symbols.js to use this. I included your symbols and a variant with a triangle tree symbol (see next point) in the deployed version. Note the automatic offset calculation is still broken as you noticed.
• A triangle shaped rendering of the conifer tree might be a better fit than the branched version used right now.
• How about using a regular pattern as before instead of the irregular one to indicate landuse=forest in contrast to natural=wood.

Generally with regards to landcover overlays (in particular also for wetland) i thought about introducing a lower way_area limit in the range of 10-100 pixel to avoid irritating isolated partial symbols. This of course will lead to problems with fine grained splitting of mapping but i am not sure how much problem this would be in reality.

Here my quick try with random symbol selection and triangle shaped conifer symbols:

I would also consider making the symbols smaller even if this makes them blurry - at 80 percent size they are still recognizable and the more blurry lines could make them less disturbing.

[HolgerJeromin]

The name of the forest is more important than the icons. So i would make the icons much lighter.

[SK53]

Broadly I think this is a good discussion with plenty of salient points. Many thanks to Paul for the work he has put in so far.

I really have only one point to add which is about the choice of a dual tree symbol rather than a single tree. The idea was taken from the Thunderforest Landscape layer, but the principle behind this choice is important.

A choice of any single tree symbol as a generic symbol will always be inappropriate somewhere in the world, the current (conifer) symbol is really only appropriate in northern areas (boreo-temparate zones). A broad trawl through a variety of sources failed to find single tree symbols which are not instantly recognisable as either conifer or broad-leaved, so either one has a dual symbol or a mixture of two symbols (as suggested by @imagico).

At least for me, one of the ideas of this woodland cartography is to encourage better tagging of forests and woods, either with the currently supported wood tag or the leaf_type tag. I would therefore like the symbolisation to discriminate between undifferentiated woodland and the main types: coniferous, broad-leaved, and mixed. If the symbology of the undifferentiated woodland is less attractive than those tagged with a type, this may result in more attention to this matter by mappers. In this case the paired symbology would be distinct from the random symbology which I would reserve for wood/leaf_type=mixed.

I know advocating use of a perhaps sub-optimal symbology as a nudge for better mapping might go against the grain, but there it is.

A minor point, I do thing @imagico's triangular conifers work better, not necessarily in their own right, but the in the current version the broad-leaf symbol looks much more stylised than the conifer symbol. Changing to the triangular form reduces that discrepancy.

[nebulon42]

I like this very much and think that this is definitely an improvement. I'm also in favour of lightening forest. Some comments/suggestions:

• This colour is definitely better, but I'm not sure if we should adjust the colour more. I will have get used to it first. (similarity with trunk road remains)
• I like that the symbols are showing up on landuses that are not in the multipolygon relation, this will encourage cleaning up these things.
• The symbols are rather prominent, lowering the opacity to 0.5 or even to 0.4 would help. Also using alternating symbols as proposed could be an improvement. They should be more unobtrusive.
• The symbols are showing up too early and thus adding a lot of noise to the map. I would propose to render them at z13 at the earliest or maybe at z14 depending on how noticable they are. Maybe fading them in at increasing zoom level by using opacity would be also an option. (This may be no longer an issue when symbols are less prominent.)
• Forest names seem too yellowish, because of the halo. Maybe using white with transparency like rgba(255, 255, 255, 0.7) for it (as in Add transparency to halo placename labels #1210)?

[althio]

I also find it an improvement
Other people already voiced concerns with good suggestions, so I will just 'add +1' to:

• name text and halo: not visible enough, lacks contrast
• contrast forest/water is worse now
• paired symbols are heavy, alternate symbols are better
• regular pattern for forest vs random for wood

[imagico]

If the symbology of the undifferentiated woodland is less attractive than those tagged with a type, this may result in more attention to this matter by mappers. In this case the paired symbology would be distinct from the random symbology which I would reserve for wood/leaf_type=mixed.

That is a good point. Still as long as the type is not rendered it is really not necessary to reserve the good looking style for mixed type woodland. When support for differentiating types in rendering is added the unspecified type could be easily downgraded to a less attractive pattern.

One option to improve the paired rendering would be to randomly swap the pairs.

Triangle vs. branches - i have to admit i am probably somewhat biased in this regard since i am very used to the German tradition of even more abtract open triangle/circle shape rendering. I do not consider this a very important aspect, keeping the connection to the traditional rendering in the OSM-style has advantages too.

[pnorman]

As the new symbols are an overlay, they show even if there is another landcover within the forest.
Is there a way to avoid it or we're bound to it by the nature of the overlays?

I think that for example glades/clearings should be clean. It is easy to recognize them as part of the forest just because they are completely surrounded by it.

Glades and clearings would not normally be within a forest polygon.

[kocio-pl]

Glades and clearings would not normally be within a forest polygon.

What about multipolygons?

[pnorman]

Colours

The colour has not significantly changed from the old wood colour, so basically any issues with

Color needs to be tested against other vegetation landcovers, in particular scrub.

Yes - new forest to scrub distance is insufficient at 5.9. It wasn't great before with old wood/scrub at 7.1. for reference, residential/land is 6.4 and commercial/retail is 7.7.

Of course, they both have symbols. I'll take another look at all three colours, as I'd like to have a consistent hue for all three.

Also how does it look together with trunk roads?

About as bad as before. I want to adjust road colours, but not in this PR.

Contrast between wood and water still seems suboptimal - maybe considering the radical idea of darkening the water color would be an option

new forest/water contrast is 27.2, which is actually an increase from old wood/water and scrub/water. Darkening the water (or forests) wouldn't increase contrast much - the difference between them comes from the chroma and hue angle.

Polygons

What about multipolygons?

Multipolygons do not normally exist in the rendering database but in any case, it remains the same - a clearing within a forest will have had a hole cut out, and that hole is not within the polygon.

Regular patterns

How about using a regular pattern as before instead of the irregular one to indicate landuse=forest in contrast to natural=wood.

Removing the difference between landuse=forest and natural=wood is intentional, as there is no consistent difference between the tags.

Symbols

The choice of a dual symbol is quite intentional - I need a symbol that does not imply one type of tree or mixed trees, but an unknown type. Unfortunately, I can find no single icon that does that. Suggestions are of course welcome, but both myself and @SK53 looked for a generic tree symbol and couldn't find one.

The triangle symbol is an improvemnt, as it has the same amount of stylization, and also will probably work better at smaller sizes.

I will be re-generating with a new symbol, making use of the undocumented symbol list feature to give different left/right pairs.

Text

Forest names seem too yellowish, because of the halo. Maybe using white with transparency like rgba(255, 255, 255, 0.7) for it (as in #1210)?

That is basically what it is doing - the colour chosen is a mix of the forest background and white. The name colour could use some adjustment. I'm not particularly sure it's any worse than the old labels or the old park label.

More in the next couple of days when I can work on it again

[polarbearing]

The choice of a dual symbol is quite intentional

While I would prefer the randomised mix of symbols, if you want to go with the dual symbol the trees could be slightly shifted vertically against each other, so they do not stand too neatly on the same line.

[kocio-pl]

I thought that if we're not sure what type of trees are in the forest/woodland, we may make a pair of different trees, but in a V-shaped icon (common roots would suggest ambiguity more than two paralell symbols).

But then I thought this may be too complicated (especially because we have limited pixel matrix) and we could make one mixed symbol like that: a triangle based symbol with peak on top, but also with a rounded bottom.

[imagico]

Thanks for addressing the issues brought up.

Color

Your deltaE values are in line with what i would have assumed - other close colors are probably orchard and vineyard. But in practial application differences in brightness are much more important than in tone since output devices, in particular the more crappy ones (laptops, office monitors) are much worse in differentiating color than in differentiating brightness.

My suggestion would probably be to lighten the pattern color a bit but to keep the base color as it is for the moment - the number of very similar green tones currently used for area coloring is not really discernable though - this will need to be either extended to brighter colors for the various grass tones or by unifying different types and differentiating only by pattern.

Symbols

I am not really convinced that a mixed pattern is not an option as long as the woodland type is not taken into account at all - see my reply to @SK53. The paired pattern works very well as an indicator for missing tags encouraging the mapper to add them but if more precise tagging does not lead to a change in pattern this effect is wasted and counterproductive.

The paired trees do look much better with random swapping IMO - if they are put fairly close together so they really function as a single symbol:

[SK53]

@polarbearing I had already mention to pnorman that offsetting the two icons might enable getting them even closer, but havent yet tried it.

@kocio-pl the common root is a great idea, but probably doesnt work at this scale.

One other thing I noticed looking at British Ordnance Survey maps is that tree symbols have a 'foot', presumably representing a shadow (from the NW):

Again this might be too busy for the scale, but again I think its probably something to note for future use.

@imagico I experience a slight optical illusion with the icons appearing to slant away from the triangle (conifer) side so it might need a bit of tweaking.

[imagico]

I experience a slight optical illusion with the icons appearing to slant away from the triangle (conifer) side so it might need a bit of tweaking.

This is to be expected with the triangle shape close to something else on one side. But i suppose such effects are much weaker in actual use of the pattern (lower contrast and combined with other elements). But there certainly is room for variation.

[kocio-pl]

@imagico: Such smaller and more abstract symbols glued together are acceptable for me for a general forest. What I'm also interested in is how will we render each type of forest (especially mixed) in this case - it should be visually more "attractive", to encourage mappers to tag more details.

[mboeringa]

@kocio-pl

New icons are too visible for me - comparing to the old ones it is bigger and consists of pair of symbols.

@HolgerJeromin

The name of the forest is more important than the icons. So i would make the icons much lighter.

@nebulon42

The symbols are rather prominent, lowering the opacity to 0.5 or even to 0.4 would help. Also using alternating symbols as proposed could be an improvement. They should be more unobtrusive.

Agree with all the above remarks. It needs more subtlety, most likely starting with a lighter color of the symbol (example @nebulon42), and possibly smaller icons, and maybe less dense. The first - not paired - example of randomized symbology of @imagico also seems to hold some promise.

[pnorman]

The name colour has been changed back to darkening by 30. The calculation is carried out in a perceptual colourspace, avoiding the hue and chroma shift inherent with darken() which changes more than lightness.

CIE76 ΔE values

I am fairly happy with the new symbols

Grass has been shifted away from yellow

scrub is distinguishable

[althio]

I think that the labels should be compared to the fill color but also to the pattern color.
Patterns are quite disturbing when you read something on them.
I don't know if you have any guidelines on color for name labels(?).
For forest name on forest landuse: I would suggest to radically improve readability with good contrast like the island name label on forest landuse.

[kocio-pl]

As for me, the name name of the forest is hardly visible and the icons are a bit too dark (but at least now they have proper size and shape).

[imagico]

I think this is an improvement, the changed base color is now a bit closer to the water color again though.

I would still lighten the pattern symbols to be somewhat less prominent, maybe in turn use a somewhat denser pattern. This would improve readability of the labels as well.

Not too sure about the grass color change - unifying grass and grassland is a good idea - on high zooms grassland could use a pattern for distinction though (but that's for a separate change). Making it less yellow makes it less distinguishable from other greens however. The yellow tone might seem less intuitive in humid regions but it is actually quite fitting in other parts of the world where grassland usally dries up during the dry season.

[matkoniecz]

and for location provided by @nebulon42 (#1242 (comment))

https://cloud.githubusercontent.com/assets/899988/8937920/ae130a8a-355b-11e5-9eb5-603cd4c6de60.png

[kocio-pl]

For me this example proves it further that z>=12 is too early: z12 is worse and z=13 is better, but worse than with no pattern, because tracks are too dense. Probably z=14 and z=15 could gain some readability if the pattern was toned down.

[imagico]

Ok - i have some more options here. First of all i moved away from the tree pair concept. We have seen a lot of variations of this already but it is very strong and possibilities to weaken its appearance while keeping it readable are limited. And ultimately it might make more sense to simply use no pattern at all for woodland of unknown composition - it well communicates something is missing (i.e. supplementary tags).

So the following suggestions include different variants for leaf_type=broadleaved, leaf_type=needleleaved and leaf_type=mixed. This is currently not available of course. As a temporary solution until this changes it would be possible to use the mixed variant of course.

First the simple tree symbols that were already used above in a denser and a coarser arrangement. Color is fairly low contrast similar to the last one @matkoniecz showed. The coarser pattern looks less noisy in the abstract sample of course but keep in mind that with small polygons large symbol distances often do not work well.

Second are somewhat more complex tree symbols - the broadleaved one is already used in the swamp pattern. In my opinion these might work better since they are more intuitive especially in cases where the shape is not perfectly clear (due to low contrast or other interfering elements).

As a third possibility i tried a pure structure pattern without distinct symbols. This is kind of meant to resemble a view from above. The mixed variant is somewhat difficult to get right of course. Two variants with slightly different settings:

The huge advantage of this would be it does not require the symbols to be readable, it works with less contrast between pattern and background color and has less problems with small polygons. But of course it is also less explicit in meaning.

And finally a quick glance on the possibility to illustrate leaf_cycle by varying the overlay color. Not sure if this is a good idea but might be worth testing.

I won't test all the different variants in actual rendering but you can try out the ones you find promising yourself - here are the pattern images:

http://www.imagico.de/files/smixed2_overlay.png
http://www.imagico.de/files/smixed_overlay.png
http://www.imagico.de/files/sbroad2_overlay.png
http://www.imagico.de/files/sbroad_overlay.png
http://www.imagico.de/files/sneedle2_overlay.png
http://www.imagico.de/files/sneedle_overlay.png

http://www.imagico.de/files/cmixed2_overlay.png
http://www.imagico.de/files/cmixed_overlay.png
http://www.imagico.de/files/cbroad2_overlay.png
http://www.imagico.de/files/cbroad_overlay.png
http://www.imagico.de/files/cneedle2_overlay.png
http://www.imagico.de/files/cneedle_overlay.png

http://www.imagico.de/files/mixed4_overlay.png
http://www.imagico.de/files/mixed3_overlay.png
http://www.imagico.de/files/broad_overlay.png
http://www.imagico.de/files/broad3_overlay.png
http://www.imagico.de/files/needle_overlay.png
http://www.imagico.de/files/needle2_overlay.png

[dieterdreist]

very nice work Christoph. From the icons I prefer the more complex ones, especially that they are "grounded" by a small piece of soil/cast shadow, this is an important graphical detail the simple symbols are missing.

I also like the abstract "top view" a lot from a graphical point of view but I feel that it might suggest more detail than there is actually mapped (especially in the mixed version but also in the others, people might think that these are actual trees rather than just an abstract representation of a kind of tree).

[mboeringa]

@imagico: good work, I like the subtle colors and symbols of the latest suggestions, we're finally getting in the direction of something that would not dominate the entire map, but meld-in with the rest.

Personally, I am in favour of the simple small symbols and a coarser pattern density, but with the subtle colors you used, the complex symbols aren't that distracting anymore, although I would still recommend the sparse distribution for those symbols.

The idea of the "patterns" is a nice one as well, although you may be right, that this is less meaningful. I do think it would be nice to see some real world examples of the use of this pattern though against the true data, instead of the sample squares presented here, to get a more informed opinion about this option.

[SK53]

Minor comments:

• I never measured symbol density on the maps in the original blog posts: perhaps I should have done so. I prefer the coarser symbol distribution, but suspect that I would like something in-between the two examples more. (I am also interested in a later possibility of interspersing tree symbology with other symbols to show other wood/forest properties but not on the standard render)
• The tree 'footer' was something I had noted in many prior cartographic examples and does really add something.
• The colour distinction for leaf_cycle is very subtle, but I thing familiarity would increase recognition. Of course I'm very much in favour of something which will encourage better mapping.
• For completeness a very abstract (circles & triangles) style perhaps ought to be considered.

Again I think the Krakow example should be tested with these: I was quite surprised how intrusive the symbology was at that scale, and felt that we had missed capturing something subtle from similar printed maps.

[matkoniecz]

felt that we had missed capturing something subtle from similar printed maps

From your examples - note how on and https://upload.wikimedia.org/wikipedia/commons/6/64/Country-side_around_Troitsk%2C_Moscow.png tree symbols are kept from intersecting paths/roads.

Compare with

(full image - https://camo.githubusercontent.com/e2c3f41b34f67b5f217369ac4b1bb9a07cb3bbfc/687474703a2f2f692e696d6775722e636f6d2f31704f354d4c762e706e67 )

[SK53]

@matkoniecz Indeed, but this is not something we can do with the current approach as an overlay. I suspect the OSGB StreetView actually cuts out the green pattern for forests/woods entirely when a path or track is shown, but 1:50k OSGB does not do that http://binged.it/1VUHvdf (and multiple overlays make it fairly difficult to read).

[imagico]

Thanks for the comments.

• regarding symbol density - i chose the extremes of the range i consider useful here for single tree symbols (for pairs you might make it even coarser but that's part of the problem why this works poorly). In between densities are possible of course - densities used in jsdotpattern were 17 and 28.
• regarding color - in the abstract samples the low contrast is not much of a problem of course - if this also works in real use remains to be seen. There is of course also the possibility to fade in the symbols when zooming in, i.e. make them more subtle at the low zooms but stronger at the higher levels. For the leaf_cycle coloring - the required color difference depends a lot on how heavy the pattern is - for the coarse one the current choice is fairly weak and might be difficult to recognize but for the heavier patterns it might already be too strong. You have to be careful not to influence the overall color impression so much that different areas are no more commonly recognizable as the same base color.

Abstract 'german style' triangle/circle symbols are here in two different sizes:

The small ones probably need a better contrast to be readable.

[Vort]

I think this symbols better than others:
https://camo.githubusercontent.com/e82ede7ebc3f4f154e8e617368c67cac98862918/687474703a2f2f7777772e696d616769636f2e64652f66696c65732f776f6f645f7061747465726e7332612e706e67
Because they are better recognizable as trees.

[kocio-pl]

I strongly support dropping pairs. This was more or less my preferred idea (I just wanted the pairs to be used only for unspecified type of forest), thanks for picking it up!

I prefer complex tree symbols sparse, because they are easiest to recognize and won't clutter the area. I guess even natural=wood, which is commonly used for smaller tree areas, it would be still usable, however field test would be needed.

BTW: I think unification could also include landcover=trees tag, since it's quite popular and we have probably no other neutral way of describing tree areas. Lack of wiki page is easy to fill, I will ask about it on Tagging list.

[dieterdreist]

sent from a phone

Am 02.08.2015 um 13:16 schrieb Mateusz Konieczny [email protected]:

From your examples - note how on and https://upload.wikimedia.org/wikipedia/commons/6/64/Country-side_around_Troitsk%2C_Moscow.png tree symbols are kept from in tersecti ng paths/roads.

these look like actual trees (surveyed), not merely abstract symbolic fills

[pnorman]

I would not worry about leaf type right now, as that's out of scope of this issue.

[imagico]

I would not worry about leaf type right now, as that's out of scope of this issue.

IMO it makes sense to plan ahead and consider the possibilities to show leaf_type and possibly leaf_cycle. As said the idea would be later when leaf_type can be rendered to not render the pattern any more in areas not tagged with leaf_type and until then use the mixed version as temporary pattern.

I did not mean to hijack this PR - if you or anyone else want to further evaluate the tree pair concept of a different generic approach that is fine - i just have my doubts this will lead to good results now and the question remains anyway how this can be extended to differentiate leaf_type.

[matkoniecz]

@imagico

I think that pairs are slightly uglier than individual tree - and it is not a problem. Once hstore will be available this style may represent forests with missing leaf_type, and forests with supplied leaf_type may use a proper and prettier pattern like proposed in #1242 (comment)

[pnorman]

closing in favour of #1728