[GRASS-dev] 6.4.0 blocker bugs

[Paul Kelly]

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