Spatially consistency between 2 Raster layers

[ma15569]

Check if the RasteImageLayer is spatially consistent with another: a) both have the same cell size
b) both have the same dimension (same width and height) c) both overlap to each other into the geographic space Usefull for ovelapping processes between two raster iamge layers

[jratike80]

Does it also check that the pixels are aligned? I mean that if the pixels have also a common origin in addition to same pixel size so that they overlap exactly? Compare the -tap option in gdalwarp https://gdal.org/programs/gdalwarp.html#cmdoption-gdalwarp-tap.

[ma15569]

Hi Jukka, I was thinking about. Technically yes: the check verifies the following conditions between two RasterImageLayers: TRUE if A) (geographic check) envelope1.minx/miny==envelope2.minx/mint where envelopes are the geographic extents of the two rasters B) (Raster1) number of columns and rows == (Raster2) number of columns and rows C) (Raster 1) cell size==(Raster 1) cell size. Which is enough for me to define the spatial coerence between two or more RasterImageLayers in order to apply operations of raster overlay, ex. the raster calculator in my raster tools or merging two or more raster. If the selected RasterImageLayers do not pass the check, Raster tools provides a specific plugin: "Resample to extension" to homologate them applying some interpolations (note that all this code was already in Openjump thanks to Stephan Stringer) Going back to your question and the question A=false, B=true, C=true define two raster which have the same size (cell size and num rows/cols) but geographically disallow. Technically it is enough A=false and B=true if no preparation of the rasters for raster algebra is required If you need a check like this I can add to the RasterImageLayer class Peppe Il dom 11 dic 2022, 12:11 Jukka Rahkonen ***@***.***> ha scritto:

…

Does it also check that the pixels are aligned? I mean that if the pixels have also a common origin in addition to same pixel size so that they overlap exactly? Compare the -tap option in gdalwarp https://gdal.org/programs/gdalwarp.html#cmdoption-gdalwarp-tap. — Reply to this email directly, view it on GitHub <#80 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSYPM3MJSC2RBOKPWNWUZLWMWZHZANCNFSM6AAAAAAS2YMRSM> . You are receiving this because you authored the thread. Message ID: ***@***.***>

[jratike80]

I do not need that kind of check myself. I was just remembering some troubles/worries that GDAL users have had when they have warped an image by using a clipping polygon. In that case GDAL by default is placing the origo to the (minx miny) of the envelope of the clipping geometry and that leads often to unaligned pixels. The -tap option is placing the pixels to match with a grid that begins from (0 0) in the CRS of the output.

If you think that that raster calculator works right if two images both have for example 100x100 pixels, with the same pixel size of 1x1 metre, but when one image has the origin at (0 0) and the other one at (0.3 0.2) then I think there is no need for this check.

[mukoki]

I think the 3 first tests (xmin, ymin, cellsize) can be replaced by :
if (! this.getWholeImageEnvelope().equals(rasterImageLayer.getWholeImageEnvelope()) {
return false;
}

[mukoki]

rasterImageLayer to follow more standard naming convention

[ma15569]

Hi Jukka,

In that case GDAL by default is placing the origo to the (minx miny) of

the envelope of the clipping geometry and that leads often to unaligned pixels. In my tests, clipping raster with polygon if my raster tools corrects the shift. Regarding Raster Calculator, it will not work if the rasters will not pass the check (same cellsize, same origin in the geographic space, same number of rows and columns). Sextante raster calculator is more flexible: you can do some raster algebra also between rasters which are not spatially consistent, resampling them. I prefer not to use this solution, even it seems more easy for users, as I wanted that making a group of raster consistent was a separate process where users could choose also the interpolation method. Il dom 11 dic 2022, 22:22 Jukka Rahkonen ***@***.***> ha scritto:

…

I do not need that kind of check myself. I was just remembering some troubles/worries that GDAL users have had when they have warped an image by using a clipping polygon. In that case GDAL by default is placing the origo to the (minx miny) of the envelope of the clipping geometry and that leads often to unaligned pixels. The -tap option is placing the pixels to match with a grid that begins from (0 0) in the CRS of the output. If you think that that raster calculator works right if two images both have for example 100x100 pixels, with the same pixel size of 1x1 metre, but when one image has the origin at (0 0) and the other one at (0.3 0.2) then I think there is no need for this check. — Reply to this email directly, view it on GitHub <#80 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSYPM4RNMNZ4AHGDYZVU73WMZA2FANCNFSM6AAAAAAS2YMRSM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ma15569]

Thanks Michael, I will correct the code according to your observation. Il dom 11 dic 2022, 23:13 Michaël Michaud ***@***.***> ha scritto:

…

***@***.**** commented on this pull request. ------------------------------ In src/org/openjump/core/rasterimage/RasterImageLayer.java <#80 (comment)>: > @@ -1580,4 +1580,31 @@ public String getFilePath() { // this.srsInfo = srs; //} + /** + * Check if the RasteImageLayer is spatially consistent with another: + * <li>both have the same cell size + * <li>both have the same dimension (same width and height) + * <li>both overlap to each other into the geographic space + * + * @param RasterImageLayer + * @return true if they are spatially consistent, false if they are not + */ + public boolean isSpatiallyConsistentWith(RasterImageLayer rasteimageLayer) { + if (this.getMetadata().getOriginalCellSize() != rasteimageLayer.getMetadata().getOriginalCellSize()) { I think the 3 first tests (xmin, ymin, cellsize) can be replaced by : if (! this.getWholeImageEnvelope().equals(rasterImageLayer.getWholeImageEnvelope()) { return false; } ------------------------------ In src/org/openjump/core/rasterimage/RasterImageLayer.java <#80 (comment)>: > @@ -1580,4 +1580,31 @@ public String getFilePath() { // this.srsInfo = srs; //} + /** + * Check if the RasteImageLayer is spatially consistent with another: + * <li>both have the same cell size + * <li>both have the same dimension (same width and height) + * <li>both overlap to each other into the geographic space + * + * @param RasterImageLayer + * @return true if they are spatially consistent, false if they are not + */ + public boolean isSpatiallyConsistentWith(RasterImageLayer rasteimageLayer) { rasterImageLayer to follow more standard naming convention — Reply to this email directly, view it on GitHub <#80 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSYPMZXSLCNRAK57SHQ7ETWMZGX3ANCNFSM6AAAAAAS2YMRSM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mukoki]

Looks good. Sorry for the delay.

[ma15569]

Thank Michael Il sab 11 mar 2023, 11:12 Michaël Michaud ***@***.***> ha scritto:

…

***@***.**** approved this pull request. Looks good. Sorry for the delay. — Reply to this email directly, view it on GitHub <#80 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSYPM3XFQ35I6LJGOYUVA3W3RF2NANCNFSM6AAAAAAS2YMRSM> . You are receiving this because you authored the thread.Message ID: ***@***.***>