FWIW, I submitted the following bug report to SuSE :
https://bugzilla.novell.com/show_bug.cgi?id=876241
-Pierre.
On 03/05/2014 14:06, Pierre Baldensperger wrote:
>
> 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
