[OSRS-PROJ] Datum Shifting

Frank Warmerdam warmerda at home.com
Wed Jul 5 16:21:12 EDT 2000

cjmce at lsu.edu wrote:
> The inclusion of the MadTran algorithms is actually incomplete for
> 3-parameter and 7-parameter methods.  In actuality, there is a Bursa-Wolf
> model and there is a Molodensky-Badekas model.  The NIMA implementation in
> MadTran was actually the Americanized version of the Bursa-Wolf 7-parameter
> model.  The European version (such as found in LEICA's "SKI" software for
> geodetic-quality differential GPS solutions), uses the opposite sign for
> the infinitesimal rotations.  Whopping errors will result if you confuse
> the two.  (The only way to avoid errors is to always provide a test point
> in both coordinate systems).


Is the NIMA Geotrans code superceed MADTRAN?  Does it have the same issues
to the best of your knowledge?

I am hoping to get something working that can handle all the datum shifting
methods described in the EPSG database.  It lists the following applicable
methods with the indicated parameters:

9604,Molodenski,,,X-axis translation,Y-axis translation,Z-axis
translation,Semi-major axis length difference,Flattening difference

9605,Abridged Molodenski,,,X-axis translation,Y-axis translation,Z-axis
translation,Semi-major axis length difference,Flattening difference

9603,Geocentric translations,,,X-axis translation,Y-axis translation,Z-axis

9606,Position Vector 7-param. transformation,,,X-axis translation,Y-axis
translation,Z-axis translation,X-axis rotation,Y-axis rotation,Z-axis
rotation,Scale difference

The 7 parameter transformation is is (according to the text) normally
evaluated using the Bursa-Wolf formula.  I gather the Molodenski (and
Abridged Molodensky) formulas are normaly applied directly to the
geodetic coordinates without having to translate to geocentric coordinates
while the geocentric translation, and bursa-wolf transformations are
applied on geocentric coordinates. 

It appears that what I have been doing so far is always transforming to
geocentric coordinates and doing either the geocentric translation (three
parameters), or the bursa-wolf transformation (7-parameters).  Looking at 
the Geotrans code, it calls something called Molodensky_Shift() for points 
not near the poles, and uses geocentric translation or bursa-wolf otherwise.

One thing that freaks me out, is that Molodensky_Shift() does not appear
to utilize the rotational and scaling parameters, only the 3 translation
parameters.  I don't quite understand how this can be legitimate. Is this
the truncation of rotations that you mention is quite inappopriate?

Are the Molodensky and Abridged Molodensky transformations just a way of
reducing the computational cost by skipping the shift to and from 
geocentric coordinates?  If so, can I safely ignore it, and just use
the geocentric translation, and bursa-wolf formulas in geocentric space
if I don't mind it being slower? 

> When you talk about "elevations" being used in a "datum shift," are you
> going to take into account the EGM96 Geoid when going to the WGS 84 Datum?
> What about NIMA's Multiple Regression Equation (MRE) solutions for
> continental areas?

My understanding of geoid, is that it is the real equigravitational surfrace
that is important for modelling sea level and so forth. Is that right?  I 
don't currently intend to deal with shifts between the ellipsoid and the geoid.

When discussing the elevation, I am just pointing out that I must now carry
a Z in and out of the datum shifts whereas this is not the case (of course)
for the projection transforms.  
> Note that the NADCON algorithm is great for the U.S., but what about Canada
> & Mexico?  I believe "Geomatics Canada" has a hefty price tag on their
> transformation package for Maple Leaf applications.  Have you seen the
> eye-popping prices charged by the Norwegians for their datum shift package?
> I think only the U.S. and Australia give their stuff out for free.  South
> Africa's solution is privately marketed by Prof. Charles Merry at the
> University of Capetown.

My understanding is that the NTv1 data distributed by Geomatics Canada is
now free, but that the NTv2 data is expensive.  Furthermore, I understand that
the algorithm to apply the transformation is not protected, and I could
implement it if I wished. However, I am not intending to do so at this
time, as it is substantial additional effort, and it doesn't seem to be
a pressing issue for me.  It might be added at some point in the future. 

> Going 3-D "geodetic" is a big chunk to bite off ...

Well, I am the first to admit that I am not intending to do it _well_.  I am
intending to do it as well as some of the commercial packages I am aware
of (eg. PCI), and what I know of Geotrans.  I believe this is alot better
than not doing it at all, even if it isn't everything that could be hoped for.
Of course, I am listening, and am willing to improve my knowledge of the
issues, and implementation of them if possible.  I would also stress that I
am trying to implement code that can support the sort of transformations 
documented in EPSG (and the derived OGC interfaces).

> I write a monthly column on this stuff with a different country featured
> each month in "Photogrammetric Engineering and Remote Sensing."  If you
> have an interest in this type of stuff, look under "GRIDS & DATUMS" at the
> society's web site:
> http://www.asprs.org/resources.html
> There's over a dozen past columns of mine available in .pdf format for
> downloading and printing with Adobe Acrobat Reader.  This month is on the
> Kingdom of Spain, last month was on the Republic of Ghana.
> Cliff

Finally, I would like to say that I am pleasantly surprised to have someone
of your stature on the list.  I have read some of your posts to USENET with
interest, and accept you as a top expert in the field.  

Best regards,

I set the clouds in motion - turn up   | Frank Warmerdam, warmerda at home.com
light and sound - activate the windows | http://members.home.com/warmerda
and watch the world go round - Rush    | Geospatial Programmer for Rent
OSRS PRoject PROJ Discussion List
To Subscribe: send a message to majordomo at remotesensing.org with 'subscribe osrs-proj' in the body
To Unsubscribe: send a message to majordomo at remotesensing.org with 'unsubscribe osrs-proj' in the body
To Report Problems: send a message to owner-osrs-proj at remotesensing.org

More information about the Proj mailing list