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

pixel values beyond valid range in QGIS #21309

Closed
qgib opened this issue Aug 20, 2015 · 5 comments
Closed

pixel values beyond valid range in QGIS #21309

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

Comments

@qgib
Copy link
Contributor

qgib commented Aug 20, 2015

Author Name: Ali Yagci (Ali Yagci)
Original Redmine Issue: 13248
Affected QGIS version: 2.8.1
Redmine category:rasters

please see here, http://gis.stackexchange.com/questions/158949/pixel-values-beyond-valid-range-in-qgis/159013#159013
You can download the file and recreate the issue yourself.
@qgib
Copy link
Contributor Author

qgib commented Aug 20, 2015

Author Name: Andre Joost (Andre Joost)

The problem is whether the scale factor has to be multiplied (as written in the HDF5 doc and done by QGIS) or divided (as assumed by the files producer).

@qgib
Copy link
Contributor Author

qgib commented Aug 21, 2015 •
edited

Author Name: Andre Joost (Andre Joost)

Maybe related to the patch in #17186

Strangely, a scale_factor value in the metadata is not used, if the file has been converted from netcdf to geotiff (and not by gdalwarp during the reprojection).

@qgib
Copy link
Contributor Author

qgib commented Aug 21, 2015

Author Name: Ali Yagci (Ali Yagci)

QGIS should not worry about the scale factor. It is not QGIS job. Users can do this operation on their own. For example, ArcMap is not involved in scale factor correction.

@qgib
Copy link
Contributor Author

qgib commented Jul 3, 2016

Author Name: Jürgen Fischer (@jef-n)

  • category_id was changed from Browser to Rasters

@qgib
Copy link
Contributor Author

qgib commented Jul 4, 2016

Author Name: Nyall Dawson (@nyalldawson)

This is a "won't fix" from me. The source data has a scale factor set, so we respect that.

  • resolution was changed from to wontfix
  • status_id was changed from Open to Closed

@qgib qgib added Bug Either a bug report, or a bug fix. Let's hope for the latter! High Priority Rasters Related to general raster layer handling (not specific data formats) labels May 25, 2019
@qgib qgib closed this as completed May 25, 2019
troopa81 pushed a commit to troopa81/QGIS that referenced this issue Jun 24, 2019
@signedav
use scale and mapUnitsPerPixel from map parameters bbox and size. in …
9552777 
…case bbox and size is given in the GetLegendGraphics request, the size of symbols defined by map units is calculated regarding the scale of that.

calculate mMmPerMapUnit with mapUnitsPerPixel to avoid to have redundant info
fixes qgis#21309

(cherry-picked from a04f91b 7de50a0 3e86163)
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! High Priority 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