On Sun, Nov 2, 2008 at 12:54 PM, <svn_grass@osgeo.org> wrote:
Author: hamish
Date: 2008-11-02 06:54:33 -0500 (Sun, 02 Nov 2008)
New Revision: 34139
Modified:
grass/trunk/scripts/v.out.gps/v.out.gps
Log:
comments about nasty gotcha in alternate ogr2ogr solution (merge from devbr6)
...
+# lossy. Also that would allow ogr2ogr -a_srs $IN_PROJ -t_srs EPSG:4326
+# so skip m.proj pains.. if that is done ogr2ogr -a_srs MUST HAVE +wktext
+# with PROJ.4 terms or else the +nadgrids will be ignored! (best to feed
+# it g.proj -wf) in that case.
hi Hamish,
curious - what does that mean? To use ogr2ogr in conjunction with
g.proj -wf is one of my favourites... but is
> Author: hamish
> Date: 2008-11-02 06:54:33 -0500 (Sun, 02 Nov 2008)
> New Revision: 34139
>
> Modified:
> grass/trunk/scripts/v.out.gps/v.out.gps
> Log:
> comments about nasty gotcha in alternate ogr2ogr
solution (merge from devbr6)
...
> +# lossy. Also that would allow ogr2ogr -a_srs $IN_PROJ -t_srs EPSG:4326
> +# so skip m.proj pains.. if that is done ogr2ogr -a_srs MUST HAVE +wktext
> +# with PROJ.4 terms or else the +nadgrids will be ignored! (best to feed
> +# it g.proj -wf) in that case.
hi Hamish,
curious - what does that mean? To use ogr2ogr in
conjunction with
g.proj -wf is one of my favourites... but is
sufficient to work around the indicated '+nadgrids will be ignored'
problem?
If ogr2ogr is given PROJ.4 +terms the OGR srs reading FN ignores anything
it can't parse, which includes +nadgrids with filename. so ogr2ogr skips
+nadgrids file unless the +wktext param is added then it doesn't try to
match terms and passes literally.. FW says it better: http://trac.osgeo.org/gdal/changeset/15681
(google: nadgrids+ogr2ogr for ML)
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:
On Mon, Nov 3, 2008 at 12:18 PM, Hamish <hamish_b@yahoo.com> wrote:
> Author: hamish
> Date: 2008-11-02 06:54:33 -0500 (Sun, 02 Nov 2008)
> New Revision: 34139
>
> Modified:
> grass/trunk/scripts/v.out.gps/v.out.gps
> Log:
> comments about nasty gotcha in alternate ogr2ogr
solution (merge from devbr6)
...
> +# lossy. Also that would allow ogr2ogr -a_srs $IN_PROJ -t_srs EPSG:4326
> +# so skip m.proj pains.. if that is done ogr2ogr -a_srs MUST HAVE +wktext
> +# with PROJ.4 terms or else the +nadgrids will be ignored! (best to feed
> +# it g.proj -wf) in that case.
hi Hamish,
curious - what does that mean? To use ogr2ogr in
conjunction with
g.proj -wf is one of my favourites... but is
sufficient to work around the indicated '+nadgrids will be ignored'
problem?
If ogr2ogr is given PROJ.4 +terms the OGR srs reading FN ignores anything
it can't parse, which includes +nadgrids with filename. so ogr2ogr skips
+nadgrids file unless the +wktext param is added then it doesn't try to
match terms and passes literally.. FW says it better: http://trac.osgeo.org/gdal/changeset/15681
(google: nadgrids+ogr2ogr for ML)
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:
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.
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:
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?
On Wed, Nov 5, 2008 at 3:39 PM, Patton, Eric <epatton@nrcan.gc.ca> 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:
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?
I feel that using -wf will severly damage the metadata (but apparently
ignores nadgrids information which is bad, too - if present).
I didn't go through the entire story, so no suggestion from me.
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:
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.