wetland rendering differentiated by wetland type #1497
Conversation
|
impacts #1242 |
|
2015-04-23 0:34 GMT+02:00 imagico [email protected]:
very nice! |
|
Made some small changes: For consistency and to avoid irritating color changes when zooming the base color of swamp/mangrove is rendered from z=8 like wood/forest. Tidalflat is shown from z=9 which is consistent with the other bare ground tags and seems appropriate since tidal flats are frequently larger areas. |
|
It would be great to include also the source files of the patterns - if feasible e.g. because they are SVG - to allow for easier customisation. |
|
The patterns as a whole do not exist in SVG form, they are assembled using raster processing (i.e. masking the base dash pattern around the symbols). I will however include the symbols used with jsdotpattern and can also make available the point arrangement - here with the mangrove symbol: |
|
Mud labels now also match the wetland labels: |
Yes, that's what I meant. Probably the form of including this in the style has to be discussed, but I always thought that it would be important to offer forks the possibility to change the patterns easily without having to recreate them from scratch (meaning the symbols and arrangement). |
|
We'll need the patterns in SVG too, eventually. Mapnik 2.x can only use raster patterns in patternsymbolizers, but this limitation is removed in mapnik 3.x so we'll prefer SVG patternsymbolizers at that point. |
|
I agree having SVGs for patterns could be useful, especially for rendering the style at different resolutions - however the design of the patterns here currently relies on raster processing and some parts of this (in particular use of hit-and-miss pattern matching - see http://www.imagemagick.org/Usage/morphology/#hmt) cannot easily be translated into vector operations. This means creating matching SVGs will be complicated and this only makes sense to do when a pattern is finalized. @pnorman also mentioned in imagico/jsdotpattern#3 that mapnik 3 has limitations in SVG support that would significantly blow up SVG file sizes for patterns with lots of or complex symbols - the current bare ground patterns for example would each be several megabytes in size as SVGs in mapnik compatible form. Long story short - i think the concept of SVG patterns has still quite a lot of open questions. Re. editability as @nebulon42 hinted the question is for example if and to what extent it makes sense to manually edit pattern SVGs in programs like Inkscape where maintaining the periodicity is not ensured. Another thing - does anyone know if mapnik 3 pre-rasterizes SVG patterns when they are used? If not i'd estimate using them will have a significant negative performance impact. |
imagico
force-pushed
the
wetland-improvements
branch
from
c66e291
to
7e5c540
Compare
|
rebased - from my side this is ready now. |
| @@ -442,6 +444,45 @@ | |||
| } | |||
| } | |||
|
|
|||
| [feature = 'wetland_mud'], | |||
There was a problem hiding this comment.
Should this not be natural_mud?
There was a problem hiding this comment.
No, in https://github.com/imagico/openstreetmap-carto/blob/wetland-improvements/project.yaml#L151 mud and marsh are translated to wetland types so natural=marsh/mud and natural=wetland+wetland=marsh/mud are treated exactly the same. This could of course also be done in the style sheet but this seems more consistent in result, esp. with regard to priorities in COALESCE() - otherwise a polygon tagged natural=marsh + landuse=* would be rendered different to one tagged natural=wetland + wetland=marsh + landuse=*.
There was a problem hiding this comment.
Thanks, I see now.
|
Looks nice! The only thing I'm not happy about it is the transparency. I think indeed that it would give undesired colours when overlapping with other landuse. I also don't think that the transparency over land/water is intuitive. In pictures like this: it is not intuitive to me that the darker parts are actually outside the coastline. I'm also not sure if the coastline is a relevant physical feature on high zoom levels, so I wouldn't mind if it weren't visible. |
Yes, I expected that darker part is a land. |
|
Ok - first the sample image is not actually very good since it is relatively bad mapping there and the boundary also adds to the confusion. But i see that the different color over water is not very clear in case of mangrove which probably has partly to do with the fact that transparency is fairly low and to get the same color as wood over land the color itself has to be very dark.
The point is that by hiding it mappers are discouraged from proper placement - it does not seem to matter since it has no effect on the rendering result. We can already widely see this in case of natural=coastline vs. natural=water. So i would rather render mangrove and tidalflat without a base color than with one that obscures the coastline. Note this is not a high zoom level problem only - both these types of wetland cover quite large areas in some cases and an arbitrary placement of the coastline within such wetlands will have a very bad effect on the coastline quality. I could imagine three measures:
below is an example for 50/60 percent transparency for mangrove (current is 25):
and here using exclusion comp-op: |
|
Found a somewhat better area for mangrove mapping crossing the coastline southeast of Mumbai:
Yes, the difference is fairly subtle - could be emphasized more as shown in the previous comment. But i don't think there is normally confusion which part is inside and which is outside the coastline. |
|
Actually I still don't recognize it as coastline, rather as two different types of vegetation. |
|
Well - in a way it is - one is mangrove forest above the high water line, the other is mangrove forest below it. Some level of obfuscation of the coastline seems appropriate considering mangrove does make it less recognizable in reality. But having it still visible, at least in a subtle way tells the mapper: it still matters, take care about placing it sensibly. Hiding it fully conveys the message: once you mapped the mangroves the coastline is not important any more, just close it somehow as it is convenient. I tried the more transparent colors shown above but the part over water is too dark IMO compared to the rest of the style. Using water polygons instead of land polygons would give some more options of course. |
This is on the to do list |
moving tidalflat base color to a separate symbolizer removing now unused mud from natural in SQL
|
I removed the mangrove base color now since it is generally not found favorable. I also moved the tidalflat/mud base color rendering to a separate symbolizer which i think makes sure it is rendered before the other landcovers without the need for a separate layer. Sample: |
I like the approach without base colour! Especially because your intention is to make clear that it matters where the coastline passes – and the version without base colour makes this clearer. |
|
It is not too bad IMO - but since mangrove would also usually be considered a type of woodland it would make sense to for it to use the base color of natural=wood - especially since at least in the inner tropics mangrove usually transits seamlessly into tropical rainforest under natural conditions. Not using a base color might encourage mappers to map wood/forest in addition but not more than right now and practical mapping of mangrove areas right now is overwhelmingly using natural=wetland without another solid color area tag in addition. When we move to water polygons it would be easily possible to use the wood base color over land and a mixture of wood and water color over water - this would be the best solution i think. |
Yes, that works. However, what about other landcover inside tidalflat/mud? I can think of leisure=track inside landuse=mud, for example. Your approach would not render the track. Currently we order landuse by area size, and this would be inconsistent with that approach. |
|
Other landcovers within tidalflat/mud work fine, here natural=sand within natural=mud (somewhat suboptimal tagging of course but that's not the issue here): Of course a small tidalflat/mud area within a larger other landcover would probably only render with the wetland overlay. |
|
You're right, I read
the wrong way around. |
|
Thanks, looks very good! |
|
Ok, thanks for reviewing and merging. |
|
I'd like to mention again that it would be nice having also source files/symbols included in the style somehow. Especially since most symbols are now going to be SVG it would be great if also patterns could be easily customised. I can open an issue for that though, if that is better suited. |
Yes, please. I agree, but thought it was not worth postponing the merge for this reason. |
|
No, of course not - and yes. :) |
|
Could you please summarise the tagging used for the above illustrations? |
|
Interesting. Looking at those examples, I see that natural=water is used in preference to waterway=riverbank to produce the correct rendering. There is a long-unfixed issue (#115) regarding this. |
|
Tidal flats can expose various surfaces: mud, sand, shingle, etc. Will these cases be rendered with different background colours for different surface=* modifiers? |
|
Currently there is no established tagging for that - wetland=tidalflat is not used significantly in combination with surface=*. Larger flat tidal areas (which is the meaning of tidalflat) also generally feature very small grained material at the surface - hence are usually muddy. Sand/gravel features in tidal areas would often most accurately be tagged natural=shoal - #545 mentions the possibility of rendering this. Another possible improvement is rendering the tidal part of natural=beach different from that above the high water line. This once again would probably require use of water polygons. |
|
Shoal is not the same as tidalflat. Shoals can be permanently underwater, permanently above water or exposed by the tide. I could find no explanation of "water polygons" in the Wiki. What is meant by this term in this context? |
|
This is not the place for discussing tagging - if there are a significant number of areas you consider rightfully tagged natural=wetland + wetland=tidalflat + surface!=mud it might be worth looking into rendering them in a distinct form - i am not sure such areas exist though. Best to discuss this first in local community or on tagging ML. water polygons refers to use of http://openstreetmapdata.com/data/water-polygons rather than (as right now) http://openstreetmapdata.com/data/land-polygons for rendering the ocean/land distinction. This has been in discussion occasionally for a long time. |
resolves #387, #1158
This adds specialized patterns for various types of wetland as indicated by the wetland tag. It also unifies natural=mud with wetland in terms of style - it is rendered like wetland=tidalflat.
As before the wetland pattern is rendered as an overlay. The base color - if it exists - is rendered in the landcover layer. There wetland has priority over landuse so if a wetland polygon has also a landuse tag (which is quite common) the wetland type supersedes the landuse for the base color. Rendering with the basic wetland pattern starts at z=10 as before. The specialized patterns are used at z=14 and above. Also the wetland pattern is less strong than before (fixing #1158)
Here are generic styling examples for all different pattern types as used at high zooms:
bog and swamp:
bog uses the base color from heath, swamp from wood.
saltmarsh and reedbed:
marsh and wet_meadow are rendered the same as saltmarsh, just with the grass color as base color.
tidalflat/mud and mangrove:
As can be seen the last two use a semitransparent base color. This is to make sure the coastline is always clearly visible even if a wetland polygon is drawn across it and transparency is the only way to do this. The colors are designed to match the previous mud color and wood color when used over land. If there is fear this might cause confusing colors when overlapping with other landcovers i can move these to a separate layer rendered before the landcover layer. This would ensure only the coastline layer is below, it would however also complicate the code quite a bit.
Practical rendering examples:
z=13:
z=14:
Showing how the overlay renders above water areas:
I did not touch the labels - they are still rendered in strong blue for all types of wetland. This seems fine to me but can be changed of course.
Mangrove rendering showing which areas are inside and outside the coastline:
