Bug#695060: libgdal1: GeoTIFF file with +to_meter=1000000 interpreted incorrectly
Reid Priedhorsky
reidpr at lanl.gov
Mon Dec 3 20:57:48 UTC 2012
Package: libgdal1
Version: 1.9.0-3.1
Severity: normal
Hi,
I have a GeoTIFF file (attached) created with python-gdal with the following
spatial reference system (WKT):
PROJCS["Miller_Mm",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],
AUTHORITY["LOCAL","540036"]],
PROJECTION["Miller_Cylindrical"],
PARAMETER["latitude_of_center",0],
PARAMETER["longitude_of_center",0],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["unknown",1000000]]
i.e., a Miller projection with units of megameters instead of meters.
When GDAL reads this file back, units are erroneously interpreted as meters:
$ gdalinfo foo.tif
Driver: GTiff/GeoTIFF
Files: foo.tif
Size is 10, 20
Coordinate System is:
PROJCS["LUnits = unknown",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]],
PROJECTION["Miller_Cylindrical"],
PARAMETER["latitude_of_center",0],
PARAMETER["longitude_of_center",0],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["unknown",1]]
Origin = (-20.015098236551182,-14.671436039695894)
Pixel Size = (2.001509823655118,2.934287207939179)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( -20.0150982, -14.6714360) ( 0d 0' 0.65"W, 0d 0' 0.48"S)
Lower Left ( -20.0150982, 44.0143081) ( 0d 0' 0.65"W, 0d 0' 1.43"N)
Upper Right ( 0.0000000, -14.6714360) ( 0d 0' 0.01"E, 0d 0' 0.48"S)
Lower Right ( 0.0000000, 44.0143081) ( 0d 0' 0.01"E, 0d 0' 1.43"N)
Center ( -10.0075491, 14.6714360) ( 0d 0' 0.32"W, 0d 0' 0.48"N)
Band 1 Block=10x20 Type=Float32, ColorInterp=Gray
(Note that while I use gdalinfo to demonstrate the problem, it also appears in
tools that link to GDAL, e.g. QGIS, so that's why I report it against libgdal1
rather than gdal-bin.)
listgeo in the geotiff-bin package apparently interprets the megameters
correctly, suggesting the problem is in the read rather than write phase:
$ listgeo foo.tif
Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTransformationTag (4,4):
2.00150982365512 0 0 -20.0150982365512
0 2.93428720793918 0 -14.6714360396959
0 0 0 0
0 0 0 1
End_Of_Tags.
Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeProjected
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
GTCitationGeoKey (Ascii,10): "Miller_Mm"
GeographicTypeGeoKey (Short,1): GCS_WGS_84
GeogCitationGeoKey (Ascii,7): "WGS 84"
GeogAngularUnitsGeoKey (Short,1): Angular_Degree
GeogSemiMajorAxisGeoKey (Double,1): 6378137
GeogInvFlatteningGeoKey (Double,1): 298.257223563
ProjectedCSTypeGeoKey (Short,1): User-Defined
PCSCitationGeoKey (Ascii,17): "LUnits = unknown"
ProjectionGeoKey (Short,1): User-Defined
ProjCoordTransGeoKey (Short,1): CT_MillerCylindrical
ProjLinearUnitsGeoKey (Short,1): User-Defined
ProjLinearUnitSizeGeoKey (Double,1): 1000000
ProjFalseEastingGeoKey (Double,1): 0
ProjFalseNorthingGeoKey (Double,1): 0
ProjCenterLongGeoKey (Double,1): 0
ProjCenterLatGeoKey (Double,1): 0
End_Of_Keys.
End_Of_Geotiff.
Projection Method: CT_MillerCylindrical
ProjCenterLatGeoKey: 0.000000 ( 0d 0' 0.00"N)
ProjCenterLongGeoKey: 0.000000 ( 0d 0' 0.00"E)
ProjFalseEastingGeoKey: 0.000000 m
ProjFalseNorthingGeoKey: 0.000000 m
GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E)
Corner Coordinates:
Upper Left ( -20.015, -14.671) ( 0d 0' 0.65"W, 0d 0' 0.47"S)
Lower Left ( -20.015, 44.014) ( 0d 0' 0.65"W, 0d 0' 1.42"N)
Upper Right ( 0.000, -14.671) ( 0d 0' 0.00"E, 0d 0' 0.47"S)
Lower Right ( 0.000, 44.014) ( 0d 0' 0.00"E, 0d 0' 1.42"N)
Center ( -10.008, 14.671) ( 0d 0' 0.32"W, 0d 0' 0.47"N)
Thanks for your hard work on Debian!
Reid
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libgdal1 depends on:
ii libarmadillo3 1:3.2.3+dfsg-1
ii libc6 2.13-37
ii libcurl3-gnutls 7.26.0-1
ii libdap11 3.11.1-11
ii libdapclient3 3.11.1-11
ii libdapserver7 3.11.1-11
ii libepsilon0 0.9.1-2
ii libexpat1 2.1.0-1
ii libfreexl1 1.0.0b-1
ii libgcc1 1:4.7.2-4
ii libgeos-c1 3.3.3-1.1
ii libgif4 4.1.6-10
ii libhdf4-0-alt 4.2r4-13
ii libhdf5-7 [libhdf5-7] 1.8.8-9
ii libjasper1 1.900.1-13
ii libjpeg8 8d-1
ii libkml0 1.3.0~r863-4.1
ii liblzma5 5.1.1alpha+20120614-2
ii libmysqlclient18 5.5.28+dfsg-1
ii libnetcdfc7 1:4.1.3-6+b1
ii libodbc1 2.2.14p2-5
ii libogdi3.2 3.2.0~beta2-7
ii libpng12-0 1.2.49-1
ii libpoppler19 0.18.4-3
ii libpq5 9.1.6-1
ii libproj0 4.7.0-2
ii libspatialite3 3.0.0~beta20110817-3
ii libsqlite3-0 3.7.13-1
ii libstdc++6 4.7.2-4
ii liburiparser1 0.7.5-1
ii libxerces-c28 2.8.0+deb1-3
ii odbcinst1debian2 2.2.14p2-5
ii zlib1g 1:1.2.7.dfsg-13
Versions of packages libgdal1 recommends:
ii proj-bin 4.7.0-2
libgdal1 suggests no packages.
-- no debconf information
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.tif
Type: image/tiff
Size: 1365 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-grass-devel/attachments/20121203/b06ab424/attachment.tif>
More information about the Pkg-grass-devel
mailing list