[Proj] WGS84 to ED50

Tue Nov 20 07:28:10 PST 2007

TR8350.2 I believe ALSO publishes the coefficients for several regional Multiple Regression Equations (MRE) for ED50 transformations.  That may be what Applanix is doing ...

See:   http://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350_2.html

C. Mugnier

________________________________

From: proj-bounces at lists.maptools.org on behalf of Roger Oberholtzer
Sent: Tue 20-Nov-07 07:21
To: proj at lists.maptools.org
Subject: RE: [Proj] WGS84 to ED50

On Mon, 2007-11-19 at 16:43 -0600, Clifford J Mugnier wrote:
> I have been reading this thread with some amusement, as datum shifts
> are only a compromise to begin with, and attempting to achieve better
> than 1-2 meters with even a 7-parameter transformation is a totally
> unreasonable expectation.  The original data for the classical datum
> is not that good!

The conversion is fully in software. So I am trying to get, if possible,
one piece of software to do what another one does. I do not think there
is anything odd or unreasonable in attempting that. My assumption in
going in to this is the I am doing something wrong (based on previous
experiences...). I have or have not specified something, or I have
specified something incorrectly. Should I be able to correct this, proj
may very well provide the results I seek. I would be a fool NOT to try
to correct any errors I have made. Thus, my question.

> Matching another transformation is a reasonable expectation, but it
> could be (likely), that the "client" is attempting to match actual
> observations with Trimble/Applanix gear working directly in WGS84
> rather than a Trimble/Applanix algorithm!  European Datum 50 (ED50)
> was "cooked up" in 1950 by Geodesists at the U.S. Army Map Service
> after WWII using geodetic surveys of Spain and Portugal performed over
> the prior 50-75 years!  That stuff wasn't that good!

The conversion I am trying to match is using a text file with WGS84
lat/long values from a GPS receiver. The absolute accuracy of these is
irrelevant for this test. They are simply a set of numbers. Trimble and
Applanix PC software convert these lats/longs into northings and
eastings, claiming that these Northings and Eastings are in ED50 for
Spain and Portugal. They only have available for this purpose the
lats/longs as provided, and whatever ED50 code is in their respective
libraries.

> Try reading my columns on the Grids and Datums of Spain and Portugal
> at:  www.ASPRS.org/GRIDS  and you'll get a better appreciation of the
> complexity of the problem being sought with a mere 7-parameter
> transformation.  (Spain is July, 2000, and Portugal is April, 2002)

I will make a bee line for this.

> Combining Applanix and Trimble gear is cutting-edge geodetic equipment
> commonly used for Real Time Kinneatic (RTK) Aerial Photography for
> hair-splitting accuracy.  That stuff is working directly in WGS84
> Broadcast Ephemeris and is then re-adjusted in post-processed mode
> with the Precise Ephemeris a couple weeks later.
> 
> That's NOT going to "match" data that's 75-100 years old!

That is not what I am trying to do. The WGS84 values are what they are.
The Applanix, as you correctly state, provides lats/longs that are very
accurate. But when it comes to converting these lats /longs to Northings
and Eastings, it is down to math of the type proj does.

BTW, we measure the location of a road measurement vehicle, where
customers are unfortunately demanding absolute accuracy of < 1 meter
(our northings/eastings compared to theirs) in a vehicle traveling 90
km/h. Unreasonable, I think. But marketers from Applanix and Trimble, to
name a few, have glossed over their own fine print and convinced
engineers that this is what they provide. They can when the can, and
they can't when they can't. Our clients demand that we will, all the
time. But this is not what I am trying to achieve here. I am only trying
to decrease the error added by the WGS84 LAT/LONG -> ED50
Northing/Easting conversion. I fully understand that there is inherent
error in this process. But companies like Applanix and Trimble are
defining what will be the 'correct' method, whether one likes it or
not.

> 
> PROJ4 is a cartographic tool and is not a geodetic panacea.
> 
> Clifford J. Mugnier, C.P., C.M.S.
> LSU Student ASCE Chapter Faculty Advisor
> and
> National Director (2006-2008),
> Photogrammetric Applications Division
> American Society for Photogrammetry and Remote Sensing
> and
> Chief of Geodesy,
> CENTER FOR GEOINFORMATICS
> Department of Civil Engineering
> CEBA 3223A
> LOUISIANA STATE UNIVERSITY
> Baton Rouge, LA  70803
>                          Home:  (225) 819-0939
>                             Cell:   (225) 236-2327
> Voice and Facsimile:  (225) 578-8536 [Academic]
> Voice and Facsimile:  (225) 578-4474 [Research]
> Honorary Life Member of the
> Louisiana Society of Professional Surveyors
> Member Emeritus of the ASPRS
> Member of the Americas Petroleum Survey Group
> ======================================================
> http://www.asprs.org/resources/GRIDS/
> ======================================================
>
>
> ______________________________________________________________________
> From: proj-bounces at lists.maptools.org on behalf of Roger Oberholtzer
> Sent: Mon 19-Nov-07 16:24
> To: PROJ.4 and general Projections Discussions
> Subject: Re: [Proj] WGS84 to ED50
>
>
> On Mon, 2007-11-19 at 13:57 -0800, Hamish wrote:
>
> > > The Applanix provides this information on their calculations:
> > ...
> > >  Coordinate transformation from WGS84 to mapping frame datum
> > >     dX = 125.098545; dY = 76.000054; dZ = 156.198703; f =
> > > 0.999991695369;
> > >     R1 = 0.000000000000; R2 = 0.000000000000; R3 =
> -0.000005473550;
> >
> >
> > The above R3,f values makes me hesitate a little, but it may be that
> Applanix
> > and Trimble are both preforming a less precise 3-term transform,
> while PROJ is
> > doing a more precise 7-term transform. That would certainly explain
> a 1-4m
> > error.
>
> My understanding is that Applanix is doing a 7 parameter transform.
> What
> I am unsure of is how to get proj to do the same. If it is the
> default,
> then I am curious how the 7 parameters are specified. Are these the
> values in the +towgs84 option? I have another library for this that is
> using 7 config values for its 7 parameter transform, and I would
> expect
> to see similar values in proj.
>
> > Rather than trust either software or method implicitly, it would be
> better to
> > judge the results based on published test points from the Spainish
> and/or
> > Portuguese government mapping office, and double check the validity
> of the
> > 7-terms params from an official document too. Depending on national
> convention,
> > the +- signs of the terms may or may not be switched.
>
> I have been trying to do just that. The person I am doing this for in
> Madrid has provided the test values I am trying to duplicate. Anyone
> know of an official source of test values for Spain?
>
> --
> Roger Oberholtzer
>
> OPQ Systems / Ramböll RST
> Ramböll Sverige AB
> Kapellgränd 7
> P.O. Box 4205
> SE-102 65 Stockholm, Sweden
>
> Tel: Int +46 8-615 60 20
> Fax: Int +46 8-31 42 23
>
> _______________________________________________
> 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
--
Roger Oberholtzer

OPQ Systems / Ramböll RST

Ramböll Sverige AB
Kapellgränd 7
P.O. Box 4205
SE-102 65 Stockholm, Sweden

Office: Int +46 8-615 60 20
Mobile: Int +46 70-815 1696

_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20071120/2f9660f9/attachment.html>