[GRASS5] Re: 5.7: Datum transformation - DHDN?
paul-grass at stjohnspoint.co.uk
Wed Oct 6 10:18:37 EDT 2004
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
> 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.
More information about the grass-dev