In my "LOST" message, I was trying to add a few clarifications and
comments to David's message as he quoted me. My clarifications and comments
are :
1. 7-parameters are not recommended (by me) for practical usage
in mapping and charting applications.
I may add here that I am absolutely against use of
transformation to "convert" world aerodromes to WGS 84 under ICAO mandated
requirement.
2. Satellite surveys directly provide ellipsoidal heights. As
such, for directly surveyed station coordinates in WGS 84, there is NO need
to "recompute" ellipsoidal heights from the formula h = H + N.
In reality, the above formula is used to compute the
orthometric height (H84) with WGS 84 Geoid as the zero refrence in place of
the MSL..
3. In case of a local datum (other than NAD 83), the
ellipsoidal heights are NOT available. Here, first we compute (from the WGS
84 Geoid) the "true" geoidal height with respect to the local datum
ellipsoid. This "N" combined with "H" (which comes from the "existing" local
vertical datum), provides us "h" for the local datum.
This "indirect" method is resorted only as a necessary evil.
In 70s, we used to take N as zero for the local datums but now we use this
approach as "any estimate of N for the local datum is better than taking N
equal to zero".
All this effort provides lat. long, and "computed"
ellipsoidal height for the local datum which in turn helps to compute
cartesian coordinates U, V, W in the local datum.
4. Bursa (or Bursa-Wolfe) model (7-parameters - 3 shifts, 3
rotations, and 1 scale factor) is only for use between two geocentric
datums, e.g., NAD 83 and WGS 84 and/or two satellite derived geodetic
systems..
When the local datum is non-geocentric, e.g., ED 50, NAD 27,
etc., the 7-parameter model to be used is MOLODENSKY.
5. Other comments:
a. Corelation between parameters is a theoretical
problem and would impact geodetic applications.
b. Rotations computed for the local datums, which cover
"small" areas, would be meaningless and thus
will not be practically useful.
In my opinion, 7-parameters for LUXEMBOURG will not
have any geodetic validity
c. As no OLD classical local datum was defined over
oceans, all horizontal control has to considered as an
extrapolation from land to marine areas. Thus, horizontal datum
transformations over the oceans are to be
used with this "limitation" in mind.
In my opinion, trying to establish 7-parameters over
ocean areas and then to use them is not a practical
approach; this will not gain anything.
d. Transformation does not (and cannot) "improve" the
accuracy of any datum (which is being transformed); thus
"increasing" the parameters only improves the "fit" between the two sets of
coordinates.
e. To avoid any confusion, I started separating datum
transformation (DT) from coordinate conversion (CC).
1) "DT" is between two datums, i.e., ED 50 and
WGS 84.
2) "CC" is within the same datum, e.g., lat &
long (ED 50) to UTM X & Y (ED 50).
f. Almost ALL the data sets from the OLD local datums
have ABSOLUTE accuracy in the meter range and the
available data sets are too sparse and poor. It is then surprising how
transformation shifts can be
computed (or established) to mm.
g. In computing the transformations from the REAL data
sets pertaining to the local datums all over the world,
we in NIMA find it extremely difficult to establish
realistic "sigmas".
Either the accuracy estimates info for the local
coordinates are NOT available or if available, no meaningful
usage can be established for them. Thus, in NIMA, we
assign equal weights, both for the local datum and
WGS 84 coordinates -- a practical simplification for
mapping and charting applications.
h. In 7-paramer solution, scale factor (DS) is also
involved between two datums. In my research (Gary Weigel)
for a continental size local datum, we found the "DS" values to range from
about -29 ppm to +137 ppm. One can
"tailor-make" any set of DX, DY, DZ..
All the above is my own view point and interpretation of this
complex problem. As I see it, most of the users are mixing the theory with
practice and application. Theory I learned at Ohio State but 20 years with
DMA/NIMA have made me learned the real practical side of the picture.
Furthermore, here I not trying to provide a solution to any "specific"
project or problem.
Muni.
> -----Original Message-----
> From: Kumar, Muneendra
> Sent: Wednesday, June 21, 2000 10:07 AM
> To: Couch, David L.
> Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; 'Bill Thoen';
> '[EMAIL PROTECTED]'; Morrison, Doug ; Wiley, Barbara ; Murdoch, David ;
> McCleary, Dennis ; Weigel, Gary R. ; Kumar, Muneendra
> Subject: RE: (GIS-L) Re: Meaning of "MI" Parameters
> Importance: High
>
>
> All:
>
> I was in the middle of writing when suddenly my e-mail diappeared
> from my computer. My search has not failed and I do not find any where !!
>
> If you got it, please ignore it. The COMPLETE message is coming.
>
> Muni.
>
> -----Original Message-----
> From: Couch, David L.
> Sent: Wednesday, June 21, 2000 8:58 AM
> To: 'Bill Thoen'; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Kumar, Muneendra
> Subject: RE: (GIS-L) Re: Meaning of "MI" Parameters
>
> All:
>
> I should point out to everyone that the Bursa-Wolf transformation
> procedure is not recommended for local datums (Muneendra Kumar, personal
> communication). This is due to a couple of different problems when
> estimating the parameters themselves. First, the parameters tend to be
> highly correlated when solved simultaneously. Solving the rotations
> separately from the translations helps to reduce the correlation. Kumar
> wrote a paper on how to do this.
>
> Secondly, there is the geometric problem of using Cartesian
> coordinates. When computing WGS84 Cartesian coordinates, the EGM96 geoid
> model should be included. That is the ellipsoid height is equal to the
> sum of the orthometric height (approximately equal to the height above
> the MSL) and the geoid height. The ellipsoid height is what must be used
> when computing Cartesian coordinates. This is straight forward for WGS84
> values: compute the EGM96 geoid and add it to the elevation and use the
> result for the Cartesian conversion.
>
> But what about local datums such as ED50? The geoid is still
> required when computing Cartesian coordinates. If the local geoid is
> ignored, the systematic error can be significant for "some" applications.
> For the vast majority of applications, I would suggest using the
> Molodensky equations as per NIMA Technical Report 8350.2. They are easy to
> use. Those of you who are interested might see the Ohio State Report by
> Badenkas. The publication date is around 1970. He details the use of
> 7-parameter solutions for local datums.
>
> Whatever the case, a zeroed out Scale factor should not be used.
> This too could be a fairly significant error.
>
> Take care!,
> Dave
>
> ----------------------------------------------
> David Couch,
> Gateway Operations Engineer, NIMA
> 314-260-5073
> [EMAIL PROTECTED]
>
> -----Original Message-----
> From: Bill Thoen [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, June 20, 2000 2:54 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: (GIS-L) Re: Meaning of "MI" Parameters
>
>
> ---------------------------------------------------------------------
>
>
>
> Clifford,
>
> I'm certainly no expert on Geodesy, but I think you didn't
> get
> all the parameters from whoever asked you for help. Seems to
> me
> that all the factors you claim are missing are, in fact, in
> the
> MapInfo projection file. Perhaps a scale factor of zero is
> what
> you mean by a missing (or at least "truncated") value, but
> it
> *is* there.
>
> Adding comments to the the Luxembourg (Bursa-Wolf)
> parameters
> record listed in mapinfow.prj (see appendix H and I in the
> latest
> MapInfo User's Guide) I see:
>
> "LuxGrid (Bursa-Wolf)",
> 8, {projection 8 = Transverse Mercator/Gauss
> Kruger}
> 9999, {means "custom datum"}
> 4, {ellipsoid: 4=International 1924, a=6378388.0,
> 1/f=297.0}
> -185.836, {shift dX, in meters}
> 13.479, {shift dY, in meters}
> -14.527, {shift dZ, in meters}
> 0.441203, {rotation Ex, in arc-seconds}
> 3.027399, {rotation Ey, in arc-seconds}
> -2.607685, {rotation Ez, in arc-seconds}
> 0, {scale correction factor m, in parts per 10^6}
> 0, {longitude of prime meridian}
> 7, {units 7 = meters}
> 6.166666667, {origin Longitude}
> 49.83333333, {origin Latitude}
> 1, {scale factor}
> 80000, {false easting}
> 100000 {false northing}
>
> The MI book doesn't say what in which order the scaling,
> rotation
> and translation are done, but I assume the order for
> performing
> the transform is scale, rotate and then translate since
> these
> ellipsoids have a common center.
>
> According to the manual, the "Simplified Bursa Wolf" is
> "truncated" because that particular transform assumes that
> only
> an ellipsoid and shift parameters are needed.
>
> So what should the scale factor be for Luxembourg
> (Bursa-Wolf)
> transformation? And are the parameters for the
> "International
> 1924" datum the same as the "European Datum 1950" you cite
> below?
> If not, I need to correct my settings. Also to satisfy my
> curiosity, I'd like to try out a couple of coordinate
> transforms
> using MapInfo's parameter file (set up properly) against
> whatever
> you use to see how "grossly inaccurate" MapInfo is. I'm not
> convinced that "computer jockeys" are entirely ignorant
> knowlessmen.
>
> Regards,
> - Bill Thoen
>
> P.S. Good flame, full marks for rebarbative epithets!
>
> [EMAIL PROTECTED] wrote:
> > The parameters you sent are an example of a MI projection
> file for
> > Luxembourg, and it is rather complicated. Bursa-Wolf is
> the name of a
> > mathematical model for performing transformations from one
> specific Datum
> > to another specific Datum. In this case, it refers to the
> transformation
> > from European Datum 1950 to the World Geodetic System 1984
> (WGS84) used by
> > GPS satellites. The parameters are in meters and are
> earth-centered in
> > the Geocentric Coordinate System and refer to a dX,dY,dZ
> translation at the
> > center of the earth AFTER a three-parameter rotation
> RZ,Ry,Rx (in radians
> > or arc seconds) and an overall scalar (dimensionless)
> multiplication is
> > performed FIRST.
> >
> > What is remarkable is that the "MI example file" is
> grossly incorrect!
> > That is indicated by the fact that only six of the seven
> parameters for a
> > Bursa-Wolf Transformation are given, (the Scale Factor is
> not even given),
> > and for the "(Simplified Bursa-Wolf)" it is an obvious
> truncation!!
> >
> > This example file is an excellent lesson of what happens
> when programmers
> > and mathematicians try to play with Geodesy - they obtain
> the usual result;
> > a complete screw-up! Apparently unknown to some "computer
> jockeys," the
> > solution for the seven parameters of a Bursa-Wolf model or
> a
> > Molodensky-Basdekas model always involves a solution for
> the rotations and
> > the scalar FIRST - THEN the translation parameters are
> solved. That means
> > that the rotation parameters (and scale factor) may NEVER
> BE TRUNCATED!!!
> > To the neophyte (read "computer jock"), the rotation
> angles look so small
> > that they appear to be insignificant. However to one that
> works with the
> > math of the actual parameter solutions, one knows that the
> tiny rotations
> > are at the center of the earth! When you examine the
> effect at the surface
> > of the ellipsoid - the magnitude is quite substantial!
> Same thing goes for
> > the scale factor expressed as so many parts per million.
> Tiny numbers with
> > negative exponents, but when you consider the semi-major
> axis is
> > 6,378+ kilometers; the effect is again quite substantial!
> Transformations
> > are affected by such blunders and resultant data will be
> grossly incorrect.
> >
> > Therefore, in the "example MapInfo file for simplified
> Bursa-Wolf
> > parameters," the only thing simple is the simpleton that
> truncated the
> > critical parameters!
> >
> > In regard to your local problem of implementing such data
> for your country,
> > I shall be happy to assist you in determining the
> appropriate parameters if
> > you send your data to me via e-mail. I will then solve
> for a 3-parameter
> > model, a 4-parameter model, and a 7-parameter model and
> provide you with
> > the accuracy results for each model solved.
> >
> > Consider looking at some of my past columns on Grids and
> Datums of
> > different countries at:
> >
> > http://www.ASPRS.org/resources.html
> >
> > Please let me know if I may be of further assistance, and
> consider joining
> > the American Society for Photogrammetry and Remote Sensing
> (ASPRS).
> >
> > Good luck!
> >
> > Clifford J. Mugnier ([EMAIL PROTECTED])
> > Surveying, Geodesy, and Photogrammetry
> > LOUISIANA STATE UNIVERSITY
> > 12408 CEBA Building
> > Baton Rouge, Louisiana 70803
> > Voice and Facsimilie: (225) 388 - 8536
>
>
>
> +----------+ subscribe +--------- GIS-L ---------+
> unsubscribe +---------+
> send email To: [EMAIL PROTECTED] | send email To:
> [EMAIL PROTECTED]
> In the BODY, type: SUBSCRIBE GIS-L | In the BODY, type:
> UNSUBSCRIBE GIS-L
>
> +-------------------------------------------------------------------------
> -+
> + Digest version: GIS-L-DIGEST + Use the same method
> to subscribe +
>
> +-------------------------------------------------------------------------
> -+
> a service of GeoGraph International Corporation
> (http://www.geoint.com)
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
