Yes the reason $GISBASE/etc/nad/ doesn't need to be included in the nadgrids
definition in the PROJ_INFO file is that the functions which prepare the
GRASS co-ordinate system definitions for use by PROJ (pj_get_kv() and
pj_get_string() in lib/proj/get_proj.c) call the PROJ function pj_set_finder
() to specify a name of a "finder function", which is provided by GRASS
(actually set_proj_lib() in get_proj.c; should really be re-written using
G_asprintf() if it is staying) and returns the location of the datum
gridshift files in $GISBASE/etc/nad/. PROJ then calls this function whenever
it wants during the transformation if it needs to find the files.
At the time we were putting the datum transformation support into GRASS,
Frank indicated that this was the preferred solution.
But looks like we've hit a limitation.
My peferred solution would be, as long as specifying the full path to the
gridshift file is supposed to work and isn't an undocumented feature of
PROJ, would be to change pj_get_kv() (which is called by g.proj) to prepend
$GISBASE/etc/nad/ to the name of the gridshift file when it prepares the
PROJ string, and to do away with pj_set_finder().
-------------------------------------------- Managed by Request Tracker
My peferred solution would be, as long as specifying the full path to
the gridshift file is supposed to work and isn't an undocumented
feature of PROJ,
from the cs2cs man page:
"The environment parameter
PROJ_LIB establishes the default directory for a
file reference without an absolute path. This
is also used for supporting files like datum
shift files."
I take that to mean it is intended.
would be to change pj_get_kv() (which is called by g.proj) to prepend
$GISBASE/etc/nad/ to the name of the gridshift file when it prepares
the PROJ string, and to do away with pj_set_finder().
My peferred solution would be, as long as specifying the full path to
the gridshift file is supposed to work and isn't an undocumented
feature of PROJ, would be to change pj_get_kv() (which is called by
g.proj) to prepend $GISBASE/etc/nad/ to the name of the gridshift
file when it prepares the PROJ string, and to do away with
pj_set_finder().
temporary work-around to fix v.in.garmin's WGS84->GRASS location bug:
IN_PROJ="+proj=longlat +towgs84=0.000,0.000,0.000"
OUT_PROJ="`g.proj -jf | sed -e
's/+nadgrids=/+nadgrids=$GISBASE\/etc\/nad\//'`"
I'd like to work towards a general purpose m.proj2 module again with -i
and -o flags to very simply convert a list of points to/from WGS84 & the
current location settings. As above, it's easy to do with cs2cs in a
script, but I still haven't figured out how to pipe into a script well
'cause "read" is kind of crappy.. so perhaps C is better albeit
reinventing the wheel & something else that only a smaller part of the
crowd can maintain, etc.
"The environment parameter
PROJ_LIB establishes the default directory for a
file reference without an absolute path. This
^^^^^^^^^^^^^^^^^^^^^^^^^
is also used for supporting files like datum
shift files."
I take that to mean it is intended.
It would seem so.
would be to change pj_get_kv() (which is called by g.proj) to prepend
$GISBASE/etc/nad/ to the name of the gridshift file when it prepares
the PROJ string, and to do away with pj_set_finder().
If you say so, you're the expert.
Untested (very simple) patch attached. On second thoughts even if we put the full path in by default, it is probably best to keep pj_set_finder() for odd circumstances in PROJ_INFO files, e.g. it would be hard to catch
datumparams: nadgrids=conus
which has been valid up to now.
Untested (very simple) patch attached. On second thoughts even if we put the full path in by default, it is probably best to keep pj_set_finder() for odd circumstances in PROJ_INFO files, e.g. it would be hard to catch
datumparams: nadgrids=conus
which has been valid up to now.
I am tempted to submit the patch as going by what Hamish said, I am confident it will solve the problem. The only problem might be if people are using the output of g.proj -j for some generic purpose. Now (if gridshift datum files are used in the projection definition) it will be machine-specific as the path to the gridshift files is hardcoded. But being machine-specific is possibly less of a disadvantage than being GRASS-specific, especially if people are using other GIS software.
So if there are no objections I will apply the patch in a few days.