#845: r.proj[.seg]: new flag to show reprojected bounds and exit --------------------------+------------------------------------------------- Reporter: hamish | Owner: [email protected] 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>
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
