Use a random symbology for forests v1.1 #1728
Conversation
This adds a random symbology for forests, lightens forests, and unifies natural=wood and landuse=forest rendering. Using http://www.imagico.de/map/jsdotpattern.php a random pattern was generated from the SVG <path d="m 3.5,0 -3.5,3.5 0,0.5 0.5,0 2.5,-2.5 0,2 -3,3 0,0.5 0.5,0 2.5,-2.5 0,5.5 1,0 0,-5.5 2.5,2.5 0.5,0 0,-0.5 -3,-3 0,-2 2.5,2.5 0.5,0 0,-0.5 z" fill="rgb(58,135,39)"/> <path d="m 10.5,0 a 2.5,3 0 0,1 0,6 l 0,-1 a 1.5,2 0 0,0 0,-4 a 1.5,2 0 0,0 0,4 l 0,1 a 2.5,3 0 0,1 0,-6 z" fill="rgb(58,135,39)"/> This was then converted with GIMP into a PNG which Mapnik can use. The forest fill was lightened, but there are now darker symbols on. This necessitated adjusting the text colour for forests, which was done in Lch colour space. The frequent symbols also required some halo adjustments. There are multiple interpretations in use of landuse=forest vs. natural=wood. Rather than attempt to sort this out when the tagging has not settled, the same appearance is used for both. This commit doesn't use different symbologies for different types of forests (mixed/coniferous/broad_leaved/palm) (#822), but that can be considered later. Fixes #938 Fixes #1724 and #647 Fixes forest part of #937 Closes pnorman#6 Closes #1242 Fixes #1309 and #888 Move grassland colour to grass There are just too many shades of green, and it couldn't be reliably differentiated from all the others before grassland is also merged in with grass. It wasn't distinguishable before, and there were just too many shades of green. Code written by Paul Norman, rebased by Mateusz Konieczny. Please assume that bugs (if any) were caused by mistakes during rebasing.
|
i like this pattern more but this one is ok for me too |
|
The wood/forest background and pattern color are fine but apart from that i have the following critiques/remarks:
|
I agree that this pattern are prettier - and I would like to use them for showing leaf_type (this from PR - without leaf_type, singular mixed symbol - leaf_type=mixed, singular symbol for leaf_type=broadleaved/needleleaved, something else for leaf_type=leafless).
Ops, it seems that I lost parameters. Anyway, it was something like http://www.imagico.de/map/jsdotpattern.php#x,512,jdp54442;g,30,32,32;rx,25,2,32,32;rx,25,2,32,32;s,jdp65794;s,jdp70741;rx,25,2,32,32;
Thanks, I opened matkoniecz/CartoCSSHelper#17 to remember about it (I would prefer to figure way to do it via rmagick)
OK, I will test it. I forgot about this change and that greens need to be retested. |
As said i see no reason not to use a mixed symbol pattern universally for now and change to using it only for leaf_type=mixed later. OTOH changing the pattern now to something suboptimal and then inevitably changing it again when leaf_type is rendered seems pointless. For the pattern try |
|
In general - another big +1! I also like the way we care for additional extension, like suggesting leaf types etc. And special big thanks for @pnorman for starting to fix this very complex subject. |
My idea it to not change it once leaf_type is available and keep using it for forests where leaf_type is missing. |
Something went wrong. I am getting file with trees clustered on borders. Can you maybe produce and share generated svg (with trees in Lch(70,30,135) colour)?
The new scrub is a problem. I think that I will keep it unchanged - and it may be synchronized later (reverting scrub change is not making color distances problematic - it increases also distance from forest and it is not getting to close to other greens). I tried to rebalance it again, without good results. |
|
For the pattern generator make sure you use the version on imagico.de and you reload all source files - i had changed some code fixing a bug that prevented you from changing the radius after generating the pattern. This is not yet on github.
Even if for illustrating leaf_type the same symbols are used this does not appear to be the best solution to me. Using no pattern for no leaf_type seems the most intuitive approach. |
No, that's not intuitive. We have far too many "plain greenish fill" polygons to be able to tell which is a forest/wood unless there are symbols. |
Thanks, now it is working! |
|
I think now forest, scrub, orchard are different enough. |
I meant intuitive in the way it clearly indicates something is missing in contrast to areas with leaf_type tagged that are rendered with a pattern. OTOH if a paired symbol pattern is used in some areas and single symbol patterns in others this is less obvious, especially if the same pattern was used indiscriminately for all forest/wood areas before. |
I don't think that leaf_type is so important that we should give users of the map the impression something 'is missing' when forests are tagged without leaf_type. |
|
It was my understanding that the display of paired symbols is meant to create an even stronger indication of something being wrong than the lack of a pattern. If there is another reason for choosing symbol pairs over mixed individual symbols please explain. |
|
I've just noticed that leaf_type has 796 665 uses, while natural=wood has 3 044 417 uses and landuse=forest has 2 704 306 uses, so - roughly estimating - only 14% of popular wood tags has leaf_type assigned. While I think idea of plain green for unknown tree areas is a clever way of encouraging people to be more specific, this would be rather demanding. Some less interesting pattern will be also valuable feedback, while not making rendering of about 86% of tree areas worse (less obvious). |
I think that pair at the same time indicates that it is forest and will subtly encourages to add leaf_type once leaf_type will result in appearance of other patterns. Lack of pattern for missing leaf_type would also encourage adding missing data but would fail in marking area as forest.
It is even worse as leaf_type is applied also to natural=tree etc. See http://taginfo.openstreetmap.org/tags/landuse=forest#combinations http://taginfo.openstreetmap.org/tags/natural=wood#combinations - both lower than 7%. |
I have my doubts this is going to be the case, especially for map users who got used to this being the normal forest/wood pattern used everywhere. But you could be right, i can't be sure. By the way the limited prevalence of leaf_type is partly due to the fact that this tag has not been around for long - there are probably still more maps rendering wood=* than there are rendering leaf_type. There are still >350k uses of wood=* without a leaf_type tag. But of course whatever styling is used for wood/forest without leaf_type will for quite some time surely be the dominating styling - especially of course in areas where forest data has been imported. |
Pattern may generated by visiting http://www.imagico.de/map/jsdotpattern.php#x,512,jdp6894;g,30,32,32;s,jdp33742;s,jdp81637;rx,250,2,32,32;s,jdp28824;s,jdp59702;s,jdp91550;s,jdp27774;rx,250,2,64,64;rd,1,0,0,tree%20pair,1,5,5,0,jdp48960; and replacing svg patterns in boxes by <g><path fill="rgb(107,141,94)" d="M 2,0 0,6 0,7 2,7 2,10 3,10 3,7 5,7 5,6 3,0 z M 2.5,1 4,6 1,6 z" /><path fill="rgb(107,141,94)" d="m 7,5 1,0 0,5 -1,0 z" /><path fill="rgb(107,141,94)" d="m 7.5,0 a 2.5,3 0 0 1 0,6 l 0,-1 a 1.5,2 0 0 0 0,-4 1.5,2 0 1 0 0,4 l 0,1 a 2.5,3 0 1 1 0,-6 z" /></g> <g><path fill="rgb(107,141,94)" d="m 2,5 1,0 0,5 -1,0 z" /><path fill="rgb(107,141,94)" d="m 2.5,0 a 2.5,3 0 0 1 0,6 l 0,-1 a 1.5,2 0 0 0 0,-4 1.5,2 0 1 0 0,4 l 0,1 a 2.5,3 0 1 1 0,-6 z" /><path fill="rgb(107,141,94)" d="M 7,0 5,6 5,7 7,7 7,10 8,10 8,7 10,7 10,6 8,0 z M 7.5,1 9,6 6,6 z" /></g> to obtain color lch(55, 30, 135) Generate file in "px aligned" mode.
Orchard/vineyard colors were modified since initial code was written, and new scrub was too close
there are also 225.000+ occurences of the (for non-relations deprecated) "type" key with leaf type values. |
That's why I preferred it. I looked hard for a single symbol that indicated a generic tree without anything about what type of tree, but could not find one. Quoting myself from before,
|
Use a random symbology for forests v1.1
|
It seems to me, the ordering of layers is not optimal. Now the forest is above lakes, which are not excluded by a multipolygon. |
|
According to current tagging of this area it is both lake and covered by forest (what may happen in some cases like mangroves - https://en.wikipedia.org/wiki/Mangrove#/media/File:Hunting_For_Worms.JPG ). In cases where it is not a forested area it should be an inner part of forest multypolygon. There are also situations where forested area and locality named "Forest Foobar" are not equivalent (lake that is not part of forested area but is part of locality) but there is no established tagging for this situations. |
|
Does this new development include landcover=trees? I need to see it on the map to verify, but ATM the symbols appear a bit intrusive & the problem noted by @HostedDinner needs to be sorted. |
I don't think that leaf_type is important enough to render it at all. Those who introduced a random symbology may be rightfully proud of it, but it should not be used for forests/woods. Just render them plain green without any symbols. |
|
Leaf type is one of the most important property of forest/woodland and it's easy to implement without disturbing anyone, so I'd like to have it in this style. |
This is not true. I feel disturbed, and I am sure that many others feel the same. Most official maps (such as http://www.amap.at) and commercial maps (such as http://maps.kompass.at) render forests plain green, and that's one of the reasons why they look considerably better than the OSM carto map. |
|
You misunderstood me: I just meant implementing leaf types rendering will not make it any more disturbing than it is now (which BTW are less intrusive than what we had before). For me plain green would hide too much, I prefer subtle hint and this is what we have now. |
|
Fortunately there is no need to decide if this is important from an absolute standpoint, >300k uses quite clearly tells mappers consider it important and since displaying leaf_type is well possible to do in a relatively subtle way it is likely this will happen as soon as it is technically feasible here. If there are specific issues with the new woodland rendering i would suggest to open a new issue but i would strongly suggest first reading the previous discussion on #1242 as to not repeat arguments from there unnecessarily. |
See #822 for discussion of this topic. |
|
@matkoniecz Historically wood=deciduous and wood=coniferous were rendered in the standard style (which is why this tag persists in the style sheet). Leaf_type is largely a semantically cleaner form of this distinction. In many parts of the world, largely those in temperate and boreo-temperate climatic zones, this distinction is an important aspect of interpreting the landscape from a map. Equally leaf_cycle also plays a part, but we have no history of rendering this distinction because wood=deciduous was treated (erroneously) as a synonym for broad-leaved woodland. As others have stated above, the various tags used to describe this are very heavily used: wood, 400k instances, leaf_type, 300k instances, type, 200k instances (I exclude leaf_type on nodes, and of course these usages are not additive). I take this to mean that there is considerable interest in collecting and displaying this type of information. Woodland covers about 23% of the world's land area: there are good cartographic reasons why a slightly finer division of types of woodland is worthwhile. More detailed division is clearly something for more specialised projects, but I don't think it is reasonable to dismiss out-of-hand leaf_type and leaf_cycle. This is particularly true now that the hard work of determining suitable ways to add symbols for woodland is nearing fruition. |
Maybe, but it's botanically unfounded, at least when it comes to whole woods or forests. E.g. in central Europe, you encounter broad leaved plants from sea level up to the alpine zones in all natural plant communities. Even in spruce forests, you'll see one or the other naturally grown young beech. And reversely, you'll hardly find any forest without any Pinacaea, because so many of them are planted or spared. So there's essentially no needle_leaved or broad_leaved forest. You could rather tag the percentage at best, like needleleaved=70%. I suspect that most wood=* come from imports, and also that most wood=* and leave_type=* on areas are incorrect.
This is wrong, because the foliage is only visible from a distance of a few metres.
How about different shades of green? We could recycle the one we used for natural=forest. The fact that woodland covers big parts of the world suggests NOT to use any symbols. Symbols should only be used for areas that are rare and therefore not obvious to the viewer. Just compare woodland to water, residential areas etc. Imagine what would happen if all water areas were ornamented with wave symbols, and all residential areas with house symbols, etc. You would not recognize any streets, POIs, nothing. You would be overwhelmed by the ornaments. That's what we experience within woodlands now. @imagico: |
This is #1242 - rebased and with subtler pattern.
Hopefully I caught all bug introduced by rebasing.
I am considering splitting landcover-area-symbols into two layers, as SQL is quite ugly.
Forest with high path density:
https://cloud.githubusercontent.com/assets/899988/9140119/05e767d0-3d2f-11e5-94af-97258b955869.png
Other examples from #1242:
https://cloud.githubusercontent.com/assets/899988/9140108/fba4c524-3d2e-11e5-87c8-4f471b250074.png
https://cloud.githubusercontent.com/assets/899988/9140109/fba558a4-3d2e-11e5-9232-561593c5ff8f.png
https://cloud.githubusercontent.com/assets/899988/9140110/fba7bd7e-3d2e-11e5-8448-a68f8e70f1a6.png
https://cloud.githubusercontent.com/assets/899988/9140107/fba2a6e0-3d2e-11e5-9c82-95cb15932ee9.png
Fixes #1724