[GRASS-dev] Create new location from EPSG code backport problem

[Paul Kelly]

On Wed, 25 Apr 2007, Paul Kelly wrote:

> Hello Hamish
> I'm not sure if it's correct/optimum in the current CVS. I posted some plans 
> here:
> http://www.nabble.com/forum/ViewPost.jtp?post=9125507&framed=y
> that I think should be fixed before it goes into a stable release.
>
> In particular I'm not sure if the logic in the Tcl code for the order of the 
> various g.proj calls and the value of the datumtrans= option is correct yet. 
> IIRC the location should be created on the first attempt if there is no list 
> of datum transformation paramters, and the default when there is a choice 
> should be 0 (unspecified) rather than forcing the first set. But the Tcl code 
> doesn't do this.
>
> Will try and find time to have a look at it.

I've now revisited this and implemented most things I described in the 
link above apart from the region setting/verification dialog.
I added a prettier radio button-based dialog for the datum transformation 
parameter selection. I also have hopefully tested it fairly robustly for a 
range of EPSG codes that result in various different warnings and error 
output from g.proj, and these should all be reported correctly now.

The datum transformation selection / improved g.proj interaction needs to 
be implemented for the georeferenced file option as well as the EPSG 
option - I could have easily done this by copying and pasting code but 
that seemed very quick and dirty - would much rather reduce code 
repetition and share the necessary functions but I've already had enough 
Tcl for a little while :) Am starting to pick it up though. There seem to 
be some solid and clear design ideas behind it but the operating system 
interaction bits have a few quirks and I suppose we're pushing it pretty 
hard in gis.m.

Paul