Extending tmap: package management (how?)

[mtennekes]

The biggest change in upcoming version 4.0 will be the possibility to extend. The question is how to manage extension packages.

There will be three dimensions in which extensions will be possible:

1. Map layers. The basic map layers such as tm_polygons, tm_symbols, tm_lines, tm_raster will be included in the base tmap package (or in a different package that is imported by tmap). However, there will (probably) be new layers functions such as tm_cartogram, tm_hex, and tm_hillshade. Each layer function will have two defined sets of aesthetics: a transformation set and a visual mapping set. The former controls how spatial features are transformed (example 1: polygons wlll be distorted in tm_cartogram; example 2: spatial objects (of any type) will we converted to spatial points (centroids) in tm_symbols). The latter controls the visual variables such as color, symbol size, and line width. Under the hood there will be generic transformation and mapping functions, such as tmapTransCartogram, tmapTransCentroid, tmapMappingColorDiscrete, tmapMapping2dSize, and , tmapMappingWidth. When implementing a new map layer, these functions need to be implemented as well.

2. Graphics engines. Currently, tmap has two (what I call) graphics engines: grid graphics and leaflet (aka plot and view mode). It will be possible to add other graphics engines. I don't know yet which, but I can imagine there are other JavaScript libraries out there that are useful for visualizing spatial data. For each graphics engine, the required are: how to make small multiples, how to draw polygons, points, lines and rasters, how to draw legend boxes, etc.

3. Spatial classes. Currently, tmap has native methods for plotting sf and stars objects. However, it will be easier to write native methods for other class packages as well, most obviously terra.

So it is some sort of "extension-cube". Note that most extensions will be in dimension 1.

How shall we package these extensions? For the first two dimensions, I can imagine a set of packages.

1. tmapBaseLayers (containing tm_polygons etc., and imported by tmap), tmapCartogram, tmapHex, and tmapHillShade (just to name a few, there can be many more).
2. tmapGrid (imported by tmap as default engine), tmapLeaflet, tmapd3, etc.

It is probably easier to keep the third dimension in tmap itself, since spatial class packages are not developed every day.

Can the two sets of packages exist next to each other? Note that they are related: e.g. if someone writes tmapHex, the "engine" packages may need to be updated as well. Not necessarily for plotting the hexagons themselves (since they are probably transformed to polygons), but for the legends.

[Nowosad]

Hi @mtennekes - great work.

My overall thoughts:

1. It seems that keeping spatial classes' preparation inside of tmap is the best choice. With some documentation in this regard, adding new classes with a pull request would be possible.
2. I am not sure if engines should be stored as separate packages or internally in tmap...
3. I think it would be best to have the map layers packages as independent from the engines as possible.

[mtennekes]

Yes, I agree to keep the spatial classes methods inside tmap.

About the engines I am also not entirely sure. If they are also kept in tmap, it creates unnecessary dependencies for these added engines. For instance, we could have a ggplot2 engine which plots tmap user code as a ggplot2 plot. It would be better to have that in a separate package.

I think it is possible to have the map layer packages separate from the engines, because there are not many "elementary" spatial object types. E.g. a cartogram (map layer package) uses polygons (for which the plotting method are included in the engines).

[higgi13425]

Would vote for AGG from {ragg} as a graphics engine option. Quite fast, handles fonts well.

[Nowosad]

@higgi13425 Additional graphic devices including {ragg} are now possible in tmap - https://github.com/mtennekes/tmap/issues/585