Raster Calculator improvement in handling nodata values

[cesarcorreo]

New feature request I propose to improve the raster calculator to sum (operate) several raster layers that they don't have the same extension (but necessary to have the same pixel size?).

I am trying to sum several raster layers that are values of ground settlements from various tunnels. The rasters are like a worms in a city and different between them but in some areas some of them intersect with other worms.
The objective is to SUM these worms. The value of the ground settlements is the sum of the areas where the worm intersects with another worm, while in the areas where there is no intersection, the original value is maintained or null (0) if there is no worm. The problem is that if the files dont have the same extension, the calculator does not work.

How to Reproduce I will send the files to the person who reviews the case. Cannot be shared publicly

QGIS and OS versions I checked in several versions of the program. QGIS version 3.14.0-Pi QGIS code revision 9f7028fd23 Compiled against Qt 5.11.2 Running against Qt 5.11.2 Compiled against GDAL/OGR 3.0.4 Running against GDAL/OGR 3.0.4 Compiled against GEOS 3.8.1-CAPI-1.13.3 Running against GEOS 3.8.1-CAPI-1.13.3 Compiled against SQLite 3.29.0 Running against SQLite 3.29.0 PostgreSQL Client Version 11.5 SpatiaLite Version 4.3.0 QWT Version 6.1.3 QScintilla2 Version 2.10.8 Compiled against PROJ 6.3.2 Running against PROJ Rel. 6.3.2, May 1st, 2020 OS Version Windows 10 (10.0) Active python plugins ale; AnotherDXF2Shape; autoSaver; ClosestPoint; contour; DataPlotly; dimensioning; dimensions_selector; EasyCustomLabeling; FeatureGridCreator; freehandEditing3; gdrive_provider; geoscience; GroupStats; HCMGIS; ImportPhotos; kmltools; KP_find; LAStools; latlontools; lines_around_point; LocatePoints; mapswipetool_plugin; MBTiles2img; Mergin; mmqgis; NNJoin; OSMDownloader; PluginLoadTimes; pointsamplingtool; polystrip; profiletool; qchainage; Qgis2threejs; qgis2web; qgiscloud; QGISSortAndNumber-master; qgis_resource_sharing; qProf; QuickOSM; quick_map_services; rasterstats; refFunctions; searchlayers; SelectWithin; SpreadsheetLayers; SRTM-Downloader; StreetView; SuperLabeling; TopoUSM-QGIS-master; valuetool; zoomtopaste; db_manager; MetaSearch; processing

Additional context Currently, you need to do some steps to prepare the raster layer to operate between them if they dont have the same extension. Could be an option in raster calculator to analyze the maximum extent of all layers to do the operation. In other programs like Global Mapper you can do the sum with no other adaptation saving time and avoiding mistakes.

Screenshots: 1: Tunnels layout. Raster values only around the lines (60 m wide) 2: Detailed intersection of the tunnels 3: Layers to be sum and wrong result of the sum 4: Sum of the raster layers done with Global Mapper (only selecting layers and sum it; no more intermediate steps needed. 5: X,Y max and Min default and modified (several attemps done) 6: Proposal of the feature request Thanks

[gioman]

the original value is maintained

@cesarcorreo what is the original pixel value in areas where these lines do not cross? if it is NULL then you are getting the expected results because in a raster calc operation if you sum/multiply/divide/whatever two rasters, and one of them has a NULL pixel, then in the result/output that pixel will be NULL.

[cesarcorreo]

That's the reason I don't know if consider it as a bug or a feature request. In the screenshot: A: Only values in red worm. B: Only values blue worm. C: A+B D: No values (NULL) in red or blue. Should be a background process (to automatically change null vallues values to 0) or algorithm that let sum the raster layers as proposed to avoid several "preparing" operations like widening several layers, cut all of them to the same extension and finally perform the sum. I did it in Global Mapper with no previous adaptations.

[gioman]

@cesarcorreo it is certainly not a bug, this is how map algebra works. Please rephrase your title and description to make them more suitable for a feature request.

[cesarcorreo]

Ok. Thanks

[root676]

@cesarcorreo you can also try to sum rasters with the new Cell statistics algorithm. This one is currently only available in the nightly builds (you can easily obtain them for windows with the OSGEO4W64 installer). The Cell statistics algorithm has also some functionality to deal with NoData cells. Maybe this helps.

[gioman]

@cesarcorreo also the tools in the Processing toolbox all work also in batch mode, so preparing your raster inputs (even if they are a lot) is not an hard task.

[cesarcorreo]

Thanks both for your answers and suggestions. root676, I have just updated my nightly builds to use the Cell statistics algorithm and it's almost perfect. The only little upgrade that I suggest is when the algorithm asked for the reference layer. I cannot use one of the calculous one because the calculous one doesn't cover all the extension so I first create another raster layer with a higher extension covering al the others (with create constant raster layer) to use it as a reference layer.

In my opinion, this option should be included in raster calculator but if you consider that the feature request should be closed it's ok to me.

The screenshot shows the comparative between the raster sum generated with Global Mapper and the new one generated with Cell Statistics.

Thanks again

[gioman]

In my opinion, this option should be included in raster calculator but if you consider that the feature request should be closed it's ok to me.

@cesarcorreo if you change/adapt the title and description we can leave this open of course.

[cesarcorreo]

Done

[baswein]

I have often come across this limitation and would like to see this as a possibility. Here are some related links in case they are helpful to someone: https://github.com/qgis/QGIS/issues/31263#issue-481078805 http://osgeo-org.1560.x6.nabble.com/nodata-and-raster-calc-td5394658.html https://numpy.org/doc/stable/reference/generated/numpy.nan_to_num.html

[github-actions[bot]]

The QGIS project highly values your report and would love to see it addressed. However, this issue has been left in feedback mode for the last 14 days and is being automatically marked as "stale". If you would like to continue with this issue, please provide any missing information or answer any open questions. If you could resolve the issue yourself meanwhile, please leave a note for future readers with the same problem and close the issue. In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this issue. If there is no further activity on this issue, it will be closed in a week.

[AlisterH]

It might be a departure from the sort of things implemented in other software (e.g. https://grass.osgeo.org/grass84/manuals/r.mapcalc.html), but it seems to me that for most purposes an equivalent of the coalesce() function, would be most useful - it would do the same thing as r.patch, but in the raster calculator it would also allow you to patch a layer and a number e.g. 0.