Andy,
I am unable to address the minutiae of the MapInfo program, but I submit
that the accuracy of the transformation parameters you list do not meet the
computational differences you quote anyway.
There are two separate and distinct ways to evaluate a Bursa-Wolf 7
Parameter Datum Shift. The difference between the two is in the sense of
the rotation of the elements in the 3X3 direction cosine matrix. The
American/Australian standard is the opposite sign used by many Europeans.
For instance, the Leica software package "SKI" uses the European convention.
The last time I taught my graduate course in coordinate systems when I was
at the University of New Orleans, one of my homework assignments was for the
computation of the 7 parameters between the Luzon Datum of 1911 and WGS 84.
The results of the homework assignment were in close agreement with the
"official" parameters that I published in August of 1999 in "Photogrammetric
Engineering and Remote Sensing," the website address is below my signature
block.
Considering the residuals realized at the co-located points in the various
Philippine Islands, decimeter accuracy for such transformations are not
feasible.
Prof. Clifford J. Mugnier ([EMAIL PROTECTED])
Surveying, Geodesy, & Photogrammetry
LOUISIANA STATE UNIVERSITY
Department of Civil & Env. Engineering
2408 CEBA Building
Baton Rouge, Louisiana 70803
Voice & Facsimile: (225) 388-8536
====================================
See: http://www.ASPRS.org/resources.html
====================================
----- Original Message -----
> Hello list people,
>
> Here's a brain teaser - well it's certainly teased mine anyway!
>
> I've been setting up a custom datum and projection relating to the some
> work I've been involved with in the Philippines, and either I'm
> dropping a
> clanger somewhere, or I'm up against the precision to which MI works.
> The
> datum transformation required is:
>
> Datum shift WGS84 to local datum (Clarke 1866 ellipsoid):
>
> Dx = +119.00m
>
> Dy = +70.00m
>
> Dz = +45.50m
>
> Rx = 0.000
>
> Ry = 0.000
>
> Rz = -0.554" (where -ve indicates a decrease in Longitude)
>
> Scaling 0.219ppm
>
> As this is WGS to local Datum, the signs are reversed for the entry in
> Mapinfow.prj thus:
>
> "Longitude / Latitude (local datum)", 1, 9999, 7, -119, -70, -45.50, 0,
> 0,
> -0.554, 0.999999781, 0
>
> Note that by trial and error I've identified that the rotation about Z
> (Rz)
> has to remain negative, due to a convention difference.
>
> I have a table containing a single trial point in WGS 84 thus:
>
> WGS 84 Input data:
>
> Lat : 12o 21' 56.6073" N Lon: 121o 35' 14.4677" E
>
> Lat : 12.36572420 N Lon: 121.58735210 E
>
> I've then saved a copy as the local datum with the following outcome -
>
> Local Datum (Clarke 1866) Output Data:
>
> Lat : 12.36702300 N Lon: 121.58592900 E
>
> Various other tried and tested geodetic datum shift/transformation
> software
> gives:
>
> Lat : 12.3670283 N Lon: 121.5859289 E
>
> the difference equates to 0.6m in a northerly direction.
>
> My question is whether this is due to a blunder on my part or a
> limitation
> in MapInfo.
>
> I've checked other transformations, eg. WGS84 to ED50 using accepted
> UKOOA
> datum shifts and find differences of 1 or 2 decimetres. Straight
> Lat/Lon to
> Projection eg. WGS84 Lat/Lon to WGS84 based UTM agree to centimetres.
>
> I would be grateful for any feedback.
>
> Regards,
>
> Andy Beckett,
>
> [EMAIL PROTECTED]
_______________________________________________________________________
List hosting provided by Directions Magazine | www.directionsmag.com |
To unsubscribe, send e-mail to [EMAIL PROTECTED] and
put "unsubscribe MapInfo-L" in the message body.
