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:

https://github.com/tidyverse/ggplot2/blob/519bc83942d93bca4777b75ab3f9f79d3200b745/man/geom_map.Rd#L125-L162

https://github.com/tidyverse/ggplot2/blob/519bc83942d93bca4777b75ab3f9f79d3200b745/man/sf_transform_xy.Rd#L27-L43

[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:

https://github.com/tidyverse/ggplot2/blob/e0d54f6d2be6452bbab61a5018abc231a3172ca6/tests/testthat/test-coord_sf.R#L290

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 :)