2

I have a raster with bathymetry data and need to add 0.6 value to each cell. The operation itself is simple - I just use raster calculator to add the value using following expression: bathymetry@1+0.6. The calculation runs successfully and at a first glance, everything is OK.

However, when I looked closely, it seems that the raster has been shifted on x and y axis, by approximately 0.2m, this value however varies.It looks like this (green is the raster raised by 0.6, gray is the source one):

enter image description here

So the question is, why does this happen? And also, how to avoid it?

@EDIT: I've noticed that this happens for any rasters that are in WGS84 CRS (EPSG 4326). When I carry out the same operation on layers in local, meter-based coordinate systems, everything is fine.

I'm using QGIS 3.14.3 and Windows 10.

Improve this question
3
  • You should also say which operating system (Windows, Linux, Mac) and the version of QGIS (2.x, 3.x) you are using.
    – xunilk
    Commented Feb 11, 2020 at 12:48
  • Have you tried processing an adjacent raster? Do both the outputs align? Is this behavior stopping you from working further?
    – Gabriel
    Commented Feb 11, 2020 at 15:41
  • It's not stopping me, that kind of slight mismatch is acceptable, however I'm very curious on why does this happen in the first place. And yes, I've tried processing other rasters from the same data source in the same CRS, and this "error" happens in all of them.
    – Pawel
    Commented Feb 11, 2020 at 15:44

3 Answers 3

Reset to default
3

This sounds like the Raster Calculator's output extent, resolution, and CRS do not match your input layer's. QGIS is therefore carefully resampling the input layer to generate the output layer with the "wrong" lattice structure.

Make sure you invoke the the Raster Calculator with the input layer, in your case bathymetry, selected; not another layer with different parameters. Then in the Result layer part of the window (see pic attached, with my project rasters rather than yours, of course), hit the Selected Layer Extent button to make sure the extent and resolution match those of bathymetry (check them beforehand to make sure), and make sure the Output CRS is correct as well.

In general this is a feature, not a bug, since especially if your calculation includes multiple rasters with different extents, resolutions, and CRSes, you need to carefully decide which one should be the "model" for the output versus which ones should be sampled. The Result layer parameters get populated by QGIS before you specify that the calculation expression depends (only) on bathymetry, so it doesn't know what you intend!

enter image description here

Editing to add: Poster has clarified this is a constructed raster in EPSG:4326. In this instance, this seems to be a genuine bug in the unusual case of a raster in an unprojected CRS, at the edge of numerical significance of latitude/longitude. The poster has reconstructed his raster from the source in a different CRS. However, I'm keeping up this answer since I think it is quite likely to be helpful to future readers with raster calculation offset issues in more normal circumstances.

Improve this answer
7
  • Thank you for your answer, but as per my comment below, I've made sure that the CRS, extent, no. of columns and rows are the same.
    – Pawel
    Commented Feb 11, 2020 at 15:12
  • Seems I was typing my (similar but not quite identical) answer at the same time as Matthew. If mine doesn't work either, suggest you double check the properties of both layers in Layer Properties or with gdalinfo. Are the extents, sizes, and CRSes of the output identical with the input, and what you specified in the dialog?
    – Houska
    Commented Feb 11, 2020 at 15:14
  • I've just edited my question as I noticed that this "error" happens only while working on data in EPSG:4326. I've also compared the raster infos, and there is a slight change in pixel sizes - 4.500000000000015869e-05,-4.500000000000013158e-05 in the original vs 4.499999999999998251e-05,-4.500036245016335058e-05. However, both extent and column/row numbers are the same.
    – Pawel
    Commented Feb 11, 2020 at 15:25
  • @Pawel, do you need to be working in EPSG:4326? The numbers you give imply your ground resolution is about 5m (111699m = 1 deg latitude), and it seems unlikely such a raster was created natively specified in (unprojected) lat/long. If the problem does not arise in projected CRS, maybe project and do the analysis there? (In EPSG:3857 if downloaded from a tiling). Then maybe open an issue at github.com/qgis/QGIS/issues since feels like a bug due to rounding, even if 4326 rasters likely pretty exceptional!
    – Houska
    Commented Feb 11, 2020 at 18:19
  • Thanks @Houska for your answer. The point is, I cannot reproject the data due to that fact that this will introduce even more errors. To be honest this question is asked more out of my curiosity. I have the point cloud for this data, so I can reproject that and create a raster.
    – Pawel
    Commented Feb 12, 2020 at 9:59
1

When you are using the Raster Calculator tool, make sure you are setting the Cell size, Output extent, and Output CRS to the same as the reference layer. If you are unsure of the cell size of the reference layer, you can leave that blank, but make sure to set the other two settings to the same as the reference layer. This should provide you a 1:1 match between the source and output.

Improve this answer
1
  • All of the parameters you mentioned are set to the same values as in the source layer. Still, the result is not an ideal match.
    – Pawel
    Commented Feb 11, 2020 at 15:06
0

While I can't test or verify without information on how the original data was processed, my guess is that there are default CRS values that differ slightly in QGIS from the software where your original raster was created.

I've had issues between FME and ArcGIS before where reprojections of the same data using the same settings yielded very slightly mismatched results - a few centimeters. I remember in that case that I saw a difference in significant numbers for the ellipsoid's semi-axis values and guessed it came from there.

Improve this answer
2
  • Did you do anything to mitigate the difference, or did you just proceed?
    – Pawel
    Commented Feb 11, 2020 at 16:10
  • I reran the entire pipeline for the data we had received from an external agency (they worked with FME) in ArcGIS because I was working on vector networks and snapping between datasets was essential. If misalignment in your case is not critical, it might be better to ignore it. But I don't know what your specific case is like.
    – Gabriel
    Commented Feb 11, 2020 at 16:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.