Update : just downloaded and compiled the newest GDAL (1.11.0) from
source. As you expected, the problem magically went away and the
projection in my SRTM files is recognized again by "gdalinfo".
I subsequently recompiled QLGT 1.7.6 from source against this new GDAL
and now everything works perfectly.
I think I should report this problem to the OpenSuSE GDAL maintainer.
The whole process took me less than 30 min : I can't believe I spent the
last 4 months with this problem, just too lazy to try this most simple
solution.
I tested that I can also (again) generate valid DEM GeoTIFF files with
this GDAL version. By the way I just discovered that the "Viewfinder
Panorama" website offers 1 arc-second resolution SRTM files for the
larger Alps area and they are gorgeous (detail is really significantly
improved vs. the 3 arc-second data I was using previously).
Thanks again Oliver for the good advice.
-Pierre.
On 03/05/2014 11:57, Pierre Baldensperger wrote:
> Hi Oliver,
>
> Sorry my initial message was a bit lengthy and confusing. Actually I
> said that the Linux "gdalinfo" (version 1.10.1) fails to recognize the
> projection because it does not show that information at all, regardless
> of adding the "-proj4" switch or not.
>
> But the Windows "gdalinfo" (version 1.8.0 bundled with QLGT) reports the
> projection information OK (just not formatted as a "PROJ.4" string
> because this was not implemented in that version, but otherwise the
> projection parameters seem to be all there : "Mercator" etc.).
>
> Looking closer at the "gdalinfo" outputs, I noticed that the newer
> version (1.10.1) reports a "LOCAL_CS" (with subsequent mention of WGS84)
> versus the older version (1.8.0) reports a "PROJCS" (with subsequent
> mention of the Mercator projection). This may be where the bad things
> happen but I have no idea what is causing this behaviour.
>
> I have just rebuilt an SRTM GeoTIFF using the newer OpenSuSE GDAL tools
> and the resulting file is again missing the projection information (and
> this time under Windows as well so the new TIFF is completely useless).
>
> I think the problem definitely originates on the GDAL side and has
> probably nothing to do with QLGT at all. I'll try to follow your advice
> and compile my own GDAL later to see if that solves anything.
>
> Thanks a lot for your help,
> -Pierre.
>
>
>
> On 03/05/2014 08:37, Oliver Eichler wrote:
>> Hi Pierre
>>
>> I just reread your inintial mail to find the part where you say that
>> gdalinfo failes to recognize the projection. You mean the missing
>> -proj4 switch? That is of no concern. As long as gdalinfo gives you
>> the lengthy hirachical projection information everything should be
>> ok.
>>
>> The GDAL library consits of a lot of libs and information that are
>> loaded at runtime if needed. If version missmatches do not
>> neccessarily result in a crash. Before I would start to reprocess all
>> my DEM data I would first try to make sure it nit GDAL. GDAL compiles
>> much faster than it processes my files :)
>>
>> Of course data corruption can always be a reason, too. But if I
>> understand you correctly the same file works on windows.
>>
>> HTH
>>
>> Oliver
>>
>>> Thanks a lot Oliver for the quick reply!
>>>
>>> Not sure I understand though : could you explain more precisely
>>> where you suspect there may be a binary mismatch ?
>>>
>>> As I said, even the standalone utility "gdalinfo" (completely
>>> outside of QLGT) apparently fails to recognize the projection of my SRTM
>>> GeoTIFF, so it does not look like the mismatch is between QLGT and GDAL.
>>> Maybe between GDAL and PROJ then ?
>>>
>>> If I can further narrow it down, I'll definitely report this
>>> problem to SuSE.
>>>
>>> But as you suggest, I'll probably end up compiling my own version
>>> manually. I've just been lazy but now I'm desperately missing my
>>> elevation data.
>>>
>>> Thanks,
>>> -Pierre.
>>>
>>> On 02/05/2014 22:23, Oliver Eichler wrote:
>>>> Hi Pierre
>>>>
>>>> I still use the DEM data I created several years ago. Thus I
>>>> doubt it's
>>>> a data format problem. It's very likely that it's a binary
>>>> missmatch of
>>>> the GDAL version. And that has to be reported as a bug to SuSE.
>>>>
>>>> Of course I always use the latest versions of the libraries
>>>> because I
>>>> compile everything on my own. That might be a short term
>>>> soulution for
>>>> you, too.
>>>>
>>>> The projection error message is always a bit tricky. There are
>>>> several
>>>> ways to define one and the same projection with a different
>>>> projection
>>>> string. And even GDALs internal compare tends to fail. Thus if
>>>> you are
>>>> sure that the projection should be ok simply ignore the message.
>>>>
>>>> HTH
>>>>
>>>> Oliver
>>>>
>>>>> 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
