Franz Schiller wrote:
Hello Frank. Did you manage to get any sucess with this?
Thank you for your help
Franz,
Sorry for the delay in responding. I moved my household over the weekend,
and only got back on the net last night. I have reproduced your problem
and come to the conclusion that it is due to an incomplete coordinate system
in your source file that is being misinterpreted. The listgeo report looks
like:
Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTiepointTag (2,3):
0 0 0
0 0 0
ModelPixelScaleTag (1,3):
0 0 0
End_Of_Tags.
Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeGeographic
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
GeographicTypeGeoKey (Short,1): Unknown-65535
GeogLinearUnitsGeoKey (Short,1): Linear_Meter
GeogAngularUnitsGeoKey (Short,1): Linear_Meter
ProjCoordTransGeoKey (Short,1): User-Defined
End_Of_Keys.
End_Of_Geotiff.
GDAL translates this to:
GEOGCS[,
DATUM["unknown",
SPHEROID["unretrievable - using WGS84",6378137,298.257223563]],
PRIMEM["Greenwich",0],
UNIT["metre",1]]
The key problem here is that the geographic coordinate system is not
being recognised as being in degrees, and so GDAL does not map it back
to radians before doing the transformation and things all go wrong.
The simple workaround is to include the "-s_srs WGS84" switch on the
commandline to override the source coordinate system and treat it as
normal WGS84.
eg.
gdalwarp -s_srs WGS84 -t_srs EPSG:3763 ROI_QB_MUL_2.tif out.tif
The geotags in the file are sufficiently malformed that I'm not
inclined to try and adjust how GDAL handles it.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
