This project is read-only.

Can somebody explain perceived raster extent shifts?

Feb 6, 2012 at 2:11 AM
Edited Feb 9, 2012 at 7:34 PM

Hi all, I may have ran into a conceptual bug in DotSpatial raster handling. When I load or create a raster, DotSpatial reports shifted raster bounds which I do not expect. Is this by design?

For instance, I want to create a 4x4 raster that envelopes X[0,10] to Y[0|5]. I would presume that the following deadly simple code would do the trick:

Raster<float> rs = new Raster<float>(4, 4);
rs.Bounds = new RasterBounds(rs.NumRows, rs.NumColumns, new Extent(0, 0, 10, 5));

However, the raster now reports an extent of X[-1.25|8.75], Y[0.625|5.625]

This has all kinds of implications. Rasters with different cell sizes do not align, tools from the analysis namespace operate on shifted bounds, etc.

Is this behaviour by design? Am I missing something?

Thanks in advance,

Feb 6, 2012 at 10:20 PM

Addition: the following delightful loop illustrates the problem well:

Console.WriteLine("Start: {0}", ext.ToString);
for (int i = 0; i < 100; i++) {
	rs.Bounds = new RasterBounds(rs.NumRows, rs.NumColumns, rs.Extent);
	Console.WriteLine("{0:000}: {1} ", i, rs.Extent.ToString());
Feb 7, 2012 at 7:49 PM

carosoisu verified that the default behavior is different in other GIS products. I think the project coordinators should indicate whether this is by design.

Feb 7, 2012 at 9:04 PM

Interesting discovery. Thanks for finding this. It seems that an unnecessary shift is indeed occurring. I am fairly certain that this is NOT by design or at least is not intuitive enough to keep as our default behavior. - Dan

Feb 7, 2012 at 9:48 PM
Edited Feb 9, 2012 at 2:57 AM

I dug deeper. When RasterBounds is asked for an extent, it internally reconstructs this from its Left, Top, Right and Bottom properties. Underneath, these properties use X, Y, Width and Height, which in turn are computed from affine coordinates.

The affine coordinates are set correctly, so far so good, but I may have found four potential bugs when affine coordinates are read and interpreted:

  1. Width and Height calculations seem correct (I only tested rasters that were not transformed), but according to code comments RasterBounds.X and Y deliberately aim to return the centroid of a cell. This was my original confusion; centroids should not be used to recreate the outer Extent of a raster.

  2. The X and Y centroid assumptions are not consistently implemented throughout RasterBoundsEx. RasterBoundsEx.Top and .Left are derived from X and Y, but TopLeft, BottomLeft or TopRight and BottomRight bypass X and Y and are directly computed from the Affine coordinates. This is inconsistent; for instance RasterBounds.Top and RasterBounds.TopLeft.Y now return different values. Try it.

  3. Although TopLeft, BottomLeft, TopRight and BottomRight directly compute from the affine coordinates they do not take transformations into account which could cause other problems.

  4. Lastly, the implementation of X and Y centroid calculations return the centroid of cell (-1, -1) instead of cell (0,0). Some simple + and - swapping solves this.

Seeing all this I propose the following changes (presuming that I indeed found bugs):

  • RasterBounds X and Y should be fine to return the centroid of a cell, but only for cell (0,0);
  • Left, Right, Top and Bottom should not refer to centroids but should instead refer to the outer bounds of the raster;
  • The outer Extent should be obtained from Left, Right, Top and Bottom and not from X and Y;
  • TopLeft, TopRight etc should consistently use Top, Left, Right, etc which will properly deal with any type of transformation
Apr 16, 2012 at 7:20 PM

Dear all,

Can anybody tell me if this issue will be addressed in a next release?


Dec 12, 2012 at 8:07 PM

Hi all,

it seems this issue is not fixed yet?

At the moment I'm using the following as a workaround to make sure the Extent of the Bounds is exactly what its supposed to be

Dim rBounds As RasterBounds = New RasterBounds(nrows, ncols, newExtent)
        rBounds.Extent = newExtent

Has anybody a better idea?

Thanks, Claudia

Feb 20, 2015 at 4:53 PM
Any news on that? I can see this problem when using the identify tool on raster cells: cells delineation do not match with cell value, the latter are shifted half cell to the right and half downward.

I rise this issue on that problem