On Wed, 5 Nov 2008, Patton, Eric wrote:
AFAICT `g.proj -wf` doesn't include grid file, while `g.proj -jf` does.
So I think my "best use `g.proj -wf` in that case" might be wrong as it
drops the grid file, so really best to use:
IN_PROJ="`g.proj -jf` +wktext"
http://trac.osgeo.org/gdal/ticket/2638#comment:6
http://trac.osgeo.org/gdal/changeset/15681
Mhh, that's fairly bad. Perhaps we need a note on
the g.proj and g.region manual pages?
However. I feel that 'g.proj -jf' is a poor representation
compared to 'g.proj -wf', at least it doesn't help to
maintain metadata in a reasonable way.
Markus
Just so I understand the problem: g.proj fails to report nadgrids information
with the -wf whereas -jf does? Should I go ahead and update the page, or is this
a relatively simple fix in the code?
Well, there is no way of specifying a nadgrids file in the WKT format.
Never has been - nothing new there as far as I know. What is new (to me
anyway) is the +wktext PROJ.4 parameter - it looks to me like this should
be included in the g.proj -j output by default - anybody disagree?
Perhaps also when GRASS is generating WKT in the GDAL-compatible format
(i.e. -e flag not specified) it should also include this new
EXTENSION["PROJ4"... parameter that seems to have been introduced -
anybody any thoughts on this? It seems to me this might solve Markus's
original problem. The whole thing seems like a huge hack to me but it's
not our fault the WKT format is so deficient and anyway it's generally
best to retain compatibility with GDAL as much as possible.
Paul
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
