Make label formatting in st_graticule() configurable?

[clauswilke]

It would be nice if the degree_label() that st_graticule() generates could be configured in some way. In ggplot2, this problem is usually solved via formatting functions. Would it be possible to add arguments for longitude and latitude label formatting functions to st_graticule(), so that users can provide their own that may behave somewhat differently from the default?

For a very simple use case, consider the following example, where some labels are presented as integer values and others as fractions. I don't think there is currently a way to prevent this.

library(sf)
#> Linking to GEOS 3.6.1, GDAL 2.1.3, proj.4 4.9.3
library(ggplot2) 

nc = st_read(system.file("gpkg/nc.gpkg", package="sf"))
#> Reading layer `nc.gpkg' from data source `/Library/Frameworks/R.framework/Versions/3.5/Resources/library/sf/gpkg/nc.gpkg' using driver `GPKG'
#> Simple feature collection with 100 features and 14 fields
#> geometry type:  MULTIPOLYGON
#> dimension:      XY
#> bbox:           xmin: -84.32385 ymin: 33.88199 xmax: -75.45698 ymax: 36.58965
#> epsg (SRID):    4267
#> proj4string:    +proj=longlat +datum=NAD27 +no_defs
ggplot() + 
  geom_sf(aes(fill = AREA), data=nc) + coord_sf(crs = 2264)

Created on 2018-08-23 by the reprex package (v0.2.0).

[edzer]

st_graticule has options where the graticule lines (and labels) are placed. I forgot whether geom_sf() / coord_sf() interfaces this, but that shouldn't be hard.

For the example above, at latitude 36.5 which label would you have preferred over the current 36.5?

[clauswilke]

Yes, the placement can be configured, but the formatting can't. In the above example, I might want to have 36.0 instead of 36 so it aligns with 36.5. I might also want to be able to create labels that say -84E instead of 84W, or lowercase "w" instead of "W", or whatever else somebody might come up with.

Currently you use the internal functions degreeLabelsNS() and degreeLabelsEW() to format labels, but you don't allow me to supply alternatives to these functions.

[clauswilke]

Also, when looking at this code:

sf/R/graticule.R

Lines 154 to 157 in d2634d1

	df$degree_label = if (is.na(crs) || !isTRUE(st_is_longlat(datum)))
	c(format(lon), format(lat))
	else
	c(degreeLabelsEW(lon), degreeLabelsNS(lat))

I'm wondering whether it would make sense to encapsulate this entire unit into a function that takes as arguments lon, lat, crs, and datum, and users could then supply an alternative to that function.

[edzer]

This gets you the 36.0 by default, which is indeed better.

About exposing a degree_labels function: is this something you need now, or is this something about which you speculate there might be users some day who would enjoy having this (I haven't heard such a request over the past 15 years)?

[edzer]

Ah, I now see option 3: is this needed to get geom_sf() work better with the rest of the ggplot API?

[clauswilke]

Thanks!

It's mostly option 3: Tick labels are configurable all over ggplot2 except for geom_sf(), where the formatting is hardcoded. I know eventually somebody will need to be able to change something. And also, for cases such as 36 vs. 36.0, there is generally no single option that is always best. Sometimes showing the first decimal is good, sometimes it may be better not to show any decimals, and sometimes you may need to go to the second or third decimal.