[GRASS5] Re: 5.7: Datum transformation - DHDN?

[Paul Kelly]

Hello Markus

On Wed, 6 Oct 2004, Markus Neteler wrote:

> Hello Paul
> (cc grass5)
>
> I'm just having import fun with projections and would like
> to hear your opinion:
>
> Trying to import the German FRIDA free vector data extended by a .prj
> file which looks like this:
>
> cat frida-1.0-shp-joined/proj.prj
> PROJCS["Transverse Mercator",GEOGCS["bessel",DATUM["D_Deutsche_Hauptdreiecksnetz",SPHEROID["bessel",6377397.155,299.1528128]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",1],PARAMETER["false_easting",3500000],PARAMETER["false_northing",0],UNIT["Meter",1]]
>
> I face the following problem:
>
> v.in.ogr dsn=frida-1.0-shp-joined/strassen-joined.shp output=strassen location=frida
> A datum name potsdam (Deutsches_Hauptdreiecksnetz) was specified without transformation parameters.
>
> Now select Datum Transformation Parameters
> Enter 'list' to see the list of available Parameter sets
> Enter the corresponding number, or <RETURN> to cancel request
>>
^^^^^^^^^

If you type list here it should give you a choice of the GRASS parameters 
for the DHDN/Potsdam datum, I think.

>
> Checking the name, reports:
> grep -i Hauptdreiec ~/grass57/lib/gis/*
> ~/grass57/lib/gis/datum.table:potsdam "Deutsches_Hauptdreiecksnetz"       bessel        dx=606.0    dy=23.0     dz=413.0
>
> Since ESRI uses the (gramatically wrong) 'D_Deutsche_Hauptdreiecksnetz', GRASS fails to
> find the values. So far no surprise.

But note that the warning message from GRASS used the correct format. I 
believe this is due to some good work by Frank in the OSRMorphFromESRI() 
from function which is called by GRASS to fix things up before importing 
the projection information, so I don't think there is a problem here 
really.

> To overcome the problem I would like to add 'D_Deutsche_Hauptdreiecksnetz'
> in lib/gis/datum.table.

The 'correct' way to do this (although it's really a bit of a hack) is to 
add two lines to the static const char *papszDatumEquiv[] in 
lib/proj/convert.c and recompile. The first one should be the 'wrong' 
value that has occured in your data, and the second one the value in the
GRASS datum.table. I did this for the New Zealand 2000 datum that Hamish 
was having some trouble with. Probably the even more correct way to fix it 
is to ask Frank to add some code to OGR to fix it.

But as I said I don't think it's necessary here---please check.

Paul