Opened 13 years ago
Last modified 13 years ago
#3649 new enhancement
Raster calculator should work on raster files in different CRS
Reported by: | timlinux | Owned by: | mhugent |
---|---|---|---|
Priority: | critical: causes crash or data corruption | Milestone: | Version 2.0.0 |
Component: | Rasters | Version: | 1.6.0 |
Keywords: | Cc: | ||
Must Fix for Release: | No | Platform: | Debian |
Platform Version: | Awaiting user input: | no |
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.
Change History (2)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Milestone: | Version 1.7.0 → Version 2.0.0 |
---|---|
Summary: | Raster calculator does not assign projection correctly to output raster → Raster calculator should work on raster files in different CRS |
Type: | bug → enhancement |
r15815 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.
r15581 implements a solution where the crs is copied from the first layer involved in the calculation. It however has two disadvantages:
Let me know if there is a better approach to deal with this.