Default graticule settings

[edzer]

While working on st_graticule, I find it hard to come with good defaults for graticules. This example

library(sf)
library(maps)
usa = st_as_sf(map('usa', plot = FALSE, fill = TRUE))
laea = st_crs("+proj=laea +lat_0=30 +lon_0=-95") # Lambert equal area
usa <- st_transform(usa, laea)
plot(usa, graticule = st_crs(4326), axes = TRUE)

gives

while specifying graticule longitudes, by

plot(usa, graticule = st_crs(4326), axes = TRUE, lon = seq(-60,-130,by=-10))

gives the nicer

The algorithm for defaults now does this:

1. segmentize the bounding box of the plotting region
2. convert this to longlat, and compute the bounding box of this
3. apply base::pretty to find the pretty values on this bounding box
4. compute the graticules
5. transform back and clip with bounding box

Does anyone know of a generic approach, or algorithm, or software that does this well, automatically? Should we for instance always choose a default interval size and then apply this to both long and lat? @mdsumner does your graticule package solve this?

[edzer]

adding @rsbivand, @tim-salabim and @hadley to this.

[tim-salabim]

pretty has arguments n and min.n. Maybe those can help?

[edzer]

That implies you'd treat x and y (or long and lat) independently. Wouldn't it be better to use some heuristics to pick an interval (10 degrees in the second graph above), and apply that to both long and lat?

[rsbivand]

These are excepts from cartographic authorities:

0, 1, 2, 3, 4.

They themselves only use graticules sparingly, mostly when discussing projections. The quotes largely advise against graticules in thematic cartography, unless either the North direction really matters to interpretation, or the distortion induced by projection affects visual interpretation. They pre-date Tufte, but seem to see ink used on graticules in thematic/statistical mapping as wasted. The books are Slocum et al., Hodgkiss, Robinson and Monkhouse & Wilkinson.

[rsbivand]

So pretty() is OK, but the help page should indicate that use is mostly for showing the distorting effect of projections (say like the misleading relative sizes of land areas in Mercator viewed globally); otherwise remind of information to ink ratio.

[mdsumner]

I don't believe it's 100% automatable, my best example of that is Oblique Mercator, perfect for Short-tailed shearwater migrations from Antarctica to the Aleutians, which was best done in two hemispheric passes to specify the right sets of longitudes, interactively. I will illustrate this and compare various methods.

The best auto algorithm I've seen is to contour() a discretized version of the projected extent with longitude (and then latitude) values in the pixels, it's nigh on perfect but needs special handling for a way to wrap on seams like 180 longitude and heuristics to pick the right grain. I have experiments with this in graticule trunk.

D3 has the ultimate machinery for automating it, but you need implicit geoidal curves stored in arc-node form, and it's something on my list to do.

We are better than Manifold already, but they do give almost complete control over the result which is very helpful.

Personally I just hope we allow overriding any defaults, and encourage the same with ggplot2. I think this is a general facility that should exist independently of sf, or at least be generatable as data, so any plot auto result could be reproduced as a data set and used elsewhere (I think that's already true?).

There is a problem somewhere with ggplot2 using sf when segmentization results in out of bounds coords that I can't pin down, will post example soon. Finally I have a lot more to say but things have been developing so fast I keep learning more and it's going to take a while to process it all!

Cheers, Mike

[barryrowlingson]

To save anyone else wondering, QGIS doesn't have an automatic algorithm for graticule spacing (or at least I couldn't find one in the base or plugins).

[mdsumner]

Here's the raster-contour "finite-element-kinda" approach. It handles omerc well, but shows up the issue with the field-switch from -180 to 180. I think that's easy to handle with fakey-polar transformations, but the crux for me is wanting flexibility over what is going on. That method won't work well with all projections, just as other methods won't always work in ways that are hard to specify in general.

http://rpubs.com/cyclemumner/244742

(I couldn't find the shearwater plot with the two-pass method).

An issue with sf/ggplot2 that I haven't had time to root out is this

library(sf)  ## c89f1d88
library(ggplot2) 

library(ggplot2)
library(maptools)
library(sf)

data(wrld_simpl)

m <- st_transform(st_as_sf(wrld_simpl), 
                  "+proj=laea +y_0=0 +lon_0=155 +lat_0=-90 +ellps=WGS84 +no_defs")

ggplot(m[1:2, ]) + geom_sf(aes(geometry = geometry)) 
#Error in seq.default(bb[2], bb[4], length.out = ndiscr) : 
 # 'from' cannot be NA, NaN or infinite In addition: Warning messages:
#1: In min(lat) : no non-missing arguments to min; returning Inf
#2: In max(lat) : no non-missing arguments to max; returning -Inf

## individually it's no problem
ggplot(m[1, ]) + geom_sf(aes(geometry = geometry)) 

ggplot(m[2, ]) + geom_sf(aes(geometry = geometry)) 

You could say that we're stretching the limits of what wrld_simpl can do, and I agree but automatically detecting when a user is going out on a limb will be very hard too. I think it's really important that we decide collectively what's best for overall flexibility and ease of use across sf and ggplot2 (at least).

[mdsumner]

@rsbivand I agree with this to the extent that if working with graticules and projections is not your primary interest, then they might be a distraction. R is really good for working with and building graticules, for dealing with spatial data generally as infrastructure for a huge range of tasks, and for some that is primary. There seems to be an assumption that R and its spatial tools are only for a certain class of statistical modelling work, but for me it's probably accurate to say that those are pretty unimportant to my work, at least for what I do directly. Creating graticules and working with them started as a general interest, but it's now a pervasive set of ideas and workflows that impacts a lot of the work I do. I think it's just so hard to work with them, generally, that the value in their use doesn't ever get discussed, in an unfortunate but pretty common self-reinforcing cycle.

[hadley]

@rsbivand I think you have to be careful to borrow too much from Tufte. There's also good evidence from Cleveland that adding grid lines considerably improves performance when comparing across plots.

@mdsumner note we're just discussing how to determine good defaults. Users will still always be able to override.

[edzer]

In think that there's a difference in the degree of distraction between drawing graticules in black ink on top of everything in a black-and-white graph, and drawing them as white lines on a grey background only in the area not covered by the geometry displayed.

Given that ggplot2 draws white grid lines on the grey background by default, should these for the case of projected maps by default be straight grid lines in the projected coordinates systems, or rather curved graticules of constant long/lat? I think I'd vote for the graticules. Projected coordinate values along axes are not easy to read, or of much use, typically.

[hadley]

@edzer I think graticules are more useful and more consistent with other coordinate systems (i.e. polar coordinates has polar gridlines)

[mdsumner]

@edzer GMT and GPlates have good algorithms

https://tectonicwaters.wordpress.com/2013/06/28/graticules-for-plate-tectonic-reconstructions/

The oce package also has an independent implementation.

[mdsumner]

There is a need use for both grid and graticule and often together so keeping flexibility is key (and reassuring thanks @hadley!).

[edzer]

IIRC, Cleveland's arguments in favor of gridlines were made for the situation where you don't have coastlines, administrative boundaries etc. as alternative means for reference.

+1 for flexibility.

[rsbivand]

Further, the remarks apply to conditioned graphics, say with male/female responses displayed side-by-side, so the grid relates to data legibility rather than location in space. So Cleveland's argument might apply for conditioned displays of spatial data if there are no spatial contextual location elements, like recognizable boundaries, coastlines, etc.

[hadley]

Agreed. My point is that need to take Tufte's remarks with a grain of salt — they are mostly made from an aesthetic standpoint, there's little empirical research to back them up, and he tends to err too far in the direction of removing useful context.

In most spatial context, you will have geographic data to serve as a common reference so graticules are clearly less important. The only example I could think of where they would be particularly important is plate tectonics.

We have drifted fairly far from the original problem, but it seems like there's no simple solution that is obviously better than the current default, and doesn't seem like a problem that is that important to solve, so maybe we should just close this issue?