#2100: r.proj bounding box too small by half a cell size (-g or -p):
-------------------------+--------------------------------------------------
Reporter: awickert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: r.proj | Platform: Linux
Cpu: Unspecified |
-------------------------+--------------------------------------------------
When using r.proj in GRASS 7.0 (svn) going from one lat/lon location to
another (so just to move rasters without reprojecting), I have noticed
that the bounding box printed by entering "r.proj -g" or "r.proj -p"
extends a half-cell-size short of the size of the input raster map. I
interpret this to be that the bounding box is defining itself by the cell
centers rather than their edges, and am concerned that this bug may also
exist for performing real projections but would have remained unnoticed in
going from one coordinate system to another.
Please let me know if you would like me to submit more information and/or
help in fixing this in some way.
#2100: r.proj bounding box too small by half a cell size (-g or -p):
-------------------------+--------------------------------------------------
Reporter: awickert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: r.proj | Platform: Linux
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by awickert):
Replying to [comment:1 glynn]:
Thanks for the pointer towards bordwalk.c. Two thoughts:
(1) Reading the starting comments, it looks like this may in fact be
intentional to make sure that the region fits within the current region.
Indeed, when I tried to make changes to bordwalk.c, I found a reason to
believe that this was the case (below).
(2) However, this prevents the use of "-p" and "-g" to set the region of
the current location to match the region of the raster being projected.
This therefore means that the code as-is contradicts the help files, which
tell you to do this to ensure a good projection.
Therefore, I have attached a working diff that removes the parts that take
the bounding box a half-cell away from the cell margins... mostly. I have
not adjusted the for loops at all, which may need to be done for a real
fix, but was unnecessary for the test data set that I was using (48 cell
N-S x 96 cell E-W GCM outputs spanning the whole globe, so 90S to 90N and
180W to 180E). Also, I found that the output of the projection would
shrink to 2 cell widths (though still spanning the whole N-S range) if I
completely removed the western offset, so I just made that fairly small
for the time being; this may be a reason that the cell centers were used.
Anyway, this is only the second time I have done anything to the GRASS
source code, so I'd greatly appreciate what those of you more familiar
with this might have to say.
#2100: r.proj bounding box too small by half a cell size (-g or -p):
-------------------------+--------------------------------------------------
Reporter: awickert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: r.proj | Platform: Linux
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by glynn):
Replying to [comment:2 awickert]:
> Therefore, I have attached a working diff that removes the parts that
take the bounding box a half-cell away from the cell margins... mostly. I
have not adjusted the for loops at all,
The change moves the sample points from the cells' centres to the
midpoints of their edges. This generates the region's boundary but with
chamfered corners.
> Also, I found that the output of the projection would shrink to 2 cell
widths (though still spanning the whole N-S range) if I completely removed
the western offset, so I just made that fairly small for the time being;
this may be a reason that the cell centers were used.
That's the hallmark of the 360-degree wraparound. Much of GRASS
unconditionally treats 180W and 180E as the same thing, so a 360-degree
range becomes a zero-degree range. The issue isn't in r.proj per se but
the core libgis functions which manage regions.
#2100: r.proj bounding box too small by half a cell size (-g or -p):
-------------------------+--------------------------------------------------
Reporter: awickert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: r.proj | Platform: Linux
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by mmetz):
Replying to [comment:1 glynn]:
> Replying to [ticket:2100 awickert]:
>
> The border-walking code uses cell centres in all cases (i.e. when
performing projection as well as when displaying the bounding box with
-p/-g).
>
> It's possible that this is intentional, to avoid issues when the
north/south edges of either the current region or the input map extend to
the poles.
These issues arise only when region cropping is done for real
reprojection, and here the half-cell offset does not apply because the
cropped output region is aligned to the original output region. The
original output region in turn has been previously defined by the user.
Thus the reported bug applies only to r.proj -[p|g], introduced in r40560.
r.proj -[p|g] prints the real extents as of r63697. These real extents
need to be interpreted (and possibly adjusted) by the user with regard to
the input map extents and output projection.