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

[Hamish]

Hamish wrote:
> I'm trying to backport Michael's fancy new EPSG code search tool
> and location creator for the 6.2 branch, to have in the upcoming
> 6.2.2 release.

Now in the 6.2 cvs. This probably needs rigorous testing- grab the weekly
6.2.2 cvs snapshot* and run "cvs update".

[*] a smaller patchset vs 6.2.1 not 6.2.0 would be nice; did we ever sort
out the inclusion of new files problem in that patchset?


>> I will simplify. I was backporting most of epsg_option.tcl.in,
>> including parts of the new location generation code. I will change
>> tack to only backport the EPSG code search tool, as originally
>> discussed. I will leave all the improved location generation code to
>> the 6.3 branch.
..
> this is primarily epsg_option.tcl.in Rev 1.15 (last before deletion)
> with the old grass-xterm-wrapper make_location_epsg.sh xterm code for
> making new locations instead of the new epsgOpt::create_loc
> replacement.



KNOWN BUGS:


*****
[6.2 only]
> if you give it a bogus EPSG code like "999999" it fails to make a new
> location but doesn't tell you that as the xterm flashes by, just
> silently fails.
(exit code of make_location_epsg.sh is not tested, see grass-run.src)


*****
[6.2 only]
> a lingering [harmless] exit bug in proc epsgOpt::def_loc:
> 
> DialogGen .wrnDlg [G_msg "WARNING: restart GRASS please"] warning \
>     [G_msg "WARNING: Please restart GRASS in order find the created
>  location in the list (closing it for you now)"] \
>     0 OK; 
> set env(EPSGSCRIPT) {yes};
> # complains that exit needs a numeric arg, but then if you give
> #  it one with [list "exit" "2"] it then complains that you gave
> #  it too many args. ARgh!
> puts stdout "exit";
> destroy .
> 
> (comment out "destroy ." to see the complaint; prob "tput clear" in
> init.sh too [x2])


*****
[both 6.2 and 6.3]
> if you search for an EPSG code, grab it [fills in value in parent window],
> then manually highlight another and then click Grab again, the value in
> the parent window doesn't update.


*****
[6.3 only]
 lib/init/epsg_option.tcl
----
	set epsgLocation [ string trim $epsgLocation ]

	if {[file exists $epsgLocation ]== 1} {
		tk_messageBox -type ok -icon error \
			-message [G_msg "WARNING: The location '$epsgLocation'\nalready
exists, please try another name"] 
		set epsgLocation ""
		return
	}
----

the above should read:
	if {[file exists "$locpath/$epsgLocation" ]== 1} {
??

otherwise it never finds the directory, even if it exists.
 (name vs path/name)
6.3 fails cleanly as g.proj refuses to overwrite the old location.
Does Windows's Tcl need a G_dirsep() translation or is "/" ok there?


Hamish