Opened 10 years ago

Closed 5 years ago

#2100 closed defect (fixed)

r.proj bounding box too small by half a cell size (-g or -p):

Reported by: awickert Owned by: grass-dev@…
Priority: normal Milestone: 7.0.7
Component: Default Version: unspecified
Keywords: r.proj Cc:
CPU: Unspecified Platform: Linux

Description

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.

Cheers,

Andy Wickert

Attachments (1)

bordwalk_diff_awickert_20131014.c (1.3 KB ) - added by awickert 10 years ago.

Download all attachments as: .zip

Change History (10)

in reply to:  description ; comment:1 by glynn, 10 years ago

Replying to 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.

Otherwise, the fix should be reasonably straightforward: remove the half-cell offsets from bordwalk1() in raster/r.proj/bordwalk.c.

in reply to:  1 ; comment:2 by awickert, 10 years ago

Replying to 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.

Cheers,

Andy Wickert

by awickert, 10 years ago

in reply to:  2 comment:3 by glynn, 10 years ago

Replying to 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.

in reply to:  1 comment:4 by mmetz, 9 years ago

Replying to glynn:

Replying to 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.

comment:5 by neteler, 9 years ago

r63697 backported in r64034. Can the ticket be closed?

comment:6 by martinl, 8 years ago

Milestone: 7.0.07.0.5

comment:7 by neteler, 7 years ago

Milestone: 7.0.57.0.6

comment:8 by neteler, 6 years ago

Milestone: 7.0.67.0.7

comment:9 by mlennert, 5 years ago

Resolution: fixed
Status: newclosed

This bug has a fix, that has been backported and no activity since, so closing.

Note: See TracTickets for help on using tickets.