Confusing test failure for sf_transform_xy() "no arguments in initialization list"

[MichaelChirico]

We are observing this test failure:

── Error ('test-coord_sf.R:290'): sf_transform_xy() works ──────────────────────
Error in `proj_from_crs(from)`: no arguments in initialization list: GEOGCRS["WGS 84",
    DATUM["World Geodetic System 1984",
        ELLIPSOID["WGS 84",6378137,298.257223563,
            LENGTHUNIT["metre",1]]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433]],
    CS[ellipsoidal,2],
        AXIS["geodetic latitude (Lat)",north,
            ORDER[1],
            ANGLEUNIT["degree",0.0174532925199433]],
        AXIS["geodetic longitude (Lon)",east,
            ORDER[2],
            ANGLEUNIT["degree",0.0174532925199433]],
    USAGE[
        SCOPE["unknown"],
        AREA["World"],
        BBOX[-90,-180,90,180]],
    ID["EPSG",4326]]
Backtrace:
    ▆
 1. └─ggplot2::sf_transform_xy(data, 3347, 4326) at test-coord_sf.R:290:2
 2.   └─sf::sf_project(...)
 3.     └─sf (local) proj_from_crs(from)

Probably this is related to missing certain GDAL drivers. But I hope you agree the error message is not very helpful. I'm not sure if this is something on the ggplot2 or the sf side; I know sf offers some things we could use to escape here e.g. sf_extSoftVersion() or is_driver_available():

https://github.com/r-spatial/sf/blob/b798413d4cd681cd173f9bdc110f2a014555ee09/tests/testthat/test_read.R#L176

https://github.com/r-spatial/sf/blob/b798413d4cd681cd173f9bdc110f2a014555ee09/tests/testthat/test_read.R#L121

Happy to offer more details as needed but I'm not sure what would help.

---

FWIW, the issue also causes some examples to fail:

ggplot2/man/geom_map.Rd

Lines 125 to 162 in 519bc83

	if (require(maps)) {
	crimes <- data.frame(state = tolower(rownames(USArrests)), USArrests)
	# Equivalent to crimes \%>\% tidyr::pivot_longer(Murder:Rape)
	vars <- lapply(names(crimes)[-1], function(j) {
	data.frame(state = crimes$state, variable = j, value = crimes[[j]])
	})
	crimes_long <- do.call("rbind", vars)
	states_map <- map_data("state")
	# without geospatial coordinate system, the resulting plot
	# looks weird
	ggplot(crimes, aes(map_id = state)) +
	geom_map(aes(fill = Murder), map = states_map) +
	expand_limits(x = states_map$long, y = states_map$lat)
	# in combination with `coord_sf()` we get an appropriate result
	ggplot(crimes, aes(map_id = state)) +
	geom_map(aes(fill = Murder), map = states_map) +
	# crs = 5070 is a Conus Albers projection for North America,
	# see: https://epsg.io/5070
	# default_crs = 4326 tells coord_sf() that the input map data
	# are in longitude-latitude format
	coord_sf(
	crs = 5070, default_crs = 4326,
	xlim = c(-125, -70), ylim = c(25, 52)
	)
	ggplot(crimes_long, aes(map_id = state)) +
	geom_map(aes(fill = value), map = states_map) +
	coord_sf(
	crs = 5070, default_crs = 4326,
	xlim = c(-125, -70), ylim = c(25, 52)
	) +
	facet_wrap(~variable)
	}

ggplot2/man/sf_transform_xy.Rd

Lines 27 to 43 in 519bc83

	\examples{
	if (requireNamespace("sf", quietly = TRUE)) {
	# location of cities in NC by long (x) and lat (y)
	data <- data.frame(
	city = c("Charlotte", "Raleigh", "Greensboro"),
	x = c(-80.843, -78.639, -79.792),
	y = c(35.227, 35.772, 36.073)
	)
	# transform to projected coordinates
	data_proj <- sf_transform_xy(data, 3347, 4326)
	data_proj
	# transform back
	sf_transform_xy(data_proj, 4326, 3347)
	}
	}

[teunbrand]

I'm relatively sure ggplot2 assumes that when {sf} is installed, the GDAL drivers work as intended.

I agree that the error message isn't helpful, but it is thrown from an {sf} function so there is little control that ggplot2 has over the message other than wrapping every piece of {sf} related code in tryCatch() blocks.

Other than maybe putting the geom_map() examples that use coord_sf() in if (require("sf")) blocks, I'm not sure what ggplot2 can do about this issue.

[MichaelChirico]

{sf} owns the error message, but {ggplot2} owns the map data & I would guess could be responsible for knowing where it comes from & thus what drivers are needed to process it?

@edzer WDYT? Is there anything reasonably straightforward {ggplot2} and/or {sf} could do to help with the error messaging here?

[edzer]

@MichaelChirico I'm not sure; can you provide a reprex that triggers this, or point to where it happens? I've never seen the no arguments in initialization list error, I believe.

[MichaelChirico]

I can point to the line causing it:

ggplot2/tests/testthat/test-coord_sf.R

Line 290 in e0d54f6

out <- sf_transform_xy(data, 3347, 4326)

But it will be hard to offer a reprex I'm afraid, sorry :\

[edzer]

I can only find the error message here, but that should not be callable (it's part of a standalone app, not the PROJ library we use). What does sf::sf_extSoftVersion() give on your system?

[MichaelChirico]

I'll have to return to this when I'm off leave in May

[MichaelChirico]

sf::sf_extSoftVersion()
#                  GEOS                  GDAL                proj.4        GDAL_with_GEOS            USE_PROJ_H                  PROJ 
#               "3.5.0" "3.6.0dev-7f16b09a89"               "7.0.0"                "true"               "false"               "7.0.0"

[edzer]

That's a pretty old software stack; does the error persist with updated sys reqs?

[MichaelChirico]

I'll report back when it's updated but that may take years :)

[teunbrand]

I'm going to go ahead and close this issue as there isn't anything I can easily investigate.
If you can find a reprex with a recentish software stack, I'd be happy to reopen this issue and find ways ggplot2/sf can improve upon the messaging here.