[Proj] Belge 1972 / Belgian Lambert 72 (31370) - towgs84parameters

[Jan Hartmann]

Mikael,

All my observations about the towgs parameters have been tested with 
real Belgian coordinates overlaid over Google. As I said before, the 
EPSG database is not very systematical in the way it represents its 
formulas, it just takes them from whatever source is available, untested 
AFAIK. Never use them without testing them with real world coordinates.

Jan

On 22-1-2010 13:31, Mikael Rittri wrote:
> Jan Hartmann wrote:
> > I have been quoting from PROJ 4.7. The older towgs parameter is not 
> exactly erroneous, it's just a bit less exact.
> But Thibaut's image showed an displacement of about 190 meters.  I 
> call that erroneous.
> Well, if by "older", you mean the EPSG datum shifts
>         1652 "BD72 to ETRS89 (1)" and 1609 "BD72 to WGS 84 (1)"
> you are right that they are just a bit less exact than EPSG datum shifts
>         15928 "BD72 to ETRS89 (1)" and 15929 "BD72 to WGS 84 (3)"
> But the towgs84 found in the current gcs.override.csv, as well as in 
> PROJ's nad/epsg file
> (at least in 4.6.1), are just wrong.  I think the wrong sign for DX, 
> DY and DZ causes most
> of the 190 meter error.
> By the way, in your first letter, you gave the older transforms as
> >   +towgs84=-99.059,53.322,-112.486,0.419,-0.830,1.885,-1
> which I think is correct, but you gave the newer transforms as
> > +towgs84=-106.8686,52.2978,-103.7329,-0.3366,0.457,-1.8422,-1.2747
> which I think has the wrong sign for the rotation angles: it should be
> > +towgs84=-106.8686,52.2978,-103.7329,0.3366,-0.457,1.8422,-1.2747
> instead.  (I base this correction on the fact that EPSG claims that 
> their datum shifts 15928 and 15929
> use the Coordinate Frame Rotation, so the rotation signs have to be 
> reversed for PROJ.4.  If the
> claim of EPSG contradicts the official documents - it happens now and 
> then -  please notify EPSG.)
> Regards,
>
> --
> Mikael Rittri
> Carmenta AB
> Box 11354
> SE-404 28 Göteborg
> Visitors: Sankt Eriksgatan 5
> SWEDEN
> Tel: +46-31-775 57 37
> Mob: +46-703-60 34 07
> mikael.rittri at carmenta.com
> www.carmenta.com
>
>
> ------------------------------------------------------------------------
> *From:* Jan Hartmann [mailto:j.l.h.hartmann at uva.nl]
> *Sent:* Thursday, January 21, 2010 11:51 PM
> *To:* Mikael Rittri
> *Cc:* PROJ.4 and general Projections Discussions
> *Subject:* Re: [Proj] Belge 1972 / Belgian Lambert 72 (31370) - 
> towgs84parameters
>
>
>
> On 21-Jan-10 12:52, Mikael Rittri wrote:
>> Jan Hartmann wrote:
>> > No, if QGIS uses PROJ, this is just an error.
>> Okay, you may be right that QGIS does not use the file gcs.override.csv.
>> But I see that the nad/epsg file of PROJ.4 contains the same erroneous
>> +towgs84 parameters for Belge 1972 as the gcs.override.csv.
>> (At least PROJ version 4.6.1).
> I have been quoting from PROJ 4.7. The older towgs parameter is not 
> exactly erroneous, it's just a bit les exact
>> > PROJ and EPSG use opposite rotational formulas, and PROJ uses 
>> degrees,  EPSG radians.
>> I don't agree in the general case.  PROJ uses the Position Vector
>> Transform, while EPSG is neutral on the rotation sign convention:
>> they use the same sign convention as the original source.
>> And PROJ uses arc seconds for rotations, while EPSG is neutral
>> on the angle unit: they use the same angle unit as the original source
>> (usually arc seconds, but sometimes microradians or radians).
>>      For the EPSG transforms you quote, EPSG use arc-seconds
>> for the rotations, but either the Position Vector Transform or the
>> Coordinate Frame Rotation depending on whether they got the
>> transform from Eurogeographics or directly from Belgium.
>>
> My information was for the Dutch and Belgian cases, as from the 
> official documents. I don't know on what principles EPSG operates, I 
> guess they just take it as they get it. It is not an easy-to-use database.
>
> Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20100122/c1a38a3b/attachment.html>