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
