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