[GRASS5] Re: [Fwd: whinging about GRASS again]

[Paul Kelly]

On Tue, 1 Feb 2005, Markus Neteler wrote:

> On Tue, Feb 01, 2005 at 08:08:30AM +0100, Paolo Cavallini wrote:
>> A suggestion to make things easier for a newby: in the startup screen, the way
>> EPSG codes are selected could be improved (e.g. with a pull-down menu, or
>> something similar);
>
> Fully agreed. First step is even to add a new field for towgs84 parameters
> in case that they are missing in the EPSG file (as it does for my
> favourite projections).

But are they not correct in the GRASS datum.table and datumtransform.table 
files? The problem here I think is g.proj / GPJ_osr_to_grass() 
is running non-interactively and it is not prompting you for the 
datum parameters. Or if the problem is really that GRASS doesn't have the 
parameters either, feel free to add them to datumtransform.table. Or if 
the problem is that the datum names from the EPSG file (actually in 
lib/proj/gdal_datum.csv IIRC) are non-standard and not recognised by GRASS,
add them to the list at the end of lib/proj/convert.c.

> But another button might be interesting:
> "create location from data set". This can be done in a few minutes
> modifying the underlying lib/init/make_location_epsg_g57.sh script
> as g.proj permits to create locations from arbitrary files supported
> by GDAL/OGR which contain projection information.

I wanted to do that ages ago. But I think that is a slightly messy solution.
It would be better to modify the underlying C programs (set_data et al if I 
remember correctly) to call the functions in the gproj library (like 
GPJ_osr_to_grass()) directly than setting up a dummy location and running 
g.proj.

> Still pessimistic to find a tcl/tk programmer who makes a clean-up
> of the start screen layout (idea on paper on my table).
> And adds the desired button for calling the "create location from data set"
> script.

I think it could be done in C (set_data etc.) and even just text-based 
first to get the algorithm right. GRASS should have some 
device-independent functions for interactive programs like g.setproj so 
that prompting or messages go to the terminal if the user is not running a 
GUI, or else use GUI interactive features.

I'm not proposing to do this now... just this is something I've thought a 
lot about a clean way of doing it and the current EPSG code system is 
messy (e.g. the EPSG codes are actually picked from a different list to that
which the locations are subsequently generated from) and would better be 
replaced than extended IMHO.
So I wanted to add my thoughts into the archive :P

Paul