On Fri, 30 Jul 2010, Hamish wrote:
Glynn:
Ah; so pj_get_def() returns a definition using spaces both
as an argument separator and within arguments?
In which case, we need a more robust alternative to
pj_get_def().
I guess the alternative is to remove the step whereby (in g.proj) the set
of PROJ parameters that has been constructed by pj_get_kv() (a GRASS
function, despite the pj_ prefix) is passed to pj_get_def() (a PROJ.4
function) for conversion into a string. Instead, part of pj_get_kv() could
be separated out into a separate function that GRASS modules could use to
get access to the PROJ parameters as an array of separate parameters
rather than as a concatentated string. That would be a little bit of work
but not too hard to do.
only if you can't live with Paul's fix, otherwise I think we're
ok. Are the NTv2 grid files likely to ever be installed to a
dir with a " +" in the name? famous last words, but it seems
unlikely to me. or at least defer worrying about it until we
get an actual bug report.
Interesting sidenote here is that it is (AFAIK) an undocumented feature of
PROJ.4 that it accepts a full pathname as the value of the +nadgrids
parameter. Years ago when we were putting the datum support into GRASS,
the recommended method from Frank was just to put an unqualified filename
as the value of +nadgrids, and then call the pj_set_finder() function to
specify a "finder function" that PROJ.4 can call back to, to find the
directory where the gridfiles are stored. But this approach falls down
when exporting a PROJ.4 string for use by another application, as there is
no way of telling that application where the gridfiles are stored. So we
had to change it to use a fully qualified path to the nadgrids file -
which has now thrown up this problem.
Paul
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
