[GRASS-dev] Create new location from EPSG code backport problem
paul-grass at stjohnspoint.co.uk
Tue Aug 14 23:47:37 CEST 2007
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
> 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.
More information about the grass-dev