[GRASS-dev] datums not recognized by g.proj?

[Michael Barton]

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 <paul-grass at stjohnspoint.co.uk>
 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