[GRASS-dev] backport r.proj -p, -g to 6.4.1svn?

GRASS GRASS developer
1

Hi,

any objections to backporting r.proj -p and -g flags? it makes it so you
don't need the v.in.region + v.proj tricks and makes the work flow a lot
easier (no need to change GRASS sessions).

also, any objections to backport v.in.lines? it's mostly just a wrapper
script with an easier to understand name.

Hamish

2

On 12/10/10 05:20, Hamish wrote:

Hi,

any objections to backporting r.proj -p and -g flags? it makes it so you
don't need the v.in.region + v.proj tricks and makes the work flow a lot
easier (no need to change GRASS sessions).

I would welcome this very much, but I would also like to ask : why not go one step further and add a flag which directly takes into account the extension and resolution of the original map to calculate a region for r.proj ?

Moritz

3

Moritz wrote:

I would welcome this very much, but I would also like to
ask : why not go one step further and add a flag which
directly takes into account the extension and resolution of
the original map to calculate a region for r.proj ?

Because it can+will do the wrong thing* and I think a human should
check over it, at minimum to pick a nice round resolution to use.
Versus doing the wrong thing, automatically.

[*] i.rectify tries to do this for you automatically, but it is
bad whenever there is convergence angle rotation between two
map projections (which is common; see 'g.region -n'). It is worst
for a square array when the angle is 45 deg, worst for a highly
rectangular array at 90deg rot. (see bug in old RC tracker)
Granted those extreme angles are more likely with i.rectify.

ie I think it is a task that requires careful consideration and
choices+compromises to be made.

Hamish

4

Hamish wrote:

any objections to backporting r.proj -p and -g flags? it makes it so you
don't need the v.in.region + v.proj tricks and makes the work flow a lot
easier (no need to change GRASS sessions).

IMHO, the documentation should be updated to indicate that the
information is only an estimate.

Better still would be to use the improved estimate obtained from
bordwalk(), which will be reasonably accurate except in pathological
cases. The four-corners estimate could be significantly off for cases
such as projecting lat-lon to LCC.

--
Glynn Clements <glynn@gclements.plus.com>