Dot map density

[ebocher]

Existing conformance classes required for this use case:

• Dashes, Stipples, Hatches and Gradients
• (conformance class for more specific stippling)

Example stylesheet:

Bellow a CSS encoding to describe a dot map. A do map is used to create a visual impression of density by placing a dot or some other symbol in the approximate location of one or more instances of the variable being mapped. The mapped variable is the area of the LCZ geometry. The dot map can be colored according the LCZ types. a.e : LCZ equals to 1, 2 , 3 filled in red to represent a high climate aleas.

Describe any capability not already addressed by existing conformance classes:

DotFill must be defined with the following properties

• quantityPerMark : the quantity represented by a single dot.
• totalQuantity : the total quantity to be represented.
• mode : the algorithm to distribute the mark random, grid...
• a mark or a set of marks

Example image illustrating the portrayal use case:

[IvanSanchez]

I would like a couple of clarifications:

• Is the density dependent on the zoom (or scale factor) of the map? Is density "points per pixel" or "points per CRS unit squared"?
• It's possible to do a renderer implementation of this by applying dithering algorithms, but such an implementation would jiggle the dots around any time the map viewport changes (the map moves or is zoomed). Is such a renderer an accepted implementation?
• Can two points be drawn in the same screen pixel?
• Can points be more than one screen device pixel? Than one CSS pixel? What's the behaviour for hi-DPI screens?

[IvanSanchez]

I created an implementation of this use case as a random dithering filter, in https://gitlab.com/IvanSanchez/gleo/-/commit/134b477781ffc4b62d7d5937a633d48ad2455c88 .

The way this works is by decorating a symbol - there's a base Fill symbol and a ditherify decorator (an implementation of a random-noise dithering filter). By combining the two, a DitherFill symbol class is defined during runtime. But this filter can be applied to any other symbol class, such as Sprites (which creates something we can call DitherSprite):

I'm interested/concerned/curious about how this approach might impact the definition. My approach is to have a dither option/property/attribute (in the constructor/instance/webgl buffer, respectively) from 0 to 1, which represents the density. There's the question of how to make the density depend on the scale factor (or "zoom level") to provide the illusion

---

On the technical side, it's also possible to approach a "dot density" symbol by actually spawning individual points (and leveraging the GL_POINTS draw mode on the technical side). My further musings are at https://gitlab.com/IvanSanchez/gleo/-/issues/86

[ebocher]

• Is the density dependent on the zoom (or scale factor) of the map? Is density "points per pixel" or "points per CRS unit squared"?

The number of points is a fixed value. The number of points to be displayed does not depend on the zoom level but on the amount of data to be displayed in the polygon.

• It's possible to do a renderer implementation of this by applying dithering algorithms, but such an implementation would jiggle the dots around any time the map viewport changes (the map moves or is zoomed). Is such a renderer an accepted implementation? If the algorithm respects the number of points to be displayed for a polygon I don't see any constraints.

• Can two points be drawn in the same screen pixel?

Please specify

• Can points be more than one screen device pixel? Than one CSS pixel? What's the behaviour for hi-DPI screens?

The size of the points can be specified in UOM (Unit of Measure) therefore -> Can points be more than one screen device pixel? : yes

[ebocher]

There's the question of how to make the density depend on the scale factor (or "zoom level") to provide the illusion

This is a complex subject. Some ideas here https://www.mdpi.com/2076-0760/8/5/157

By the way, thank you for your comments