r-spatial / discuss

a discussion repository: raise issues, or contribute!
54 stars 12 forks source link

OSGeo stack on CRAN (for wiki) #38

Closed mdsumner closed 2 years ago

mdsumner commented 4 years ago

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

edzer commented 4 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.

edzer commented 4 years ago

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:

mdsumner commented 4 years ago

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

rsbivand commented 4 years ago

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?

rsbivand commented 4 years ago

Is https://stat.ethz.ch/pipermail/r-sig-mac/2020-May/013528.html relevant?

rsbivand commented 4 years ago

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?

edzer commented 4 years ago

Yes, sf uses default context everywhere, for GDAL I don't know.

rsbivand commented 4 years ago

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);
...
edzer commented 4 years ago

Yes.

mdsumner commented 4 years ago

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.

rsbivand commented 4 years ago

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?

edzer commented 4 years ago

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/...