[GRASS-dev] status and updates of datumtransform.table

Paul Kelly paul-grass at stjohnspoint.co.uk
Tue Jun 9 12:35:40 EDT 2009


On Tue, 9 Jun 2009, Moritz Lennert wrote:

> What is the status of lib/gis/datumtransform.table ? Trying to do some 
> reprojection between LL-WGS84 (epsg 4326) and belgian lambert 72 
> (epsg:31370), I see some problems due to the parameters in that file:
>
> - in the proj epsg file (Rel. 4.6.0, 21 Dec 2007), the belgian lambert 72 
> projection is defined as
>
> +proj=lcc +lat_1=51.16666723333333 +lat_2=49.8333339 +lat_0=90 
> +lon_0=4.367486666666666 +x_0=150000.013 +y_0=5400088.438 +ellps=intl 
> +towgs84=106.869,-52.2978,103.724,-0.33657,0.456955,-1.84218,1 +units=m 
> +no_defs
>
> - this is confirmed by the info given by the Belgian geographic institute 
> [1], which gives the same parameters with only differences in sign of which I 
> don't know if they have any effect
>
> - however in lib/gis/datumtransform.table one can find:
>
> bel72   "towgs84=-99.1,53.3,-112.5,0.419,-0.830,1.885,-1.00" "Belgium" 
> "Accuracy about 0.3m"

This (like most of the parameters for European countries) comes from this 
site: http://crs.bkg.bund.de/crseu/crs/eu-countrysel.php?country=BE
(http://crs.bkg.bund.de/crs-eu/ for the top-level site, formerly 
crs.ifag.de as indicated in datumtransform.table).

Up to now it has been very accurate and reliable, so this is an 
interesting observation and I wonder where the different parameters come 
from. Belgium was covered in the ASPRS Grids & Datums column back in 1998 
(http://www.asprs.org/resources/grids/10-98-belgum.pdf) and unfortunately 
there aren't any parameters given there that could be a clue.

> which gives quite different results when reprojecting compared, for example, 
> to cs2cs.
>
> What is the reason to have this datumtransform.table file ? Isn't most of 
> this covered by proj / epsg these days ?

Well a lot of countries have a choice of datum projection parameters and 
as far as I know the GDAL EPSG tables don't include any (to avoid making 
the wrong choice). Also if you're not creating a location using an EPSG 
code you'd need some way of interactively browsing the datum 
transformation parameters and making a choice anyway. This sort of thing 
is discussed on the MetaCRS list occasionally 
(http://lists.osgeo.org/pipermail/metacrs/) but I think a solution is 
still fairly far away from emerging.

Probably we should update datumtransform.table with the correct Belgium 72 
parameters. But it would be reassuring to find out where the wrong ones 
have come from first...

Paul


More information about the grass-dev mailing list