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

[Markus Neteler]

On Tue, Feb 01, 2005 at 05:07:21PM +0000, Paul Kelly wrote:
> 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.

If I recall correctly, we recently fixed that and a terminal pops
up to ask you. But that's not very much GUI style...

> Or if the problem is really that GRASS doesn't have the 
> parameters either, feel free to add them to datumtransform.table.

Yes.

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

Sure, better solutions are always welcome. 
The workaround sits there unless someone replaces it with something
better.
 
> >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.

At www.epsg.org you can fetch the *entire* DB in SQL (works well in PostgreSQL
etc), then extract things. The representation in PROJ4 is a subset which
does not permit for several datums for a zone (e.g. 4 datums for Gauss-Boaga
Fuso Ovest won't appear). But in the original EPSG DB it's present.

The QGIS people use a different list with different approach which looks
more reasonable. Shall be active from 0.7 onwards.

> So I wanted to add my thoughts into the archive :P
> 
> Paul

Markus