I am working with a standalone app build with QGIS 2.8.1 on a CentOs7 machine. I got a new DTED data set which raises errors "somewhere" in the app. The app doesn't read the .dt? files directly, but as a VRT.

Even in debug mode this is all I get on the console:

Warning 1: Longitude count (195) of column 193 doesn't match expected value
Process finished with exit code 139.

Just for info:

  • About QGIS states: compiled with GDAL/OGR 1.11.1, running with GDAL/OGR 1.11.2; Python is running with gdal 1.11.2
  • other DTED files work perfectly, readed directly or as VRT
  • reading a single .dt? file works
  • both, VRT and individual .dt? files work in QGIS application
  • The columns may be different in each run, and there may be different counts of warnings

Unfortunately yesterday evening CentOs was proud to tell, that QGIS has successfully updated to the current version 2.8.3. But using this version, and after downgrading back to 2.8.1, there is no difference. I cannot state, if this error would have occur before updating, because I hadn't used the same DTED data before.

What is the reason for this GDAL error, which instructions will raise this exception, and why is the behaviour of the different components (VRT/direct reading, QGIS/QGIS components) so different?

  • Obviously the application believes that something is setting something to use longitude of 195 degrees in some place.You can have a look inside VRT and try to see invalid extents, and you can run gdalinfo for the vrt file. However, if QGIS is happy then perhaps the the bug is in the standalone app. How do you know that the error comes from GDAL? – user30184 Nov 18 '15 at 13:23
  • @user30184 This error message is printed to console while the application is running, after several zoom or pan actions, sometimes even before the app window is drawn. Therefore I don't know, what to debug. I found this message in a source from gdal dted_api.c in function DTEDReadProfileEx. Here Longitude does not mean geographical coordinate, but a counter of some DTED data records. If the file may be corrupted, why is QGIS itself displaying the files correctly (and btw other GIS as well), and my app stumples across displaying these files only? – Detlev Nov 18 '15 at 14:06
  • Right, the code is here trac.osgeo.org/gdal/browser/trunk/gdal/frmts/dted/…. It needs a GDAL specialist to help you and they would probably need to see your code. Could it be that because of using VRT, the expected nLongitudeCount have been detected in some earlier phase from another physical file? So when you pan the app still memories the count (195) even you have moved the viewport to another file? Does all the dt files have same number of rown and columns? – user30184 Nov 18 '15 at 15:06
  • First step towards a solution: according trac.osgeo.org/gdal/ticket/1716 by setting some environment variables DTED handling can be influenced (DTED_VERIFY_CHECKSUM, DTED_IGNORE_IMPOSSIBLE_CHECKSUM, DTED_BEHAVIOUR_WHEN_BAD_CHECKSUM). The app now reports the errors once, and goes on. But sooner or later it crashed with exit code 139. There are obviously some more tricks to get an app handle DTED files like QGIS. – Detlev Nov 18 '15 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.