r.proj[.seg]: new flag to show reprojected bounds and exit

[hamish]

Hi,

the current v.in.region + v.proj method for finding/setting the output region prior to running r.proj successfully is a time wasting pain in the neck. the attached patch adds two flags to r.proj (-p and -g) to display the bounds of the input map reprojected into the present location's projection. if it gets rotated along the way I'm not sure if these numbers will be at the far corners or in the middle of the source box.

patch is vs. 6.5svn's raster/r.proj.seg/main.c but applies to trunk's r.proj ok.

another idea is to have another new flag to automatically adjust the output map's region like the r.in.* modules would. But then resolution will typically be broken and you still have to fix that by hand, so I'm not sure how much that gains you. IIRC i.rectify has some code for figuring out the output resolution based on the input, but IIRC that is simplistic based on number of rows and columns and so it's buggy if there is much north-rotation between the two locations. IIRC the ticket for that bug is in the old RT bug tracking system, and a possible solution is to multiply ew,ns resolution by the cosine of the convergence angle. So for now I prefer to set the output resolution by hand.

comments?

Hamish

[hamish]

patch to add flags for r.proj region hinting

[cmbarton]

I think this will be a good idea. Just doing the equivalent of what r.in.gdal does--extend region to match reprojected map--will be an enormous improvement. In many cases, you want the resolution of the target region to be somewhat different anyway (e.g., latlon to utm), so the effort of trying to match the resolution, though potentially useful, is less important the getting the extents right so that you can actually have a map to display after reprojection.

Michael

[hamish]

FWIW I'm not a fan of the r.in.gdal -e flag. If it were not for the create-new-location ability I'd argue that it should be removed (as only g.region should be changing the DEFAULT_WIND or region settings). But because of the create-new-location r.in.gdal ability why avoid setting the resolution in that case? (and make then make it automatic for new location creation but remove the flag for general use)

r.in.xyz has a similar "issue", but there as well automatically doing the wrong thing is not a good solution. You should have to ask it to do the wrong thing.. :) It is worse for r.in.xyz because there is no starting clue as to what the resolution should be. You are not doing new users any favors by giving them a default which produces bad results, when the path to real success is not very intuitive. Very good guiding documentation or an interactive wizard is the solution there.

For r.proj we have starting info and math on our side, so we have better chances at guessing what the region and resolution will be. Still, some rounds of 'g.region -p' + 'g.region res= -a' will be needed to get it right. FWIW, note that my patch exports the bounds before they are grown a few cells outwards by the following code.

I suggest we tackle the i.rectify bug before thinking about adding new functionality to automatically set stuff. see

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

2c, Hamish

[cmbarton]

I thought I was agreeing with you. Get it to do the extents and let users set the resolution.

Michael

[hamish]

Replying to cmbarton:

I thought I was agreeing with you. Get it to do the extents and let users set the resolution.

Ok, never mind the rand then :) I guess what I was picking up on was what the meaning of "do the extents" is... this patch just tells you what they are but doesn't set them for you. (but puts them in a handy g.region compatible format with -g)

best, Hamish

[cmbarton]

Well that is a big step forward and would avoid all the rigamarole of doing v.in.region in the source region and so on. Once I can compile again, I'll try it. Hopefully soon.

Michael

[hamish]

committed to 6.5svn and trunk in r40559,60.