Just to keep you posted... End of story : as you'll read in the bugzilla if you are interested, it was actually all my fault. I was using a previous (apparently incompatible) version of libgeotiff (from the "Packman" OpenSuSE repository).
Upgrading to the version of the "Application:Geo" repository fixes everything. QLandkarteGT works like a charm now. -Pierre. On 03/05/2014 16:23, Pierre Baldensperger wrote: > > 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
