[PROJ] Management of datum grid files.
Helmut Kudrnovsky
hellik at web.de
Wed Nov 27 12:31:03 PST 2019
>> 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 ;-)
-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/PROJ-4-f3840930.html
More information about the PROJ
mailing list