Closed mdsumner closed 2 years ago
Thanks! I'd say tiler
no, as it can be installed without any dependencies (like gdalUtils
), but uFTIR
yes. It's more like which packages are affected when we the Windows or OSX binary CRAN build systems change/update/expand.
And sorry but I changed the wiki page name and hence link into https://github.com/r-spatial/discuss/wiki/R-packages-that-use-the-OSGEO-stack-in-System-Requirements:
I was thinking not to be concerned about versions, because if they become necessary it wouldn't be hard to fork (and lobby CRAN) for a given arrangement. But I guess that implies some kind of coordinated release for winlib uses?
Another thought I had was to include the downloader tools for grid files if and when someone wants those, so a data package seems the right place to put shared tools for those. But, otherwise I don't have much clarity of thought on what could/should happen. (Whatever it is I wish to make less work for you and Roger and Jeroen, if possible ...)
A curiosity: how do packages using GDAL/PROJ manage without the share/proj and share/gdal contents? Are they all avoiding any use of functions that need metadata?
Re: CND, see the end of https://rgdal.r-forge.r-project.org/articles/CRS_projections_transformations.html, which suggests that this could be done either way. The key thing for PROJ seems to be to set/unset enables globally or in the same context - in rgdal each PROJ function is run in a separate context, which isn't helpful. I think sf uses the default context, so I think the same context - does GDAL use the default PROJ context?
Yes, sf
uses default context everywhere, for GDAL I don't know.
Does using the default context mean that it does not need to be destroyed? I'm often doing:
...
PJ_CONTEXT *ctx = proj_context_create();
...
proj_context_destroy(ctx);
...
Yes.
I can report that you can get away with quite a lot without those share files ... I expect some packages only use certain formats etc.
Do we know which do use them, or maybe rely on the CRAN binaries of sf and rgdal providing them silently by setting environment variables?
You could look at which ones install them, but that doesn't have to mean anything since it looks like most authors have simply copied the configure scripts from rgdal/rgeos/sf/...
Just doing a sweep for candidates (didn't really expect to find more).
searching for "proj" is more problematic ... but " proj" and "proj " and "geos" didn't pull up obvious ones