#845: r.proj[.seg]: new flag to show reprojected bounds and exit
-------------------------+--------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: normal | Milestone: 6.5.0
Component: Raster | Version: svn-develbranch6
Keywords: r.proj | Platform: All
Cpu: All |
-------------------------+--------------------------------------------------
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.
#845: r.proj[.seg]: new flag to show reprojected bounds and exit
--------------------------+-------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: normal | Milestone: 6.5.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords: r.proj
Platform: All | Cpu: All
--------------------------+-------------------------------------------------
Comment (by 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.
#845: r.proj[.seg]: new flag to show reprojected bounds and exit
--------------------------+-------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: normal | Milestone: 6.5.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords: r.proj
Platform: All | Cpu: All
--------------------------+-------------------------------------------------
Comment (by 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.
#845: r.proj[.seg]: new flag to show reprojected bounds and exit
--------------------------+-------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: normal | Milestone: 6.5.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords: r.proj
Platform: All | Cpu: All
--------------------------+-------------------------------------------------
Comment (by cmbarton):
I thought I was agreeing with you. Get it to do the extents and let users
set the resolution.
#845: r.proj[.seg]: new flag to show reprojected bounds and exit
--------------------------+-------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: normal | Milestone: 6.5.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords: r.proj
Platform: All | Cpu: All
--------------------------+-------------------------------------------------
Comment (by hamish):
Replying to [comment:3 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)
#845: r.proj[.seg]: new flag to show reprojected bounds and exit
--------------------------+-------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: normal | Milestone: 6.5.0
Component: Raster | Version: svn-develbranch6
Resolution: | Keywords: r.proj
Platform: All | Cpu: All
--------------------------+-------------------------------------------------
Comment (by 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.
It is worse for r.in.xyz because there is no starting