[GRASS-dev] Re: [GRASS-user] Projection Units and Values Negatively Affect r.topidx Results

[Hamish]

[moved from grass-user list]

Rich:
> >>   Wow! After all of yesterday's anguish, 6.5's r.proj
> >> did the trick. That's teriffic! So, should I continue this
> >> project in 6.5 or revert to the 6.4 revision 41119?
Hamish:
> > the modules are the same, the only difference is the new -p
> > and -g flags in 6.5 which can save you some time by not needing
> > to use the v.in.region where-am-I trick.
Markus: 
> Please let's backport it for 6.4.1 then.


I agree; but it does need some field testing time-

uncertainties:

 - it reprojects SW and NE corners and not all four, and so doesn't test
for e.g. the max of the two north coords and the min of the two south
corners. (mostly due to me not knowing if it really matters much in
practice and erring on the side of simplicity/laziness)

 - should it take this into consideration?   r.proj:
  /* Add 2 cells on each side for bilinear/cubic & future interpolation methods */
  /* (should probably be a factor based on input and output resolution) */

 - issues raised by, and Cedric's solution to, RT bug #3296
    http://intevation.de/rt/webrt?serial_num=3296

 - how it deals with projections that only/mostly work one way. (I guess
r.proj will choke on them anyway..?)

 - wouldn't be surprised by other unimagined problems.



also I had considered the 'r.in.gdal -l' flag for 6.4.1, as the work-
around for that one is very messy. (resetting bounds with gdal_translate
being the least-messy solution to force things into -90 > y > 90 lat)


all of these new flags are fairly benign code wise, it's more the
unimagined/correct assumptions bit I worry about.



Hamish