[Proj] Stereo 1970 (EPSG 31700)

Noel Zinn (cc) ndzinn at comcast.net
Thu Oct 7 03:17:12 PDT 2010 

Hi Mikael,

It is true that there is no numerical problem using a 7-parameter 
transformation derived from observations in a small area, which means, I 
will add, derived poorly.

It is an unfortunate reality that more geodetic software supports 
7-parameter transformations than supports Molodensky-Badekas (M-B) 
transformations, sometimes called 10-parameter transformations due to the 
additional 3 coordinates of the topographic rotation center, but these are 
givens of the adjustment and not additional parameters to be solved for. 
(Perhaps you can advise me if this indictment of geodetic software applies 
to Proj4.)  Anyway, in the example you provide (EPSG Tfm Codes 4827 and 
4829) the Slovakian authorities had this deficiency in mind in supplying a 
7-parameter transformation to replace a M-B transformation.

It may be true (not positive as I haven't tested this) that the coordinate 
results of a given M-B transformation can be reproduced by some 7-parameter 
transformation as you suggest.

The problem with 7-parameter transformations derived in small area is more 
fundamental, however.  The 7 parameters of a 7-parameter (Helmert, 
Bursa-Wolfe, or similarity) transformation have well-known and 
well-documented physical interpretations.  The 3 translations represent the 
relative displacement of the geocenters of the two ellipsoids involved (in 
the ECEF X, Y and Z directions); the 3 rotations represent rotations about 
the X, Y and Z axes; and the scale represents an inflation (or deflation) of 
an ellipsoid (i.e. the linear unit).  These 7 parameters are not like the 
parameters of a multiple regression equation (MRE) of the kind that used to 
be published by the Defense Mapping Agency (DMA, predecessor to NIMA and 
NGA) for transforming datums with more "accuracy" than a 3-parameter 
translation.  Those parameters can be pencil whipped into submission because 
they "mean" nothing.  The 7 parameters of a Helmert (et al) transformation 
mean something and that meaning is badly corrupted by the ill conditioning 
of an adjustment over a small area.

Let me illustrate this point with my own EPSG tfm code examples.  Codes 
15714, 15716, 15718, 15720, 15722, 15724, 15716 and 15728 offer 7-parameter 
transformations from Bogota 1975 to Magna-Sirgas for regions I through VIII 
in Colombia and codes 15730 through 15737 offer M-B parameters for the same 
regions respectively.  Code 1125 offers a 3-parameter translation between 
Bogota 1975 and WGS84, which EPSG regard to be the same as Magna-Sirgas at 
the 1-meter level.  So, the 3 parameters of tfm 1125 provide a 1-meter 
assessment of the geocentric displacement between the International 1924 
ellipsoid of Bogota 1975 and GRS80 of Magna-Sirgas.  Now, observe that these 
same 3 translations (307, 304, -318) are pretty much the same as the first 3 
parameters of all the M-B transformations for the eight regions (tfm codes 
15730 through 15737).  Finally, observe the first 3 parameters of the 
7-parameter transformations for the eight regions (tfm codes 15714, 15716, 
15718, 15720, 15722, 15724, 15716 and 15728).  Shocking, isn't it?  They're 
scattered meaninglessly all over the place, a consequence of the ill 
conditioning of deriving a 7-parameter transformation in an area an eighth 
the size of Colombia.

The derivation of a 7-parameter Helmert (et al) transformation over a small 
area is pencil whipping, not geodesy.  Until all of (y)our software supports 
M-B, use a 3-parameter translation instead!

Regards,
Noel

Noel Zinn, Principal, Hydrometronics LLC
+1-832-539-1472 (office), +1-281-221-0051 (cell)
noel.zinn at hydrometronics.com (email)
http://www.hydrometronics.com (website)

--------------------------------------------------
From: "Mikael Rittri" <Mikael.Rittri at carmenta.com>
Sent: Thursday, October 07, 2010 2:13 AM
To: "PROJ.4 and general Projections Discussions" <proj at lists.maptools.org>
Subject: Re: [Proj] Stereo 1970 (EPSG 31700)

> Hello Noel,
>
>> The least-squares adjustment of 7 transformation parameters
>> (3 translations, 3 rotations and a scale) for an area as
>> small as the country of Romania is badly ill-conditioned.
>
> Now I am confused.
>
> What you say is that it is a difficult statistical problem
> to derive a 7-parameter transformation from observations in
> a small area. But if someone I can trust has already derived
> a 7-parameter transformation, then there is no numerical
> problems when using it, is there?
>
>> In these cases use a 3-parameter transformation instead.
>> Or a Molodensky-Badekas transformation ... as has become
>> common in some smaller countries (e.g. Luxembourg, Venezuela)
>> ... if you can find (or derive) one.
>
> Well, but if a Molodensky-Badekas transformation is okay,
> then there is always a 7-parameter transformation that gives
> the same result.  For all I know, the Romanian authorities
> may have started out by deriving a Molodensky-Badekas
> transformation, and then decided to publish it as the
> equivalent 7-parameter transformation.  If that is what
> they did, there would be no reason to suspect that their
> transformation is less accurate than the 3-parameter
> transformations, is there?
>
> (An example: the datum shift EPSG:4829, "S-JTSK to ETRS89 (3)",
> is a Molodensky-Badekas transformation, and the datum
> shift EPSG:4827, "S-JTSK to ETRS89 (4)", is the same
> transformation expressed as a 7-parameter transformation.)
>
> Best regards,
>
> Mikael Rittri
> Carmenta AB
> Sweden
> www.carmenta.com
>
> -----Original Message-----
> From: proj-bounces at lists.maptools.org 
> [mailto:proj-bounces at lists.maptools.org] On Behalf Of Noel Zinn (cc)
> Sent: den 6 oktober 2010 16:47
> To: PROJ.4 and general Projections Discussions
> Subject: Re: [Proj] Stereo 1970 (EPSG 31700)
>
> Although the third of the three EPSG transformations cited herein has the
> (Romanian) National Agency for Cadastre and Land Registration as its 
> source (and is, therefore, authoritative) and it has more parameters (7 
> versus 3 for the Shell and NIMA transformations), it should not be 
> regarded as more accurate.  The least-squares adjustment of 7 
> transformation parameters (3 translations, 3 rotations and a scale) for an 
> area as small as the country of Romania is badly ill-conditioned.  The 7 
> parameters are highly correlated and, therefore, are driven by small 
> survey errors, not physical reality.
> Simply stated, the translations pull in one direction and the rotations in 
> another.  Australia is big enough, but not Romania.  Not even Germany.  In 
> these cases use a 3-parameter transformation instead.  Or a 
> Molodensky-Badekas transformation ... as has become common in some smaller 
> countries (e.g. Luxembourg, Venezuela) ... if you can find (or derive) 
> one.
>
> Noel Zinn, Principal, Hydrometronics LLC
> +1-832-539-1472 (office), +1-281-221-0051 (cell)
> noel.zinn at hydrometronics.com (email)
> http://www.hydrometronics.com (website)
>
> --------------------------------------------------
> From: "Mikael Rittri" <Mikael.Rittri at carmenta.com>
> Sent: Wednesday, October 06, 2010 2:38 AM
> To: "PROJ.4 and general Projections Discussions" <proj at lists.maptools.org>
> Subject: Re: [Proj] Stereo 1970 (EPSG 31700)
>
>> Hello, Thibaut.
>>
>> For the record, www.epsg-registry.org gives three datum shifts from
>> Pulkovo 1942(58) to WGS84 that are valid in Romania.
>>
>> Code Accuracy Source Proj.4 syntax
>> 15496 10 meters Shell SIEP +towgs84=44.107,-116.147,-54.648
>> 15497 7 meters NIMA TR8350.2 +towgs84=28,-121,-77
>> 15995 3 meters www.ancpi.ro (*)
>> +towgs84=2.329,-147.042,-92.08,-0.309,0.325,0.497,5.69
>> (*) National Agency for Cadastre and Land Registration
>>
>> The third one seems to be more accurate than the two you mentioned. Of
>> course, this may not matter if your main concern is to get ArcMap and
>> Qgis to agree.
>>
>> Actually, it is possible that the Shell datum shift is more accurate
>> than the NIMA one, since accuracies that EPSG quotes from different
>> sources are not comparable.  I think accuracies from NIMA are usually
>> one-sigma (about 67 percent confidence), but I don't know about Shell.
>> But my impression is that the ANCPI datum shift is the most accurate.
>>
>> By the way, I noticed that the code EPSG:31700 is deprecated, because
>> it used the the geodetic datum Dealul Piscului 1970, EPSG:6317.  This
>> was deprecated in September 2008 because
>>
>>   "Datum does not exist but is an alias for S-42 in Romania" (Change
>> ID 2008.011).
>>
>> And S-42 is (in this context) the same as Pulkovo 1942(58).
>> So, EPSG:31700 has been replaced by EPSG:3844, "Pulkovo 1942(58) /
>> Stereo70".
>>
>> Best regards,
>>
>> Mikael Rittri
>> Carmenta AB
>> Sweden
>> www.carmenta.com
>>
>> ________________________________
>>
>> From: proj-bounces at lists.maptools.org
>> [mailto:proj-bounces at lists.maptools.org] On Behalf Of Thibaut Gheysen
>> Sent: den 4 oktober 2010 17:24
>> To: PROJ.4 and general Projections Discussions
>> Subject: Re: [Proj] Stereo 1970 (EPSG 31700)
>>
>>
>> I checked in Arcmap, there are two "geographic coordinate system
>> transformations" for stereo 1970 to wgs84. I used the first with those
>> parameters : +towgs84=44.107,-116.147,-54.648,0,0,0,0. The suggested
>> proj.4 definition correspond to the second "geographic coordinate
>> system transformations" in ArcMap.
>>
>> All is fine now.
>>
>> Thanks for your help,
>> Thibaut.
>>
>>
>> 2010/10/4 Thibaut Gheysen <gheysen.t at gmail.com>
>>
>>
>> Thanks Frank.
>> I use QGis 1.5 from osgeo4w (I don't know exactly which version of
>> Proj.4 is used).
>> I just try with your suggested definition. It's better but I always
>> have a deviation of about 5 meters.
>>
>> Thibaut.
>>
>>
>> 2010/10/4 Frank Warmerdam <warmerdam at pobox.com>
>>
>>
>> Thibaut Gheysen wrote:
>> > Hi,
>> >
>> > I have a problem in QGIS with the Stereo 1970 coordinate system
>> > (EPSG 31700).
>> > I have a shapefile in the WGS 84 coordinate system (from a GPS device).
>> > I projected this shapefile in Stereo 1970 using ArcMap.
>> > In ArcMap, the source and projected points are in the same place. In
>> > Qgis, I have a deviation of about 100 meters when displaying this 2
>> > shapefiles and activating the "on the fly projection" (stereo.jpg).
>> > This deviation is the same that the one I obtain in ArcMap without
>> > "geographic coordinate system transformations".
>>
>>
>> Thibault,
>>
>> I'm not sure exactly what version of PROJ.4 you are using, but after
>> my "datum shift identification upgrade" the EPSG dictionary for proj
>> now has this as the suggested definition of 31700:
>>
>>
>> +proj=sterea +lat_0=46 +lon_0=25 +k=0.99975 +x_0=500000 +y_0=500000
>> +ellps=krass +towgs84=28,-121,-77,0,0,0,0 +units=m +no_defs
>>
>> Perhaps you could try with this?
>>
>> 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
>> <http://pobox.com/%7Ewarmerdam>
>> and watch the world go round - Rush    | Geospatial Programmer for Rent
>>
>> _______________________________________________
>> Proj mailing list
>> Proj at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/proj
>>
>>
>>
>>
>> _______________________________________________
>> Proj mailing list
>> Proj at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/proj
>>
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>

More information about the Proj mailing list