<HTML dir=ltr><HEAD><TITLE>RE: [Proj] WGS84 to ED50</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.2900.3199" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText43590 dir=ltr>
<DIV dir=ltr><FONT face="Times New Roman" color=#000000 size=2>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 ...</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>See:   <A href="http://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350_2.html">http://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350_2.html</A></FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT> </DIV>
<DIV dir=ltr><FONT size=2>C. Mugnier</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> proj-bounces@lists.maptools.org on behalf of Roger Oberholtzer<BR><B>Sent:</B> Tue 20-Nov-07 07:21<BR><B>To:</B> proj@lists.maptools.org<BR><B>Subject:</B> RE: [Proj] WGS84 to ED50<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>On Mon, 2007-11-19 at 16:43 -0600, Clifford J Mugnier wrote:<BR>> I have been reading this thread with some amusement, as datum shifts<BR>> are only a compromise to begin with, and attempting to achieve better<BR>> than 1-2 meters with even a 7-parameter transformation is a totally<BR>> unreasonable expectation.  The original data for the classical datum<BR>> is not that good!<BR><BR>The conversion is fully in software. So I am trying to get, if possible,<BR>one piece of software to do what another one does. I do not think there<BR>is anything odd or unreasonable in attempting that. My assumption in<BR>going in to this is the I am doing something wrong (based on previous<BR>experiences...). I have or have not specified something, or I have<BR>specified something incorrectly. Should I be able to correct this, proj<BR>may very well provide the results I seek. I would be a fool NOT to try<BR>to correct any errors I have made. Thus, my question.<BR><BR>> Matching another transformation is a reasonable expectation, but it<BR>> could be (likely), that the "client" is attempting to match actual<BR>> observations with Trimble/Applanix gear working directly in WGS84<BR>> rather than a Trimble/Applanix algorithm!  European Datum 50 (ED50)<BR>> was "cooked up" in 1950 by Geodesists at the U.S. Army Map Service<BR>> after WWII using geodetic surveys of Spain and Portugal performed over<BR>> the prior 50-75 years!  That stuff wasn't that good!<BR><BR>The conversion I am trying to match is using a text file with WGS84<BR>lat/long values from a GPS receiver. The absolute accuracy of these is<BR>irrelevant for this test. They are simply a set of numbers. Trimble and<BR>Applanix PC software convert these lats/longs into northings and<BR>eastings, claiming that these Northings and Eastings are in ED50 for<BR>Spain and Portugal. They only have available for this purpose the<BR>lats/longs as provided, and whatever ED50 code is in their respective<BR>libraries.<BR><BR>> Try reading my columns on the Grids and Datums of Spain and Portugal<BR>> at:  www.ASPRS.org/GRIDS  and you'll get a better appreciation of the<BR>> complexity of the problem being sought with a mere 7-parameter<BR>> transformation.  (Spain is July, 2000, and Portugal is April, 2002)<BR><BR>I will make a bee line for this.<BR><BR>> Combining Applanix and Trimble gear is cutting-edge geodetic equipment<BR>> commonly used for Real Time Kinneatic (RTK) Aerial Photography for<BR>> hair-splitting accuracy.  That stuff is working directly in WGS84<BR>> Broadcast Ephemeris and is then re-adjusted in post-processed mode<BR>> with the Precise Ephemeris a couple weeks later.<BR>> <BR>> That's NOT going to "match" data that's 75-100 years old!<BR><BR>That is not what I am trying to do. The WGS84 values are what they are.<BR>The Applanix, as you correctly state, provides lats/longs that are very<BR>accurate. But when it comes to converting these lats /longs to Northings<BR>and Eastings, it is down to math of the type proj does.<BR><BR>BTW, we measure the location of a road measurement vehicle, where<BR>customers are unfortunately demanding absolute accuracy of < 1 meter<BR>(our northings/eastings compared to theirs) in a vehicle traveling 90<BR>km/h. Unreasonable, I think. But marketers from Applanix and Trimble, to<BR>name a few, have glossed over their own fine print and convinced<BR>engineers that this is what they provide. They can when the can, and<BR>they can't when they can't. Our clients demand that we will, all the<BR>time. But this is not what I am trying to achieve here. I am only trying<BR>to decrease the error added by the WGS84 LAT/LONG -> ED50<BR>Northing/Easting conversion. I fully understand that there is inherent<BR>error in this process. But companies like Applanix and Trimble are<BR>defining what will be the 'correct' method, whether one likes it or<BR>not.<BR><BR>> <BR>> PROJ4 is a cartographic tool and is not a geodetic panacea.<BR>> <BR>> Clifford J. Mugnier, C.P., C.M.S.<BR>> LSU Student ASCE Chapter Faculty Advisor<BR>> and<BR>> National Director (2006-2008),<BR>> Photogrammetric Applications Division<BR>> American Society for Photogrammetry and Remote Sensing<BR>> and<BR>> Chief of Geodesy,<BR>> CENTER FOR GEOINFORMATICS<BR>> Department of Civil Engineering<BR>> CEBA 3223A<BR>> LOUISIANA STATE UNIVERSITY<BR>> Baton Rouge, LA  70803<BR>>                          Home:  (225) 819-0939<BR>>                             Cell:   (225) 236-2327<BR>> Voice and Facsimile:  (225) 578-8536 [Academic]<BR>> Voice and Facsimile:  (225) 578-4474 [Research]<BR>> Honorary Life Member of the<BR>> Louisiana Society of Professional Surveyors<BR>> Member Emeritus of the ASPRS<BR>> Member of the Americas Petroleum Survey Group<BR>> ======================================================<BR>> <A href="http://www.asprs.org/resources/GRIDS/">http://www.asprs.org/resources/GRIDS/</A><BR>> ======================================================<BR>><BR>><BR>> ______________________________________________________________________<BR>> From: proj-bounces@lists.maptools.org on behalf of Roger Oberholtzer<BR>> Sent: Mon 19-Nov-07 16:24<BR>> To: PROJ.4 and general Projections Discussions<BR>> Subject: Re: [Proj] WGS84 to ED50<BR>><BR>><BR>> On Mon, 2007-11-19 at 13:57 -0800, Hamish wrote:<BR>><BR>> > > The Applanix provides this information on their calculations:<BR>> > ...<BR>> > >  Coordinate transformation from WGS84 to mapping frame datum<BR>> > >     dX = 125.098545; dY = 76.000054; dZ = 156.198703; f =<BR>> > > 0.999991695369;<BR>> > >     R1 = 0.000000000000; R2 = 0.000000000000; R3 =<BR>> -0.000005473550;<BR>> ><BR>> ><BR>> > The above R3,f values makes me hesitate a little, but it may be that<BR>> Applanix<BR>> > and Trimble are both preforming a less precise 3-term transform,<BR>> while PROJ is<BR>> > doing a more precise 7-term transform. That would certainly explain<BR>> a 1-4m<BR>> > error.<BR>><BR>> My understanding is that Applanix is doing a 7 parameter transform.<BR>> What<BR>> I am unsure of is how to get proj to do the same. If it is the<BR>> default,<BR>> then I am curious how the 7 parameters are specified. Are these the<BR>> values in the +towgs84 option? I have another library for this that is<BR>> using 7 config values for its 7 parameter transform, and I would<BR>> expect<BR>> to see similar values in proj.<BR>><BR>> > Rather than trust either software or method implicitly, it would be<BR>> better to<BR>> > judge the results based on published test points from the Spainish<BR>> and/or<BR>> > Portuguese government mapping office, and double check the validity<BR>> of the<BR>> > 7-terms params from an official document too. Depending on national<BR>> convention,<BR>> > the +- signs of the terms may or may not be switched.<BR>><BR>> I have been trying to do just that. The person I am doing this for in<BR>> Madrid has provided the test values I am trying to duplicate. Anyone<BR>> know of an official source of test values for Spain?<BR>><BR>> --<BR>> Roger Oberholtzer<BR>><BR>> OPQ Systems / Ramböll RST<BR>> Ramböll Sverige AB<BR>> Kapellgränd 7<BR>> P.O. Box 4205<BR>> SE-102 65 Stockholm, Sweden<BR>><BR>> Tel: Int +46 8-615 60 20<BR>> Fax: Int +46 8-31 42 23<BR>><BR>> _______________________________________________<BR>> Proj mailing list<BR>> Proj@lists.maptools.org<BR>> <A href="http://lists.maptools.org/mailman/listinfo/proj">http://lists.maptools.org/mailman/listinfo/proj</A><BR>><BR>><BR>><BR>> _______________________________________________<BR>> Proj mailing list<BR>> Proj@lists.maptools.org<BR>> <A href="http://lists.maptools.org/mailman/listinfo/proj">http://lists.maptools.org/mailman/listinfo/proj</A><BR>--<BR>Roger Oberholtzer<BR><BR>OPQ Systems / Ramböll RST<BR><BR>Ramböll Sverige AB<BR>Kapellgränd 7<BR>P.O. Box 4205<BR>SE-102 65 Stockholm, Sweden<BR><BR>Office: Int +46 8-615 60 20<BR>Mobile: Int +46 70-815 1696<BR><BR>_______________________________________________<BR>Proj mailing list<BR>Proj@lists.maptools.org<BR><A href="http://lists.maptools.org/mailman/listinfo/proj">http://lists.maptools.org/mailman/listinfo/proj</A><BR></FONT></P></DIV></BODY></HTML>