Re: Management of datum grid files.

> On 27 Nov 2019, at 21:31, Helmut Kudrnovsky <[email protected]> wrote:
> 
>>> Keep in mind, in the most cases in windows,  proj  is bundled with other
>>> Software.
>>> 
>>> E.g. OSGeo4W where proj needed files are living in  e.g.
>>> c:\OSGeo4W\share\proj\ or in standalone winGRASS or qgis where  proj
>>> needed
>>> files are living in e.g. c:\programs\qgis\share-subfolder  and 
>>> %PROJ_LIB%
>>> is set accordingly.
>> 
>> That's one of the reason to propose an installation-independent directory.
>> That way different installations may be able to use the same grids & cache. 
> 
> so the idea is:
> 
> that e.g. OSGeo4W puts the proj shared things into %LOCALAPPDATA%, a
> standalone GIS software depending on proj looks into %LOCALAPPDATA% if there
> is a subfolder called e.g. proj? or the other way around, a standalone GIS
> software depending on proj puts needed files into %LOCALAPPDATA%\proj and
> OSGeo4W looks while updating/upgrading its proj version into %LOCALAPPDATA%
> if there is a proj subfolder with shared folders? what if in
> %LOCALAPPDATA%\proj are already files with the same name? should these be
> just overwritten? how will be there a track of updated/ugraded/changed
> shared proj files if different software are working/updating/upgrading them
> at the same time? 
> 
> or should be set %PROJ_LIB% windows system wide (for all users? for just one
> user in a multiuser network?) and a standalone GIS software depending on
> proj/OSGeo4W while updating looks for %PROJ_LIB% instead of
> %LOCALAPPDATA%\proj?
> 
> will this work in the windows side of the world? ;-)
> 
> I'm not against a consolidated way how to deal with proj supporting files
> like grids and their big file sizes; with a _co-maintainer of winGRASS_ hat
> on, I know, windows can be sometimes a hardly manageable beast ... here just
> for well thought solution on the windows side of the world ;-)
> 

I would think that we would mostly just continue doing what we doing with PROJ_LIB
at the moment with the addition of looking for usable grids in %APPDATA% (on Windows).

This is somewhat equivalent to what is done on unix-based installs already, where the
logic for finding grids is something like:

1. Look in current dir
2. Look in search paths set by API function
3. Look in PROJ_LIB
4. Look in /usr/local/share/proj or whatever was specified with ./configure

On Windows step 4 would look for resources in %APPDATA%\PROJ

Is that a reasonable approach?

/Kristian







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