[Proj] WGS84 parameters in epsg:31370 and 28992 (Belgian and Dutch coordinate systems)

[Frank Warmerdam]

Jan Hartmann wrote:
> Hi,
> 
> In the epsg-file in Proj-4.7.0, the Belgian coordinate system (31370) 
> has a +towgs84 clause, and the Dutch one (28992) hasn't. Is there any 
> reason for this? EPSG:28992 is much more usable *with* the +towgs84 
> parameter, as conversions to WGS84 latlon (EPSG:4326)  won't be correct 
> without it.  The same goes for conversions between Dutch and Belgian 
> coordinates: they *both* need the  +towsg84 parameter:
> 
> $ cs2cs +init=epsg:28992 +to +init=epsg:31370 # (only one projection or 
> none  with +towgs84, incorrect transformation)
> 300000 180000
> 368686.96       35802.01 0.00
> 
> $ cs2cs +init=epsg:28992 +to +init=epsg:31370 # (both projections with 
> +towgs84, this one is correct)
> 300000 180000
> 368729.27       35841.07 -301.04
> 
> My impression is that ellipse conversions (bessel to intl in this case) 
> are only done when both projections have a +towgs84 string. Is this 
> correct? I know that this is the case for lat-lon values (see Frank's 
> response at: 
> http://lists.maptools.org/pipermail/proj/2009-January/004303.html), but 
> is this also the case for projected coordinate systems? Doesn't look 
> right to me.

Jan,

The epsg init file generation logic defaults to supplying no wgs84
parameter for datums lacking a 3 or 7 parameter transform in EPSG or for
datums with more than one transform in EPSG.

I see that you supplied parameters for Belge 1972 in the past via a
bugzilla ticket as noted here in the libgeotiff gcs.override.csv file:

#
# From Jan: http://bugzilla.remotesensing.org/show_bug.cgi?id=1336
#
4313,Belge 1972,6313,Reseau National Belge 
1972,6313,9122,7022,8901,1,0,6422,9606,106.868628,-52.297783,103.723893,-0.336570,0.456955,-1.842183,1.0000012747

In the same file I see:

#
# Bart van den Eijnden and Jan Hartmann suggest this datum shift value:
#
#4289,Amersfoort,6289,Amersfoort,6289,9122,7004,8901,1,0,9606,565.2369,50.0087,465.658,-0.406857330322398,0.350732676542563,-1.8703473836068,4.0812

What is not clear to me is why the Amersfoort parameters were commented
out.  Curse me for note making clearer notes on why things are in the
state they are.  If you would like to file a ticket against libgeotiff
explaining why the above parameters are appropriate I can re-enable them
in libgeotiff and they will in time flow downstream into GDAL, PROJ.4,
PostGIS, etc.

As you note, no datum shift at all is applied unless both source and
destination datum have a defined relationship to WGS84 (towgs84, datum
shift file, etc).

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent