[GRASS-dev] Re: g.proj and datum information (and gis.m)
paul-grass at stjohnspoint.co.uk
Fri Oct 20 21:03:18 EDT 2006
Quite a few issues here but I'll try and address them
On Sat, 21 Oct 2006, Moritz Lennert wrote:
> 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
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
More information about the grass-dev