Feature request #3649

Raster calculator should work on raster files in different CRS

Added by Tim Sutton about 13 years ago. Updated almost 9 years ago.

Status:Closed
Priority:Low
Assignee:Marco Hugentobler
Category:Rasters
Pull Request or Patch supplied: Resolution:
Easy fix?:No Copied to github as #:13708

Description

Take a simple raster e.g. a GeoTiff in UTM. Open the raster calculator and create a simple product based on that raster e.g.

raster@1 * 1

Save the output and load it. Look in the general properties of raster layer dialog. The CRS shown is 4326, but it does not show overlaid on LatLon data. Still in the general properties tab, assign the CRS manually to the original dataset's CRS. The raster now overlays properly with other datasets in in the projected CRS.

It would be great if the new raster calculator carried the CRS of the original dataset from which it derives.

Associated revisions

Revision 559d7bb9
Added by Nyall Dawson almost 9 years ago

[rastercalc] Rework raster calculator to use QGIS raster classes

...rather than reading input layers directly through GDAL.
Benefits include more robust handling of nodata/data type conversions,
less code duplication, also being able to take advantage of features
in QGIS raster code like handling gain/offset in rasters. (fix #12450)

Also, add a choice of output projection to the raster calculator.
Previously the output CRS would be taken from the first raster, with
no guarantees that the output extent matched the output CRS. This
resulted in empty/misplaced rasters. (fix #3649)

History

#1 Updated by Marco Hugentobler about 13 years ago

f1527c7f (SVN r15582) implements a solution where the crs is copied from the first layer involved in the calculation.
It however has two disadvantages:
- If there is a constant expression (e.g. '42'), the result has no CRS assigned. A solution could be to have a crs button in the dialog (but it is string freeze now).
- The CRS is passed to GDAL as WKT, and there can be some loss of information depending on the format. E.g. for GeoTiff, the doc says 'Note that the GeoTIFF format does not support parametric description of datums, so TOWGS84 parameters in coordinate systems are lost in GeoTIFF format'.

Let me know if there is a better approach to deal with this.

#2 Updated by Marco Hugentobler almost 13 years ago

implements a better solution by going over the epsg code and OGRSpatialReferenceH if it is an epsg projection. Like this, the projection is recognized better by QGIS.

For a perfect handling of CRS, the calculator should be ported to the new raster provider functions such that calculation can be done on rasters in different CRS. This is out of scope for 1.7, so I'm changing version and title of the ticket.

#3 Updated by Pirmin Kalberer over 11 years ago

  • Target version changed from Version 2.0.0 to Future Release - Nice to have

#4 Updated by Nyall Dawson almost 9 years ago

  • Status changed from Open to Closed

Also available in: Atom PDF