[PROJ] Management of datum grid files.

[Helmut Kudrnovsky]

Even Rouault-2 wrote
>> 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? ;-)
> 
> Huh, what a mess ! No wonder I stay away from Windows as much as possible
> :-)
> 
> I'd say that applications shouldn't mess with  %LOCALAPPDATA%\proj at all. 
> What will be put there will be managed by PROJ itself (in RFC4 a sqlite 
> database with a cache of downloading grid chunks. And if
> https://github.com/OSGeo/PROJ/issues/1750 comes true, with what the script 
> will install). An implementation detail.
> They might go on with the "old way" of installing the grids in the
> "PROJ_LIB" 
> they manage (or ..\bin\share\proj if we adopt Joaquim's strategy).
> 
> So an updated logic for the pj_open_lib_ex() function that attempts to
> locate 
> a grid would be in the order they are done:
> - user callback provided by user through proj_context_set_file_finder() ? 
> (does anybody use that ? Probably not)
> - search paths set through proj_context_set_search_paths()
> - PROJ_LIB env var
> - hardcoded path at build time
> - current dir
> - ..\bin\share\proj with proposed PR
> - %LOCALAPPDATA%\proj /  ${XDG_DATA_HOME}/proj for grids as files (cf
> https://
> github.com/OSGeo/PROJ/issues/1750)
> - RFC4 + networking enabled: %LOCALAPPDATA%\proj /  ${XDG_DATA_HOME}/proj
> for 
> the SQLite3 cache.db
> - RFC4 + networking enabled: network access to fetch the grid bit
> 
> Actually the current behaviour is a bit more subtle than that. For
> example, if 
> the search paths are defined, this stops the following mechanisms to be 
> attempted even if the grid is not found. Some tweakings likely needed to 
> rationalize that a bit.
> 
> 
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> PROJ mailing list

> PROJ at .osgeo

> https://lists.osgeo.org/mailman/listinfo/proj

Sounds reasonable 



-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/PROJ-4-f3840930.html