[PROJ] specifying the search paths

Even Rouault even.rouault at spatialys.com
Wed Jul 1 07:40:25 PDT 2020


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

In the non-public API (proj_internal.h), there's a pj_context_set_user_writable_directory() 
function to modify it. It is actually PROJ_DLL exported because used by the projsync utility, 
but do not rely on it for production code, as this might change in the future, if the function 
was promoted to the public API.

On Unix, you can also modify it by setting the XDG_DATA_HOME environment variable (the 
actually directory will then be ${XDG_DATA_HOME}/proj)
A non-documented feature used by PROJ tests is also to use
the PROJ_USER_WRITABLE_DIRECTORY environment variable: this will have precedence on 
XDG_DATA_HOME

See
https://github.com/OSGeo/PROJ/blob/b66798a8f3d559b5fe28c22973241e97d191a053/src/
filemanager.cpp#L1190

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/c58f0aaa/attachment.html>


More information about the PROJ mailing list