Hello QLandkarteGT users,
I am a long time very happy user of this wonderful software tool and I
am most thankful to the developers of this gem for their excellent work.
I just registered to this list because, for the last few months (since
January or so), I have been bumping on the same weird problem with
loading an SRTM DEM on the OpenSuSE 13.1 version. Apparently the problem
appeared after upgrading from OpenSuSE 12.2 to 13.1 but it may be a
simple coincidence (and the simultaneous upgrade from QLGT 1.7.4 to 1.7.6).
More specifically, this is with QLGT version 1.7.6 x86_64 regularly
updated from the Application:Geo repository (on "OpenSuSE Build
Service"). FWIW, it uses Qt 4.8.5, GDAL 1.10.1 and PROJ 4.8.0.
I usually always use the same tiled SRTM GeoTIFF DEM file that I created
about 2 years ago following the instructions in the FAQ (don't remember
what GDAL/PROJ versions it was back then). This file has always worked
fine previously (albeit with a harmless warning about projection not
matching map) and still does load and map elevations perfectly on the
Windows version ("1.7.6.post" which uses Qt 4.8.4, GDAL 1.8.0 and PROJ
4.7.0).
Currently, I assume that I may have a problem with the newer GDAL
version on Linux. Unfortunately, I found no repository with older
versions to revert back to 1.8.0. So I wanted to know whether I am alone
with this problem or is anybody else also using this GDAL version
(1.10.1) and also experiencing the same kind of problem with loading DEMs ?
Some further details :
Under Linux, whenever I try to load the DEM file, I get the (usually
harmless) warning about the DEM projection not matching the current map,
except that the DEM projection string reported in the message box is
empty (while under Windows there is indeed a non-empty projection string
reported in the dialog).
I found out that my Linux "gdalinfo" has a "-proj4" switch to extract
that projection string from the file, so I tried to run it on the
command line and the reported projection string was indeed empty :
==BEGIN TRANSCRIPT========================================
> gdalinfo -proj4 srtm.tif
Driver: GTiff/GeoTIFF
Files: srtm.tif
Size is 11826, 11816
Coordinate System is:
LOCAL_CS["unnamed",
GEOGCS["unnamed ellipse",
DATUM["unknown",
SPHEROID["unnamed",6378137,0],
TOWGS84[3.458459520888726e-323,0,0,0,0,1,0]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
UNIT["metre",1]]
PROJ.4 string is:
''
Origin = (-46.383121164097140,6800200.793425155803561)
Pixel Size = (112.966288047500555,-112.966288047500555)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
COMPRESSION=DEFLATE
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( -46.383, 6800200.793)
Lower Left ( -46.383, 5465391.134)
Upper Right ( 1335892.939, 6800200.793)
Lower Right ( 1335892.939, 5465391.134)
Center ( 667923.278, 6132795.964)
Band 1 Block=256x256 Type=Int16, ColorInterp=Gray
==END TRANSCRIPT========================================
Unfortunately, the GDAL version 1.8.0 bundled with QLGT for Windows does
not yet provide this "-proj4" switch (was introduced in version 1.9
apparently) but the projection information seems to be reported anyway
(just not as a PROJ.4 string). Otherwise, the output of "gdalinfo" under
Windows is fairly consistent with the above (except the "TOWGS84" line
and the non-empty projection information) :
==BEGIN TRANSCRIPT========================================
C:\>gdalinfo srtm.tif
Driver: GTiff/GeoTIFF
Files: srtm.tif
Size is 11826, 11816
Coordinate System is:
PROJCS["unnamed",
GEOGCS["unnamed ellipse",
DATUM["unknown",
SPHEROID["unnamed",6378137,0]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Mercator_1SP"],
PARAMETER["central_meridian",0],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]]]
Origin = (-46.383121164097140,6800200.793425155800000)
Pixel Size = (112.966288047500560,-112.966288047500560)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
COMPRESSION=DEFLATE
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( -46.383, 6800200.793) ( 0d 0' 1.50"W, 52d 0' 1.50"N)
Lower Left ( -46.383, 5465391.134) ( 0d 0' 1.50"W, 43d59'58.81"N)
Upper Right ( 1335892.939, 6800200.793) ( 12d 0' 1.91"E, 52d 0' 1.50"N)
Lower Right ( 1335892.939, 5465391.134) ( 12d 0' 1.91"E, 43d59'58.81"N)
Center ( 667923.278, 6132795.964) ( 6d 0' 0.20"E, 48d 9'20.50"N)
Band 1 Block=256x256 Type=Int16, ColorInterp=Gray
==END TRANSCRIPT========================================
Maybe I should simply try to regenerate my tiled GeoTIFF DEM with the
newer versions of the GDAL tools ?
Any help or insight on this matter will be highly appreciated,
Thanks in advance,
-Pierre.
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Qlandkartegt-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
