[GRASS5] Outstanding issues for the 5.0 stable release
Glynn Clements
glynn.clements at virgin.net
Thu Jun 27 21:53:59 EDT 2002
Eric G. Miller wrote:
> > > - r.proj needs a clean-up. The improvements coded by Morten Hulden
> > > are partially disabled (region sensivity etc) which is a major
> > > drawback. If no general solution is possible, we may introduce
> > > optional flags.
> >
> > I've committed an update which makes the -n flag control both
> > bordwalk() calls; it also fixes the error handling.
> >
> > AFAICT, the remaining issues for r.proj are:
> >
> > 1. Whether to forward-project the entire input map in order to
> > determine the boundaries of the output map. This code is currently
> > present (in main.c) but disabled.
> >
> > 2. Whether the sense of the "-n" switch is correct, i.e. whether
> > cropping should be on or off by default.
>
> As a user, my preference would be for all of the input map per
> current region settings be projected into the output. Seems to be the
> most consistent with other GRASS raster operations. The output raster
> size should be no larger than the minimum bounding box of the projected
> input bounding box as adjusted for rectangularity.
1. This seems self-contradictory. For most GRASS raster commands, the
size of the output map is determined from the current region settings,
regardless of the portion which will be non-null.
2. Bear in mind that r.proj "works backwards". For each output cell,
it projects that cell's coordinates via the inverse projection
function to obtain the corresponding coordinates in the input map, and
copies the corresponding cell value from the input map to the output
map. Forward projection is only used to compute an optimal bounding
box.
3. There are two distinct bounding box calculations which are
performed. First, it inverse-projects the current region to the source
projection to determine the rectangular portion of the input map which
has to be read into memory. Second, it forward-projects that region
back to the output projection to determine the boundaries of the
output map.
4. When I say "computes", "guesses" may be a better term, as the
computation is fallible. It assumes that the boundary of the
projections of the cells is the projection of the boundary of the
cells. While this is likely to hold true for "almost affine"
transformations (i.e. projecting "small" regions), it can fail,
particuarly for creating "whole earth" maps from a lat-long source.
--
Glynn Clements <glynn.clements at virgin.net>
More information about the grass-dev
mailing list