[GRASS-dev] Re: [GRASS GIS] #845: r.proj[.seg]: new flag to show reprojected bounds and exit

GRASS GIS trac at osgeo.org
Wed Dec 23 20:34:48 EST 2009


#845: r.proj[.seg]: new flag to show reprojected bounds and exit
--------------------------+-------------------------------------------------
  Reporter:  hamish       |       Owner:  grass-dev at 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.

 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

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/845#comment:2>
GRASS GIS <http://grass.osgeo.org>


More information about the grass-dev mailing list