[GRASS-dev] Re: g.proj and datum information (and gis.m)

[Paul Kelly]

Hi Moritz
Quite a few issues here but I'll try and address them

On Sat, 21 Oct 2006, Moritz Lennert wrote:

> Hello,
>
> I have an issue with g.proj -c and datum information.
>
> Procedure to reproduce:
>
> GRASS 6.3.cvs (spearfish60):~ > v.out.ogr input=landuse at PERMANENT type=area 
> dsn=/home/mlennert olayer=landuse layer=1 format=ESRI_Shapefile
>
> GRASS 6.3.cvs (spearfish60):~ > g.proj -c location=test georef=landuse.shp
> Trying to open with GDAL...ERROR 4: `landuse.shp' not recognised as a 
> supported file format.
>
> Trying to open with OGR......succeeded.
> A datum name nad27 (North_American_Datum_1927) was specified without 
> transformation parameters.

OK well you'd think that shouldn't happen because the datum transformation 
information was properly specified in the GRASS location. The 
GPJ_osr_to_grass() function only prompts for datum transformation 
information if it is only partially specified in the input co-ordinate 
system.

But the problem here is a deficiency in the WKT projection format that 
that the Shapefile uses. There is no way to specify that a datum gridshift 
file should be used for datum transformation (although it can store a set 
of towgs84=x,x,x,x,x,x,x parameters). So, for a location that uses 
gridshift files (e.g. nad27/conus or nzgd49/nzgd2kgrid0005.gsb), this 
information is lost on export to WKT format and then when importing the 
data back into GRASS there is no information in the .prj file to say which 
datum transformation method to use - so it *has* to prompt the user if 
fully-specified datum information is important, which in the case of 
creating a new location it is. I guess perhaps some other GIS may 
hard-code in that the conterminous USA gridshift file should be used with 
a NAD27 location, but IMHO that is simply wrong - e.g. NAD27 also covers 
Canada and various islands etc. My philosophy here was that it's very 
important for the user to make an informed decision about which datum 
transformation parameters to use as only he/she knows the area covered by 
the data and the accuracy required etc.

> Several issues with this:
>
> - Is this datum information really necessary ?

It is when creating a new location. GPJ_osr_to_grass(), which decides 
whether or not the user needs to be prompted about about the datum 
transformation information can be run in either non-interactive or 
interactive mode (one of the parameters passed to it indicates this). In
e.g. the projection check at the start of v.in.ogr/r.in.gdal the resulting 
co-ordinate system definition doesn't have to be fully specified - it is 
only used for comparison to the existing location and then thrown away. So 
in this case GPJ_osr_to_grass() is called in non-interactive mode and it 
does not prompt the user even if the input co-ordinate system has 
partially-specified datum information.

But in location create mode it's vital that the datum information is fully 
specified so that (a) re-projection modules will work and (b) in most 
cases, the co-ordinate system will be fully specified when exporting data.

> - gis.m reproduces the above message and datum choice prompt in the output 
> window, but the user can't do anything about it.

I haven't used gis.m, but why can the output window not accept user input? 
I think it would be cool if GRASS could work a bit like AutoCAD and Matlab 
which, while mostly GUI-oriented, still have a command line available. IIRC 
the way Radim integrated GRASS with QGIS on Windows with the GRASS shell 
inside QGIS worked something like this?

> - v.in.ogr with location= does not ask for datum information. In my eyes 
> 'g.proj -c' and 'v.in.ogr location=' should be consistent in their behaviour. 
> Or is there a reason for the contrary ?

Yes they should. Are you using them with the same input data? They both call 
GPJ_osr_to_grass() in interactive mode so if there is a datum name but not 
parameters they should prompt the user. You can avoid this by either 
passing no datum information at all (not even a name) or fully-specified 
(i.e. including transformation parameters).

I guess that doesn't help much but hope it explains why things are the way 
they are

Paul