Randomized symbology for forests

[pnorman]

See towards the end of http://sk53-osm.blogspot.com/2014/09/woodland-cartography.html by @sk53 as a reference. We may want to consider this for other features, but forests are a good start.

There are a few ways to do this

Use a large texture

See https://github.com/gravitystorm/openstreetmap-carto/issues/937#issuecomment-55294102 and @imagico's example of

There is no particular reason why the texture must be 256x256. The constraint is that any sub-square in the top-left of a potential metatile size forms a valid repeating pattern (i.e. the edges align). In production we use a 2048x2048 metatile, which is certainly big enough to appear random, as not all of it will appear on most screens at once.

Advantages

• Minimal style changes
• No SQL changes

Disadvantages

• Detectable repetitions for small meta-tile sizes.
• Image needs to be designed carefully so any sub-square in a MT size meets tiling criteria

  Generate point locations in SQL

We could plot tree icons on top of a solid green fill by generating points in SQL.

It is possible to generate a grid in SQL, and then offset each point based on some criteria that isn't visually obvious (e.g. md5 of location)

The SQL to generate a 16 pixel grid is approximately

SELECT 
    ST_SetSRID(
      ST_Point(x+floor(st_xmin(!bbox!)/(!pixel_width!*16))*!pixel_width!*16,
      ST_Point(y+floor(st_ymin(!bbox!)/(!pixel_height!*16))*!pixel_height!*16),900913) 
  FROM 
    generate_series(0,ceil((st_xmax(!bbox!)-st_xmin(!bbox!))/!pixel_width!,16) AS hor(x), 
    generate_series(0,ceil((st_ymax(!bbox!)-st_ymin(!bbox!))/!pixel_height!,16)  AS ver(y);

Advantages

• Never repeats
• With ST_Buffer(way, -sqrt(!pixel_width!*!pixel_height!)*N) AS way you can avoid placing an icon where it gets cut off at an edge

Disadvantages

• Adds another layer
• More complicated SQL

Mixed

• Different styling. The trees will essentially be overlays

[imagico]

My example by the way is not a randomly displaced grid pattern and neither a Low-discrepancy sequence - the two simplest and quickest approaches to this. It is based on relaxing a randomly displaced grid pattern to maximize distances between symbol locations with periodic boundary conditions. As a result the pattern is perfectly periodic, i.e. should be invariant in any statistical properties against arbitrary translations. On the negative side this is not suited for real time calculation of course. You could however also use a precalculated pattern to place individual symbols and avoiding symbols being cut off.

It should however be mentioned that leaving out symbols from an otherwise unmodified pattern at the edge is not the ideal approach either since by leaving out symbols the overall symbol density is reduced near the edge while ideally it should be the same or even slightly higher. It is questionable if this approach improves readability in comparison to a version with cut off symbols. A strongly 'branched' polygon with a very long outline compared to its area for example will frequently not get any symbol while a round or rectangular one of similar size will - and the viewer than can easily get the impression both represent different types of areas due to the different appearance in the map.

The visibility of repetitions in a precalculated periodic pattern is mostly a matter of how large the polygons are in comparison to the pattern size used. In principle it is also possible to create a pattern that is periodic on several different subsets (like the top left 256x256 crop as well as the full 2048x2048 pattern) without the large area being a repetition of the smaller subset.

[pnorman]

In principle it is also possible to create a pattern that is periodic on several different subsets (like the top left 256x256 crop as well as the full 2048x2048 pattern) without the large area being a repetition of the smaller subset

How would we do that? I just need the points, not a final file, since with the points I can generate a SVG easily enough.

[matkoniecz]

I am no sure how this change is improving anything. Also, it may be harder than it is now to deduce that placement of the tree symbols is meaningless - it only specifies area type.

[pnorman]

There's a great deal of precedent for randomized symbology. SK's blog post outlines them fairly well.

[Rovastar]

I think this will cause more confusion and will not really improve anything. surely the precedent is for ancient hand drawn maps where they had to have more info. Modern maps have no precedent. Therefore the modern precedent is for no trees symbols at all, which frankly is the route we should take.

[dieterdreist]

I like the proposed "ordered chaos" for the tree symbology. No symbols at all would be a step back, we already have tons of different greens, hard to distinguish and guess the meaning of them.

[imagico]

@Rovastar - to forgo the use of patterns in area rendering in general does not seem feasible in the OSM style. The argument ancient vs. modern is not really convincing - map styling in general always builds heavily on traditions. What's right of course is that for maps targeted at screen use, i.e. low resolution output with good color representation, use of colors instead of patterns in general is a good idea but we are already at the end of the line with use of color to differentiate surface types and patterns are the logical solution here. The current use of these possibilities in the style are very basic of course - you could even say crude.

Even if this issue is targeted at trees i would not too much concentrate on this - in case of forests/woods the use of symbols would primarily serve differentiating different types of woodland which currently is not done - without such differentiation there is indeed very little use in a symbol pattern for forests. In case of wetland there have been frequent requests to differentiate wetland types in rendering - likewise for various sorts of bare ground. This would all hardly be possible with uniform coloring.

[dieterdreist]

2014-09-12 14:44 GMT+02:00 imagico notifications@github.com:

i.e. low resolution output with good color representation, use of colors instead of patterns in general is a good idea but we are already at the end of the line with use of color

this, and display technology is progressing quickly, with recent devices you typically get fullHD on small areas such as a smartphone screen, which is comparable to (laser printer) print quality. In a few years even low end devices will have these "hi-res" screens...

[Rovastar]

Requests for features do not in any way mean we should render them. consolidation of the 'greens' is what is needed. Not more different types and green on green patterns.

[gravitystorm]

It is based on relaxing a randomly displaced grid pattern to maximize distances between symbol locations with periodic boundary conditions.

@imagico Do you have a guide to generating such an image? I like it, and I'd like to experiment with the approach.

fwiw, I think 256x256 pixel patterns will be sufficient for our needs but I'd like to try a few to see.

[imagico]

All right - i brought the tool used into shape a bit - you can find it online as well as the code. Documentation? - not really, but should be easy enough to figure out. I put in a few examples for symbols to use - here a few patterns generated with those:

I also implemented the multiple periodicity version which however is not included in the above since it is somewhat more delicate to use. You can find a tree pattern with 256 pixel and 2048 pixel periodicity on

http://www.imagico.de/files/forest_2048.svg

so you can get an idea.

[daganzdaanda]

After reading @sk53 's blog and watching his talk, I like this proposal. Maybe he could add some feedback? About the edges, I wouldn't mind if the symbols get cut off. It's better than leaving one out if it doesn't fit completely.

One addition for the future would be to have more information in the pattern. Different patterns for different leaf_type or other tags. Sometimes I feel a tag for density of a forest would be helpful (can you walk through?)

[SK53]

@daganzdaanda I love what imagico has done: way more sophisticated than anything in my imaginings. It's great to apparently prompt such ideas: but the original thought was put in my head by Steve Chilton, the original maintainer of the Mapnik style some 3-4 years ago.

I didnt include much on leaf-type based renderings, but have done some experimentation, and of course density dependent ones follow on from that, but we (as yet) have no tagging for it. Beyond the basic pseudo-randomisation I would see most other ideas as applying not to the standard style, but to special-purpose renderings, mainly for environmental purposes, but orienteering is another obvious use-case (with a well established cartographic representation.