Bug report #12075

Misreading value from a .grd file created with MapInfo (Vertical Mapper)

Added by Olivier ATHIMON almost 10 years ago. Updated about 9 years ago.

Status:Closed
Priority:Severe/Regression
Assignee:-
Category:Rasters
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:up/downstream
Crashes QGIS or corrupts data:No Copied to github as #:20272

Description

When I read .grd MapInfo file (created with Vertical Mapper) with QGIS 2.0, it displays four bands.
The 3 first show the RGB values and the fourth gives the value of the matrix, namely the altitude to a vertical file.

Inside QGIS 2.7 and 2.6.1 (same problem inside 2.6.0, not tried with QGIS 2.2/2.4), 4th displayed value is changed...

In addition, when making calculations with this file (.grd) and another (for example, a tiff file) QGIS seems to use the real values (not displayed) of the GRID. Then, it gives a good result for calculation.

QGIS_pb_lecture_grd.png - Sample for same pixel (61.7 KB) Olivier ATHIMON, 2015-01-28 04:28 AM

QGIS_pb_lecture_grd.png (61.7 KB) Olivier ATHIMON, 2015-01-29 02:27 AM

MNT_Lidar_1m_Granges.zip (4.16 MB) Olivier ATHIMON, 2015-01-30 03:56 AM

Misreading_of_band_4_but_real_value_in_the_result_after_this_operation_with_raster_calculator_of_QGIS_until_2.6.1.jpg - this simple operation give another result that the interrogation button... The right value appear in GEOTIFF output with QGIS 2.2 to 2.6.1 (204 KB) Olivier ATHIMON, 2015-02-12 08:59 AM

Misreading_of_band_4_and_zero_value_in_the_result_after_this_operation_with_raster_calculator_of_QGIS_Master_2.7.jpg - this simple operation give another result that the interrogation button... All pixel have a zero value (WRONG value) with QGIS Master 2.7... (201 KB) Olivier ATHIMON, 2015-02-12 08:59 AM

History

#1 Updated by Olivier ATHIMON almost 10 years ago

  • File QGIS_pb_lecture_grd.png added
  • Target version changed from Future Release - Nice to have to Future Release - High Priority

Corruption...

QGIS don't show the real value of a pixel for grid named: "Northwood Numeric Grid Format .grd/.tab (*.grd *.GRD)", and used with MapInfo/Vertical Mapper.

When I open and read a .grd MapInfo file (created with Vertical Mapper) with QGIS 2.0 or QGIS 2.2, it displays four bands with the real value, not with the next version of QGIS...

The 3 first show the RGB values and the fourth gives the value of the matrix, namely the altitude to a vertical file.

Inside QGIS (2.7, 2.6.1, 2.6.0 and 2.4), 4th displayed value is a bad value, not the real value.

In addition, when making calculations with this file (.grd) and another (for example, a tiff file) QGIS seems to use the real values (not displayed) of the GRID. Then, it gives a good result for calculation... Not with the plugin "Profile Tool"...

#2 Updated by Giovanni Manghi almost 10 years ago

  • Status changed from Open to Feedback
  • Affected QGIS version changed from 2.6.1 to master

Could you please attach a sample dataset? thanks

#3 Updated by Olivier ATHIMON almost 10 years ago

I attached the sample dataset (used for the previous picture).

This morning, i have tried to open it with QGIS 2.6.1 under Debian (Linux)... I have the same problem when i show values with button for information/interrogation => bad value, not real value! I suppose it gives the same problem for calculation.

#4 Updated by Giovanni Manghi almost 10 years ago

  • Operating System deleted (Windows)
  • Status changed from Feedback to Open
  • Assignee deleted (Giovanni Manghi)
  • OS version deleted (Windows 7)

#5 Updated by Giovanni Manghi almost 10 years ago

  • Priority changed from Normal to Severe/Regression

#6 Updated by Martin Dobias almost 10 years ago

  • Status changed from Open to Feedback

Since QGIS 2.4 there is support for using band offset and scale as reported by GDAL. Indeed the band 4 has offset and scale defined:

$ gdalinfo /data/gis/tst-bug12075-band4/MNT_Lidar_1m_Granges.grd
[... omitted lines above ...]
Band 4 Block=2000x1 Type=Float32, ColorInterp=Undefined
  NoData Value=-9.99999993381581251e+36
  Offset: -6.38000011444092,   Scale:0.000509811698468156

So the reported values (e.g. -6.378) seems to be the correct - according to the band's offset/scale. Can we close the bug?

#7 Updated by Olivier ATHIMON almost 10 years ago

No... I am sorry. You can't close the bug.

I created a video with a query of a pixel with MapInfo 6.5/Vertical Mapper, MapInfo 12, QGIS 2.2 Valmiera, QGIS 2.6.1 Brighton and QGIS 2.7.0.94 (QGIS b35a596) to show you more the problem...

https://www.youtube.com/watch?v=hnIbBdfcWLI&feature=youtu.be

