Opened 13 years ago
Last modified 6 years ago
#1640 new enhancement
r.in.gdal scale/offset not applied
Reported by: | alf | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 7.6.2 |
Component: | Raster | Version: | 6.4.2 |
Keywords: | r.in.gdal, scale, offset | Cc: | |
CPU: | Unspecified | Platform: | Linux |
Description
Hi,
r.in.gdal does not apply scale and offset specified as metadata (and correctly shown by gdalinfo) in the file to be imported.
Maybe it shoud/should not by default, but a specific flag might be advisable.
Best,
Alessandro
Change History (11)
comment:1 by , 13 years ago
Component: | Default → Raster |
---|---|
Keywords: | r.in.gdal scale offset added |
comment:2 by , 13 years ago
Milestone: | 6.4.3 → 7.0.0 |
---|---|
Type: | defect → enhancement |
comment:3 by , 8 years ago
Milestone: | 7.0.0 → 7.0.5 |
---|
comment:4 by , 8 years ago
Milestone: | 7.0.5 → 7.3.0 |
---|
comment:6 by , 8 years ago
Hello,
specifying scale and offset directly in r.in.gdal would be helpful for Proba-V NDVI Data too. So you wouldn't have to use the r.mapcalc tool after the import.
Maybe it's a good reason to start this topic again :)
kind regards,
Jonas
comment:8 by , 6 years ago
Milestone: | 7.4.1 → 7.4.2 |
---|
comment:9 by , 6 years ago
Milestone: | 7.4.2 → 7.6.0 |
---|
All enhancement tickets should be assigned to 7.6 milestone.
Note:
See TracTickets
for help on using tickets.
Hi,
afaik they are non-standard extensions and just treated as plain-text metadata by GDAL. heuristics might be possible (albeit fragile), but perhaps not advisable to apply them by default. (e.g. makes filtering out transformed non-NULL no-data values a bit more difficult)
for examples of semi-automatic transforms see:
and exponential flavour: (where Slope and Intercept are present but not y=mx+b)
Hamish