Re: Management of datum grid files.

A previous point. I hate things installed in %APPDATA% and try to fight is much as I can ... but keep losing. The reason is simple, %APPDATA% is a hidden directory and users who have to set Windows to show hidden directories will not see it, and uninstallers tend to leave things there so it slowly becomes a huge trash sink.

But the point I want to bring is different. I saw in the camake scripts that there is an hard-wired default %PROJ_LIB% pointing to  bin/../share/proj but since this is set by cmake that only works when one builds proj and do not move it after.

Because in GMT we ship an full GDAL3+PROJ and I wanted to avoid the need to set ENV variables, I patched proj code to also look for  bin/../share/proj but at runtime. This means that we can install where ever and it still works. The question is, is there interest for such a feature in the PROJ itself? If yes, I can make a PR.

Joaquim


-----Original Message-----
From: PROJ <[email protected]> On Behalf Of Kristian Evers
Sent: Wednesday, November 27, 2019 8:14 AM
To: Even Rouault <[email protected]>; [email protected]
Subject: Re: [PROJ] Management of datum grid files.

Perhaps we should look into using %APPDATA%\Local\PROJ as the default path for %PROJ_LIB% on Windows?

This has been good practice on Windows for quite a while now. I guess the reason that PROJ doesn't have a default location on Windows is that in earlier versions of Windows no such place was available.

/Kristian

-----Original Message-----
From: PROJ <[email protected]> On Behalf Of Even Rouault
Sent: 26. november 2019 23:12
To: [email protected]
Subject: Re: [PROJ] Management of datum grid files.

> No. The PROJ binary has no idea where PROJ_LIB can be pointed too. 
> That's why it is needed to be defined. For some builds typically done 
> by Linux distributions where the installaton path is known at build 
> time, the default search path is hardcoded in the binary, but for 
> Windows, the actual installation path is rarely known in advance.

Yes, that's why I floated around the idea that PROJ default search path could also include the  ${XDG_DATA_HOME}/proj directory, where ${XDG_DATA_HOME} resolves to ${HOME}/.local/share on Unix builds and ${USERPROFILE}/.local/ share on Windows builds, that RFC4 plans to use to put the local cache of downloaded chunks from the CDN. That has also the advantage that it is a user writable directory, which can help people not having admin rights.

Even

--
Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj

_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj