[GRASS-dev] updates to grass startup

[Michael Barton]

On 12/13/06 4:46 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:

> 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?

This is very good news. The design of gis_set.tcl is difficult overall,
because it is pretty old legacy code. I'm not sure there is an easy way to
do an automatic refresh after returning from the terminal window. If there
is some kind of return code, maybe it could be bound to an update event of
some kind.

> 
>> 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? 

I don't know how this work. I'll look into it as I'm currently working with
this file.

> 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.

I think this is an excellent suggestion. Note, however, that these files are
not in the same place on all platforms. Hamish notes that this needs to be
set in configure at compile time. If we could do as you suggest, configure
should generate an error if the relevant proj directory is not found.

> 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.

Agreed

> 
> 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.

This is worth following up, especially for new versions. Could you explain a
bit more.

Michael


__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton