Opened 15 years ago

Closed 14 years ago

#845 closed enhancement (fixed)

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

Reported by: hamish Owned by: grass-dev@…
Priority: normal Milestone: 6.5.0
Component: Raster Version: svn-develbranch6
Keywords: r.proj Cc:
CPU: All Platform: All



the current + 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* 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.



Attachments (1)

rproj_hint.diff (3.7 KB ) - added by hamish 15 years ago.
patch to add flags for r.proj region hinting

Download all attachments as: .zip

Change History (7)

by hamish, 15 years ago

Attachment: rproj_hint.diff added

patch to add flags for r.proj region hinting

comment:1 by cmbarton, 15 years ago

I think this will be a good idea. Just doing the equivalent of what 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.


comment:2 by hamish, 15 years ago

FWIW I'm not a fan of the -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 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) 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 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

2c, Hamish

comment:3 by cmbarton, 15 years ago

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


in reply to:  3 comment:4 by hamish, 15 years ago

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

comment:5 by cmbarton, 15 years ago

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


comment:6 by hamish, 14 years ago

Resolution: fixed
Status: newclosed

committed to 6.5svn and trunk in r40559,60.

Note: See TracTickets for help on using tickets.