GREAT!!!! I'm in class now (on a break) but will compile and test ASAP. If it works, I'll make required changes in the location wizard.
Michael ____________________ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Oct 1, 2012, at 2:44 PM, Paul Kelly <[email protected]> wrote: > Markus Neteler wrote: >> >> I do agree that getting the datum lost is bad. Perhaps we could enhance >> g.proj to write it to PROJ_INFO when using the "Select coordinate system" way >> of creating locations. Proof of concept: >> >> GRASS 6.4.3svn (newLocation2):~ > eval `g.gisenv` >> >> GRASS 6.4.3svn (newLocation2):~ > echo "datum: eur50" >> >> $GISDBASE/$LOCATION_NAME/$MAPSET/PROJ_INFO > > I have just committed r53297 to trunk, which adds a new datum= option to > g.proj, which does something very similar to this. If a GRASS datum code is > given for the datum= option, it will override any datum in the input > co-ordinate system (or add one if it is missing). > > So you can now do something like: > g.proj -c loc=spain proj4="+proj=utm +zone=30 +ellps=intl" \ > datum=eur50 datumtrans=-1 > which will correctly prompt for all the datum transformation options for > eur50. You can also do > g.proj datum=list > to get a list of all supported datums like g.setproj does, but in a more > easily parseable format similar to the output from datumtrans=-1. > > Hope that helps a bit. > > Paul _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
