[GRASS-dev] g.proj to create a new location

[Paul Kelly]

Hello Hamish

On Thu, 8 Feb 2007, Hamish wrote:

> I have now added new epsg= and datumtrans= options to g.proj in CVS.
>
> The epsg= option to create new location by EPSG code is fully
> functional:  (it just plugs the code into a PROJ4 format string)
>
> G63> g.proj -c loc=newlocNZTM epsg=2193
> Location newlocNZTM created!
>
> If it needs more info WRT datum transform options, it currently goes
> interactive as the datumtrans= option to list or select datum transform
> parms is not yet functional. Paul, can you try and connect this to
> get_datum_transform_by_name() and GPJ_ask_datum_params(), or wherever
> the number needs to get to? Mucho gracias.

I have this working now in my local copy, but just realised a slight flaw 
with it. Because we are assuming a default of datumtrans=1, there is no 
way to assume if the user specifically asked for the 1st set of datum 
transformation parameters, or they are just using the default. Up to now, 
if the user didn't specifically specify datum transformation parameters, 
they were not written into the PROJ_INFO, only the datum name. When 
necessary then (e.g. using one of the re-projection modules), the current 
default parameters for that datum would be read from the datum.table file 
and used. So if the default changed (e.g. we discovered it was wrong and 
updated it) the user wouldn't need to edit their location to take 
advantage of the update. But if the parameters are written into the 
PROJ_INFO, then whatever default was in force at the time becomes set in 
stone.

The logic in a few parts of the GRASS gproj library also uses the 
presence/absence of specific transformation parameters in the PROJ_INFO as 
an indicator of how likely any parameters present are to be 
correct/appropriate for the location.
E.g. when writing an output WKT file, GRASS always puts the datum name 
in, but only adds TOWGS84 parameters if they were specifically specified 
in the PROJ_INFO. Again, the logic is that the parameters had been 
specifically specified so there was a good chance they were correct and 
there was no harm promulgating them on. But if the user had just accepted 
the default parameters, then we're not so sure if they're appropriate for 
the specific area of the data, so just put the datum name in and whoever 
receives the export data can use their own initiative in choosing 
appropriate parameters.

With this new functionality however, we are always assuming the user 
specified datumtrans=xxx, so the parameters are always written in.

I'm not sure what to do about this, whether it's nothing to worry about or 
not.

Also, I was wondering what format would be appropriate for the 
GUI-parsable list of datum transformation parameters. In the copy I have 
I'm just printing to stdout the list that you got by typing list at the 
old interactive prompt. Are there any existing examples of something 
similar I wonder.

Paul