Edzer Pebesma

Thanks @lbusett ! I hadn't thought of this option as a possible GDAL3/2 fall out. One way to mitigate this is to use `sf::gdal_utils`, e.g. `sf::gdal_utils("vectortranslate")` instead of `system("ogr2ogr")`, and...

@mgageo you are hijacking the issue really, but you forgot the `-` in `-t_srs`.

You could look into how CRAN package `x13binary` does this. Alternatively, the gdal utilities interfaced through the [GDAL utils C API](https://gdal.org/api/gdal_utils.html) are available through the `sf` function `gdal_utils`; see [here](https://r-spatial.github.io/sf/reference/gdal_utils.html)...

If this is only about `PROJ_LIB` (and not about `GDAL_DATA`), then the way forward is to use PROJ6's `proj_context_set_search_paths()`, an API point to set the directory that drops the need...

`sf::gdal_utils()` uses the [gdal_utils.h](https://gdal.org/api/gdal_utils.html) API. Some of the "gdal utilities" may not be in here, either because nobody made the effort or for instance because they are Python scripts that...

So, to be clear, `sf::gdal_utils` does not call any external binary (and will never do that).

You could develop `gdalUtils` in a direction where, instead of calling external binaries, it would call `sf::gdal_utils`, for those functions supported. Still external to `gdalUtils`, but at least not external...

Right, it is harder than you'd think: point 5 doesn't look like a quick fix. It gets even harder if sf and rgdal are both loaded, since both store `PROJ_LIB`...

Personally, I'm more in favor of working towards getting GDAL3/PROJ6 to the CRAN windows and OSX build farms.

I'm also planning to attend FOSS4G. Workshops seem to be Aug 22+23.