Greetings
A couple of days ago I have exchanged a few messages with Paul Kelly and Micha Silver regarding this issue. But now I have a new example and I want to know if I’m doing anything wrong and better understand what is GRASS behaviour.
I’m trying to have an aumatic procedure to reproject images using gdalwarp. First it checks image CRS (g.proj input=IMAGE -jf) and compares with Location’s CRS (g.proj -jf).
As target_CRS I’m using the output from g.proj -j -f .
In this case, g.proj -jf give me the Location«s CRS:
+proj=utm +south +no_defs +zone=24 +a=6378137 +rf=298.257223563 +towgs84=0.000,0.000,0.000 +to_meter=1
(Sidenote. This Location was created based on an EPSG)
I use this expression to warp the image:
gdalwarp -t_srs “+proj=utm +south +no_defs +zone=24 +a=6378137 +rf=298.257223563 +towgs84=0.000,0.000,0.000 +to_meter=1” input.tif proj4.tif
But if I check proj4.tif CRS I get this:
+proj=utm +south +no_defs +zone=24 +a=6378137 +rf=298.257223563 +to_meter=1
Trying to open with OGR…
Trying to open with GDAL…
…succeeded.
Datum not recognised by GRASS and no parameters found
Why towgs84 is not kept in the image?
THanks
Kim
On Tue, Jun 29, 2010 at 11:20 AM, Kim Besson <kimbesson1981@gmail.com> wrote:
Greetings
A couple of days ago I have exchanged a few messages with Paul Kelly and
Micha Silver regarding this issue. But now I have a new example and I want
to know if I'm doing anything wrong and better understand what is GRASS
behaviour.
I'm trying to have an aumatic procedure to reproject images using gdalwarp.
First it checks image CRS (g.proj input=IMAGE -jf) and compares with
Location's CRS (g.proj -jf).
As target_CRS I'm using the output from g.proj -j -f .
In this case, g.proj -jf give me the Location«s CRS:
+proj=utm +south +no_defs +zone=24 +a=6378137 +rf=298.257223563
+towgs84=0.000,0.000,0.000 +to_meter=1
(Sidenote. This Location was created based on an EPSG)
I use this expression to warp the image:
gdalwarp -t_srs "+proj=utm +south +no_defs +zone=24 +a=6378137
+rf=298.257223563 +towgs84=0.000,0.000,0.000 +to_meter=1" input.tif
proj4.tif
But if I check proj4.tif CRS I get this:
+proj=utm +south +no_defs +zone=24 +a=6378137 +rf=298.257223563 +to_meter=1
Trying to open with OGR...
Trying to open with GDAL...
...succeeded.
Datum <unknown> not recognised by GRASS and no parameters found
Why towgs84 is not kept in the image?
To my knowledge the GeoTIFF format is not able to keep the towgs84 string.
Did you try with different formats?
But in general, it may be better to assign proj metadata via EPSG code.
Markus
Hello Markus
Thanks for the reply
To do what you suggest, I would have to retrieve LOCATION’s CRS EPSG code and I’m not able to get it automatically. I only can get that PROJ4 string by using g.proj. Is there a way to automatically get a LOCATIONS’s EPSG code?
Best regards,
Kim
2010/6/29 Markus Neteler <neteler@osgeo.org>
On Tue, Jun 29, 2010 at 11:20 AM, Kim Besson <kimbesson1981@gmail.com> wrote:
Greetings
A couple of days ago I have exchanged a few messages with Paul Kelly and
Micha Silver regarding this issue. But now I have a new example and I want
to know if I’m doing anything wrong and better understand what is GRASS
behaviour.
I’m trying to have an aumatic procedure to reproject images using gdalwarp.
First it checks image CRS (g.proj input=IMAGE -jf) and compares with
Location’s CRS (g.proj -jf).
As target_CRS I’m using the output from g.proj -j -f .
In this case, g.proj -jf give me the Location«s CRS:
+proj=utm +south +no_defs +zone=24 +a=6378137 +rf=298.257223563
+towgs84=0.000,0.000,0.000 +to_meter=1
(Sidenote. This Location was created based on an EPSG)
I use this expression to warp the image:
gdalwarp -t_srs “+proj=utm +south +no_defs +zone=24 +a=6378137
+rf=298.257223563 +towgs84=0.000,0.000,0.000 +to_meter=1” input.tif
proj4.tif
But if I check proj4.tif CRS I get this:
+proj=utm +south +no_defs +zone=24 +a=6378137 +rf=298.257223563 +to_meter=1
Trying to open with OGR…
Trying to open with GDAL…
…succeeded.
Datum not recognised by GRASS and no parameters found
Why towgs84 is not kept in the image?
To my knowledge the GeoTIFF format is not able to keep the towgs84 string.
Did you try with different formats?
But in general, it may be better to assign proj metadata via EPSG code.
Markus
Hi Kim,
On Tue, Jun 29, 2010 at 6:37 PM, Kim Besson <kimbesson1981@gmail.com> wrote:
Hello Markus
Thanks for the reply
To do what you suggest, I would have to retrieve LOCATION's CRS EPSG code
and I'm not able to get it automatically. I only can get that PROJ4 string
by using g.proj. Is there a way to automatically get a LOCATIONS's EPSG
code?
That not possible (yet?) - also GDAL/OGR does not have a reverse
lookup - too complicated or too many exceptions.
The string
+proj=utm +south +no_defs +zone=24 +a=6378137 +rf=298.257223563
+towgs84=0.000,0.000,0.000 +to_meter=1
looks like
http://spatialreference.org/ref/epsg/32724/
to me.
cs2cs -le | grep 'WGS 84'
WGS84 a=6378137.0 rf=298.257223563 WGS 84
Markus
So, this means that I’m not able to use g.proje -jf output to properly define a coordinate system right?
2010/6/29 Markus Neteler <neteler@osgeo.org>
Hi Kim,
On Tue, Jun 29, 2010 at 6:37 PM, Kim Besson <kimbesson1981@gmail.com> wrote:
Hello Markus
Thanks for the reply
To do what you suggest, I would have to retrieve LOCATION’s CRS EPSG code
and I’m not able to get it automatically. I only can get that PROJ4 string
by using g.proj. Is there a way to automatically get a LOCATIONS’s EPSG
code?
That not possible (yet?) - also GDAL/OGR does not have a reverse
lookup - too complicated or too many exceptions.
The string
+proj=utm +south +no_defs +zone=24 +a=6378137 +rf=298.257223563
+towgs84=0.000,0.000,0.000 +to_meter=1
looks like
http://spatialreference.org/ref/epsg/32724/
to me.
cs2cs -le | grep ‘WGS 84’
WGS84 a=6378137.0 rf=298.257223563 WGS 84
Markus
On Wed, Jun 30, 2010 at 4:33 PM, Kim Besson <kimbesson1981@gmail.com> wrote:
So, this means that I'm not able to use g.proje -jf output to properly
define a coordinate system right?
Of course you can.
Back to your original email:
On Tue, Jun 29, 2010 at 11:20 AM, Kim Besson <kimbesson1981@gmail.com> wrote:
...
But if I check proj4.tif CRS I get this:
+proj=utm +south +no_defs +zone=24 +a=6378137 +rf=298.257223563 +to_meter=1
Trying to open with OGR...
Trying to open with GDAL...
...succeeded.
Datum <unknown> not recognised by GRASS and no parameters found
Yuo see that there is not datum=... in that string. Hence unknown.
Instead of writing out togws84=0.0,0.0,0.0 you could use
datum=wgs84 which is stored in GeoTIFF.
Markus