I rewrite the text, shown in the video:

"the grid: MNT_Lidar_1m_Granges.grd (associated with MNT_Lidar_1m_Granges.tab)

1- Open the grid with MapInfo (version 6.5, a very old version) / Vertical Mapper.
Query a pixel in the same area <=> when Mapinfo read a pixel, it create an interpolation of the pixel around. So, if you are not exactly in the center, the value change a little but it is the real value.

2- Open the grid with MapInfo (version 12, a recent version), without Vertical Mapper
Query a pixel in the same area. You have too an interpolation value (real value)

3- Open the grid with QGIS 2.2.0 - Valmiera
Query a pixel in the same area <=> it is the real value (viewed too in GRASS GIS)
Use Grid Calculator, select band 4 and save it in GeoTiff.
Query a pixel in the same area <=> it is the real value

4- Open the grid with QGIS 2.6.1 - Brighton
Query a pixel in the same area <=> it is a bad value!
Use Grid Calculator, select band 4 and save it in GeoTiff.
Query a pixel in the same area <=> it is the real value

5- Open the grid with QGIS 2.7.0-94 (Master)
Query a pixel in the same area <=> it is a bad value!

Use Grid Calculator, select band 4 and save it in GeoTiff.
Query a pixel in the same area... => It is a NEW PROBLEM... Just 0 value...??? I am sorry...

Use "Saveas" in Raw Data (not image) => It is a bad value... from grd file
Or it is a 0 value from Geotiff created with grid calculator before...

Now, i hope that you understand the problem...

Thanks for your job.

QGIS is great!

#8 Updated by Olivier ATHIMON almost 10 years ago

Hello,

I don't know if you have seen the previous video, but i put another here:

https://www.youtube.com/watch?v=ZCMV3PyfBc0

to show you the (same) problem with Raster Calculator to do the simple operation to "export" the band 4: "QGIS change the values" of the GEOTIFF result...

In reality, QGIS put the RIGHT values in the OUTPUT file (GEOTIFF), where the query button gives a WRONG value (for the input GRD File / Northwood Numeric Grid Format with QGIS from 2.4 to 2.7)...

Except for QGIS Master 2.7, this one give 0 value (and wrong value) all over... <= NEW PROBLEM...

I add 2 pics of the simple operation realized with the raster calculator...
One (for QGIS until 2.6.1) gives the RIGHT VALUES in the result.
The other (for QGIS Master 2.7) gives 0 VALUES (WRONG VALUES) all over...

Precision: everything was working with QGIS version 2.2... No misreading (with query button), and good result with raster calculator to save band 4 to a GEOTIFF file. The right value before (in the grd file) and after (in the GEOTIFF/.tiff file)

Hope that you will find a solution...

#9 Updated by Martin Dobias almost 10 years ago

  • Status changed from Feedback to Open

Then it looks like a bug in GDAL library - I have reported it here: GDAL #5839

#10 Updated by Giovanni Manghi almost 10 years ago

Martin Dobias wrote:

Then it looks like a bug in GDAL library - I have reported it here: http://trac.osgeo.org/gdal/ticket/5839

then closing this as upstream?

#11 Updated by Martin Dobias almost 10 years ago

  • Resolution set to up/downstream
  • Status changed from Open to Closed

Fixed in upstream (both GDAL trunk and 1.11 branch)

#12 Updated by Olivier ATHIMON over 9 years ago

  • Status changed from Closed to Reopened

With a raster dataname: "MNT.grd" with 4 bands (band1 : Red, band2: Green, band3: Blue, band4: altimetry)...

It had been found that the problem was with the version of GDAL 1.11 ... Ewen Rouault (from GDAL) had after making changes to the GDAL library in Version 1.11.3... [[http://trac.osgeo.org/gdal/ticket/5839]]

However, now, I have a doubt (though QGIS integrates GDAL 1.11.2 release)... Indeed, QGIS has seen other changes...

Version 2.8 is the successor to version 2.6 with the same problem (read error but problem solved by writing to the raster calculator by exporting the result of the expression: "MNT@4" in GeoTIFF format)...

In version 2.8 of QGIS, the GDAL library was 1.11.2 release. It is also present in version 2.10.

But now, reading and writing of "MNT@4" in size Geotiff give the same result, a false result in the two cases...

I'll wait for version 2.12 (QGIS) that could possibly incorporate version 2 of the GDAL library ... but I have a doubt, however, that I consider useful to trace... If you ever want to check it.

#13 Updated by Olivier ATHIMON about 9 years ago

  • Target version deleted (Future Release - High Priority)
  • Status changed from Reopened to Closed
  • Assignee deleted (Martin Dobias)
  • % Done changed from 0 to 100

With the update of Gdal (in version 1.11.3), the data are effectively OK in QGIS 2.8.3, QGIS 2.10 and QGIS 2.11 (91e1554 for the future QGIS 2.12)...
Thanks at all.

Also available in: Atom PDF