Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
qgib opened this issue Jan 28, 2015 · 13 comments
Closed

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

qgib opened this issue Jan 28, 2015 · 13 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Rasters Related to general raster layer handling (not specific data formats)

Comments

@qgib
Copy link
Contributor

qgib commented Jan 28, 2015

Author Name: Olivier ATHIMON (Olivier ATHIMON)
Original Redmine Issue: 12075
Affected QGIS version: master
Redmine category:rasters

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.
@qgib
Copy link
Contributor Author

qgib commented Jan 29, 2015

Author Name: Olivier ATHIMON (Olivier ATHIMON)

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"...

  • 8344 was configured as QGIS_pb_lecture_grd.png
  • fixed_version_id was changed from Future Release - Nice to have to Future Release - High Priority

@qgib
Copy link
Contributor Author

qgib commented Jan 29, 2015

Author Name: Giovanni Manghi (@gioman)

Could you please attach a sample dataset? thanks

  • status_id was changed from Open to Feedback
  • version was changed from 2.6.1 to master

@qgib
Copy link
Contributor Author

qgib commented Jan 30, 2015

Author Name: Olivier ATHIMON (Olivier ATHIMON)

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.

  • assigned_to_id was configured as Giovanni Manghi
  • 8349 was configured as MNT_Lidar_1m_Granges.zip

@qgib
Copy link
Contributor Author

qgib commented Jan 30, 2015

Author Name: Giovanni Manghi (@gioman)

  • operating_system was changed from Windows to
  • status_id was changed from Feedback to Open
  • assigned_to_id removed Giovanni Manghi
  • os_version was changed from Windows 7 to

@qgib
Copy link
Contributor Author

qgib commented Jan 30, 2015

Author Name: Giovanni Manghi (@gioman)

  • priority_id was changed from Normal to Severe/Regression

@qgib
Copy link
Contributor Author

qgib commented Feb 9, 2015

Author Name: Martin Dobias (@wonder-sk)

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?

  • status_id was changed from Open to Feedback

@qgib
Copy link
Contributor Author

qgib commented Feb 10, 2015

Author Name: Olivier ATHIMON (Olivier ATHIMON)

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!

@qgib
Copy link
Contributor Author

qgib commented Feb 12, 2015

Author Name: Olivier ATHIMON (Olivier ATHIMON)

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...

  • 8416 was configured as Misreading_of_band_4_but_real_value_in_the_result_after_this_operation_with_raster_calculator_of_QGIS_until_2.6.1.jpg
  • 8417 was configured as Misreading_of_band_4_and_zero_value_in_the_result_after_this_operation_with_raster_calculator_of_QGIS_Master_2.7.jpg
  • assigned_to_id was configured as Martin Dobias

@qgib
Copy link
Contributor Author

qgib commented Feb 12, 2015 •
edited
Loading

Author Name: Martin Dobias (@wonder-sk)

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

  • status_id was changed from Feedback to Open

@qgib
Copy link
Contributor Author

qgib commented Feb 12, 2015

Author Name: Giovanni Manghi (@gioman)

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?

@qgib
Copy link
Contributor Author

qgib commented Feb 16, 2015

Author Name: Martin Dobias (@wonder-sk)

Fixed in upstream (both GDAL trunk and 1.11 branch)

  • resolution was changed from to up/downstream
  • status_id was changed from Open to Closed

@qgib
Copy link
Contributor Author

qgib commented Aug 20, 2015

Author Name: Olivier ATHIMON (Olivier ATHIMON)

+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.

  • status_id was changed from Closed to Reopened

@qgib
Copy link
Contributor Author

qgib commented Sep 27, 2015

Author Name: Olivier ATHIMON (Olivier ATHIMON)

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.

  • fixed_version_id removed Future Release - High Priority
  • status_id was changed from Reopened to Closed
  • assigned_to_id removed Martin Dobias
  • done_ratio was changed from 0 to 100

@qgib qgib added Bug Either a bug report, or a bug fix. Let's hope for the latter! Rasters Related to general raster layer handling (not specific data formats) labels May 25, 2019
@qgib qgib closed this as completed May 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Rasters Related to general raster layer handling (not specific data formats)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@qgib