Add "-e" switch (=extend location extents based on reprojected map) in r.proj

[nikos]

Well, the title speaks itself :-) Would it hurt to have this when reprojecting for example simple study area boundaries or similar? What speaks against it?

Also, I read in the manual of r.proj (section NOTES) "To avoid excessive time consumption when reprojecting a map the region and resolution of the target location should be set appropriately beforehand." but it's not clear to me why this can't be accomplished automatically.

[hamish]

Replying to nikos:

Well, the title speaks itself :-) Would it hurt to have this when reprojecting for example simple study area boundaries or similar? What speaks against it?

It violates the axiom of "do one thing well". The purpose of the module is to reproject maps, not to mess with the region. g.region should always be used for that. It is the GUI's job to tie those tasks together for the user in a nice wizard or menu order, not the individual number crunching modules' job to do all-in-one tasks.

see also trac wishes #37 and #123 (re. r.in.xyz) similar arguments there.

Also, I read in the manual of r.proj (section NOTES) "To avoid excessive time consumption when reprojecting a map the region and resolution of the target location should be set appropriately beforehand." but it's not clear to me why this can't be accomplished automatically.

because the user's intentions are unknowable to the program. Another way of saying the above is that "r.proj observes the current region settings".

e.g. if reprojecting from lat/lon WGS84 to UTM, how big should the resolution size be? ?

My usual method around this is in the source location to do g.region rast=map v.in.region out=map_box

then in the target location v.proj map_box loc=source g.region vect=map_box d.vect map_box # (observe amount of rotation) g.region res=... -a g.region -p # repeat until rows x cols are slightly bigger than source, # resolution is a nice round number, AND!! taking into # account more rows+cols needed as the map is more rotated

#finally: r.proj map loc=source

the code in i.rectify tries, but doesn't take into account rotation, so resolution is lost with rotated maps. see old RC bug #3926

​http://intevation.de/rt/webrt?serial_num=3296

also

​http://intevation.de/rt/webrt?serial_num=3052 ​http://intevation.de/rt/webrt?serial_num=3166

(we Badly need to back up the two old bug trackers!)

Hamish

[hamish]

Replying to hamish:

I meant what I said in the last post, but that may have come out a bit harsher than I intended. The resolution setting is really critical for r.in.xyz; for r.proj the user will have something to compare it to, so more of an idea that the output looks like crap vs original and that something has been set incorrectly.

Hamish

[nikos]

Thank you Hamish. All understood :-)

[glynn]

Replying to hamish:

Well, the title speaks itself :-) Would it hurt to have this when reprojecting for example simple study area boundaries or similar? What speaks against it?

It violates the axiom of "do one thing well". The purpose of the module is to reproject maps, not to mess with the region. g.region should always be used for that.

FWIW, I took the request as meaning setting the map's bounds (not the current region) to contain the entire projected map.

This isn't something that can readily be done with g.region, as r.proj is the only place where the relevant information is available (from the bordwalk() calculation).

Currently, r.proj reverse-projects the current region borders into the source projection, and only reads the needed portion of the source map into memory (for 6.4 r.proj) or into the temporary file (for 6.4 r.proj.seg and 7.0 r.proj). It then forward-projects that region into the target projection, and sets the map's bounds accordingly (so the map's bounds may be smaller than the current region).

It wouldn't be that hard to skip the first step and perform the second, so that the (internal) region, and thus the output map's bounds, was expanded to cover the projected boundary of the source map. You would still need to use "g.region rast=outmap" to see all of the new map.

[neteler]

Do ticket #845 and changes in 6.5svn (r40559) and trunk in r40560) help?

[hamish]

assumed resolved by the new r.proj -g functionality.