[GRASS5] [5.7] Exact datum names and v.in.ogr

[Paul Kelly]

Hello Hamish

Hamish wrote:
> 
> Hi, trying to import a shapefile into a location with the nzgd2k datum,
> v.in.ogr gives the following warning:
> 
> > v.in.ogr dsn=. out=coastline_g57 layer=coastline
> WARNING: Datum 'NZGD_2000' not recognised by GRASS and no parameters found.
>          Datum transformation will not be possible using this projection
>          information.
> Layer: coastline
> -----------------------------------------------------
> ...
> ...
> 
> How can I tell it NZGD_2000 == GRASS's nzgd2k ?
> Reprojecting with a datum transform is what I need the file for..

Well very short answer is that it doesn't matter. "this projection
information" in the warning refers to the projection information in the
georeferenced file. But presumably you have already set up the
projection information in your nzgd2k location to support datum
transformation so it is OK.

The problem is that when I was writing GPJ_grass_to_osr() (which is
where the above warning was emitted from) I had in mind that it would be
only called when it was really needed and that users would be interested
in such things as the status of the datum information. When actually it
is more useful than that and in this case it is just being called to
check the projection information in your input dataset against your
current location so it can warn you if they don't match.

I have added some extra output to v.in.ogr so it tells you that the
projections have matched and it is going ahead with the import. I will
have to think about changing the warnings from GPJ_grass_to_osr() but
they might be very useful sometimes.


> 
> I don't necessarily have write permissions on the data to edit the
> metadata file or want to do that (many many large files to copy/edit/break).
> 
> More generally, different people will call the same datum by slightly
> different names. How do we deal with this during data import?
> 

Yes, a huge problem. From
http://gdal.velocet.ca/~warmerda/wktproblems.html :

======

Datum Names

In Simple Features style WKT, the name associated with a datum is the
only way to identify the datum. In CT WKT the datum
can also have a TOWGS84 parameter indicating it's relationship to WGS84,
and an AUTHORITY parameter relating it to
EPSG or some other authority space. However, in SF WKT the name itself
is the only key.

By convention OGR and Cadcorp have translated the datum names in a
particular way from the EPSG database in order to
produce comparible names. The rule is to convert all non alphanumeric
characters to underscores, then to strip any leading,
trailing or repeating underscores. This produces well behaved datum
names like "Nouvelle_Triangulation_Francaise".

However, other vendors have done different things. ESRI seems to follow
a similar convention but prefixes all datum names
with "D_" as well, giving names like "D_WGS_1972". Also they have lots
of other differences for reasons that are not clear.
For instance for what Cadcorp and OGR call
"Nouvelle_Triangulation_Francaise", they call it "D_NTF". Oracle appears
to use
the raw names without cleanup. So for NTF they use "NTF (Paris
meridian)". 

The short result of this is that it is almost impossible to recognise
and compre datums between different Simple Features
implementations, though I have had some success in translating ESRI
datum names to match Cadcorp/OGR conventions, with
some special casing.

=======

The format of the GRASS datum.table file is really set in stone for many
years (although it wasn't used until recently) because of the C code
that reads it. I tried to make the most of the format by using the long
name (second parameter) for the WKT name and did the standard
translation from the WKT name using the conventions on Frank's page
above. Looks like your source for the nzgd2k files uses a different
convention.

It would be nice to be able to alter the format of the datum.table to
include alternative names. At the moment the 'hack' way of doing this is
to add a pair of entries to static const char *papszDatumEquiv[] in
lib/proj/convert.c in GRASS 5.7. The first entry should be the
alternative name, e.g. NZGD_2000, and the second the GRASS EPSG-derived
name, e.g. New_Zealand_Geodetic_Datum_2000. But this is not an ideal
long term solution.

GRASS now includes local copies of the GDAL datum database files. In
particular lib/proj/gdal_datum.csv may be of interest as it includes a
field, ESRI_DATUM_NAME, containing alternative datum names. Obviously
this could be extended and we could generate our own GRASS versions of
these CSV files using SQL queries from the EPSG co-ordinate system
database. Markus has some ideas on this also. But I am at the very
limits of knowing what I am talking about here so it's just really
letting the list know of some vague plans for the future.

Paul