[PROJ] specifying the search paths

[Even Rouault]

On mercredi 1 juillet 2020 17:33:05 CEST Roger Bivand wrote:
> Even,
> 
> On Wed, 1 Jul 2020, Even Rouault wrote:
> > Roger,
> > 
> >> I have a question about the use of
> >> proj_context_set_search_paths(PJ_DEFAULT_CTX, ...). On initiating PRØJ, I
> >> see from proj_info().searchpath that (now 7.1.0) I have three paths, the
> >> last two identical /usr/local/share/proj, and the first
> >> $HOME/.local/share/proj - which contains a cache.db.
> >> 
> >> For testing on other platforms than my own, I need to change the first
> >> path to a temporary directory with write access, so that I do not write
> >> in
> >> the user space of the test platform. So I use
> >> proj_context_set_search_paths(PJ_DEFAULT_CTX, ...), providing the correct
> >> length of the vector of paths, and the paths themselves. The
> >> user-writeable path is first, as at startup. It, however, does not
> >> contain
> >> a cache.db file, even of zero length. After finding a coordinate
> >> operation
> >> (using a grid cached in $HOME/.local/share/proj), the temporary directory
> >> remains empty, $HOME/.local/share/proj is used despite not being on the
> >> active path list, and the operation completes successfully.
> >> 
> >> This is, however, not what I need - I need the download to occur to the
> >> temporary directory, so that I can demonstrate that cache.db gets
> >> populated.
> >> 
> >> May libproj be caching paths so that even if the path to the
> >> use-writeable
> >> directory has been set, it still uses the one determined on load, even if
> >> it had been renamed and is not on the this of search paths? I find the
> >> default use-writeable directory being re-created even when it is not on
> >> the declared list of search paths. I'm only using PJ_DEFAULT_CTX - is
> >> that
> >> the problem?
> > 
> > The location of the user writable directory for cache.db is not controlled
> > through proj_context_set_search_paths(). You can get the location with
> > proj_context_get_user_writable_directory()
> 
> Thanks for a rapid and full reply. My context is that in order to include
> runnable code examples in R packages, they need to meet a requirement not
> to cause data to be written outside the R temporary directory for the
> running instance irrespective of platform. So I need to control the
> address of the user-writeable directory completely in order to show users
> what is going on, and to permit the package to meet test requirements. I
> can try pj_context_set_user_writable_directory() understanding that it is
> not part of the public API, and will report back.

I'd say R shouldn't worry about what PROJ does under the hood. This is just caching. An 
internal detail that shouldn't have observable effect from pepole using the PROJ API. The 
purpose of this per-account directory was that the cache could be shared by many PROJ 
using software: GDAL, QGIS, etc.

If you consider using pj_context_set_user_writable_directory() for more than testing, I'd 
suggest you to propose a pull request to move it to the public API as 
proj_context_set_user_writable_directory().

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20200701/9c331e76/attachment-0001.html>