[GRASS-dev] updates to grass startup

[Paul Kelly]

Hello Michael

On Tue, 12 Dec 2006, Michael Barton wrote:

> I just committed a set of patches to the GRASS startup tcltk files
> (gis_set.tcl, epsg_option.tcl, and file_option.tcl). These are designed to
> make creating a new location from EPSG code or georeferenced file more
> robust. This is especially important for Windows users who cannot make a new
> location with g.proj.

BTW that is no longer true. g.setproj and etc/set_data work fine on 
Windows (better if you have Msys in your path though - I'm working on 
replacing a system("ls -C") call). If you click the "projection values" 
button in gis_set.tcl it will pop up a Window running set_data so you can 
create a location the traditional way. Current problem though is that the 
list of locations doesn't refresh to show the new location after you 
return from the box. I had a quick look a week or two ago but the design 
of gis_set.tcl seemed to make it very difficult to refresh that. Although 
if you click after the database directory and press Enter it refreshes. 
Maybe you have improved something to make that easier though?

> I¹ve tested these on my Mac OSX with x11 GRASS cvs build of last Friday and
> they seem to be fine. Please test on other platforms.
>
> Also, if we are going to have EPSG codes as a standard way to create a new
> location (and I think this is a handy way to go), can we distribute a copy
> of the EPSG file inside the GRASS directory structure (e.g., in the infamous
> catchall etc or another directory)? The EPSG file is ending up in different
> places on different architectures making it difficult to find. If it was
> always in the same place, within the GRASS hierarchy, it would be easy to
> make this the default location for the GUI.

I tried to create a location with EPSG code but it just says "WARNING: The 
epsg-codes file was not found!" and nothing appears to happen. Surely it 
isn't necessary to have that file installed if you already know the code 
you need? It isn't used for anything other than browsing and while 
including it in GRASS is definitely preferable to having to look for it 
wherever it was installed with PROJ, my preference would be to remove it 
altogether and instead in some way generate the lists from the .csv files 
in lib/proj that are actually used by g.proj to generate the location. Not 
sure how to do that but I think it's very confusing the way the file used 
for browsing is different from and potentially out of sync with the file 
used in the location generation.

Or another option would be to use the PROJ.4 definitions in that file 
directly and forget about the roundabout way it is currently done by 
passing the EPSG code to g.proj as part of a PROJ-style projection 
description? Whatever's done will probably need a bit of work though.

Paul