[Proj] quoting +nadgrids ?

[Frank Warmerdam]

Glynn Clements wrote:
> Personally, I'm not inclined to suggest that PROJ should be
> introducing this sort of workaround for issues with software which
> uses it.
> 
> However, if you decide to go that route, URL encoding (%##, e.g. %20
> for space) serves roughly this purpose (although the use of '+' for
> space wouldn't be desirable here). This assumes that % is uncommon in
> PROJ parameter values.

Glynn,

I had been avoiding "normal" escaping schemes primarily to avoid
the escaping getting interpreted earlier in the processing chain,
though I suppose url encoding would not be widely used.  Also, to
the best of my knowledge the only things we might need to escape
would be " " and "+".

> Another option would be to provide utility functions to convert
> between an argument list (i.e. a list of strings) and a string. This
> would make it easier for GDAL (etc) to "do it right".

In fact GDAL uses pj_init_plus() which takes the whole string rather
than a set of pre-separated options.  So PROJ.4 already does have
a natural place to put the parsing rules for applications that use it.

Earlier I suggested this issue wasn't really a PROJ.4 issue, but now
that I think about pj_init_plus() it clearly is a PROJ.4 issue.  Based
on that it seems to come down to how to do the escaping for interpretation
by pj_init_plus().

I had proposed the @@@space@@@ idea just because it wouldn't be interpreted
anywhere else, though it is somewhat peculiar.  Can you, or anyone,
provide an argument for a different approach?  Were you suggesting url
encoding because it was easily extended to other escaping operations?

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent