[OSRS-PROJ] Datum Shifting

[cjmce at lsu.edu]

Frank,

Comments are imbedded as follows:

>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).

>Cliff,

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

I have not looked at it recently, but I would suggest that it largely be
ignored.

>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
>translation

>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.

The EPSG text is specific to what Mr. Roger Lott of British Petroleum
prefers to do at the approximately one-metre level of transformation
precision for locating shot points and well heads.  Roger is not looking
for the ultimate in geodetic precision, although he has nothing against the
idea as long as it does not get too complicated for the worldwide crew of
surveyors under his supervision.  There are a number of companies in the
"oil patch" that like to follow Mr. Roger Lott's lead.  PetroConsultants,
Inc. would love it if everyone used the "EPSG Standard."  They could sell
more data that way ...  simplifies their life in Geneva ...

>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.

No.  However, that is true with respect what NIMA calls those
transformations.  The NIMA nomenclature in that context, however, is
incorrect.  It is just consistent with decades of DMA/NIMA use of the
misnomers.  Note that when I was there, it was the Corps of Engineers' Army
Map Service and then Army Topographic Command.  We didn't make such a faux
paus until DoD took over ... then after the NRO Spooks took over, well, ...
!

>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?

No, it is not the truncation I spoke of.


>Are the Molodensky and Abridged Molodensky transformations >just a way of
reducing the computational cost by skipping >the shift to and from
geocentric coordinates?

Absolutely.  The "Abridged version" refers to the fact that they ignore the
third component, ellipsoid height.  When you are lobbing 155mm Howitzer
shells for 30 kilometers or less, the blast radius (and crater) will take
care of geoid separation differences quite effectively.

>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?

Yes.

> 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
surface that is important for modeling >sea level and so forth. Is that
right?

Important for terrestrial applications far inland, too.

>I don't currently intend to deal with shifts between the >ellipsoid and
the geoid.

That's fine, but to be consistent; you should NOT be diddling with
seven-parameter shift models, either.  If you want to remain largely a
cartographic application toolbox, I urge you not to dally with the higher
precision methods.
If you stick to a military-type implementation, intended for cartographic
applications at the 1:50,000 source scale and smaller, a simple three
parameter datum shift implementation is more than adequate for accuracies
around +/- 25 meters.

>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.

You should use the elevation as being equivalent to ellipsoid height for a
3-D solution.  It is preferable, anyway, and for a +/- 25 meter error
budget - it's simpler.
The "new" ellipsoid height on the new datum will probably give a number of
cartographers no small amount of heartburn, but that's good.  They SHOULD
read more!
... especially my stuff.  I consider myself a cartographer; not a
geodesist.

> 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.

I was attempting to play Devil's Advocate in that paragraph.  I suggest
that you leave the higher-precision models to the individual user to keep
this stuff manageable for cartographic apps.

> 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.

The PCI implementation is the old "BP Projection Module" License.  It was
the early foundation of the EPSG attempts later improved upon by the same
guy, Mr. Roger Lott.


>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 would recommend that you NOT try to emulate the EPSG system.  It has
problems, although fewer and fewer as Roger and I talk from time to time.
The EPSG model is essentially intended for the professional surveyor with
R.I.C.S. (Royal Institute of Chartered Surveyors), after his name, and not
for a general purpose cartographic utility.

> 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,

>Frank Warmerdam, warmerda at home.com

Hope this advice helps.

Cliff


----------------------------------------
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