4

I have a point cloud in a piece of software and have exported the point in both WGS84 and NAD27 State Plane California Zone II (in US survey feet). The WGS data looks like this, with elevation in meters:

-121.330272 38.547287 5.661467
-121.330272 38.547287 5.646508
-121.330272 38.547287 5.661565
-121.330272 38.547287 5.657426

where as the NAD27 Zone II data looks like this:

2191840.924977 321431.770306 44.012074
2191840.804111 321431.731749 43.962994
2191840.798730 321431.632417 44.012394
2191840.725906 321431.877987 43.998812
2191840.639473 321431.718561 44.001784

I don't understand why the elevation is different and what units it is meant to be in. It's not a simple change from meters to feet. Something else is going on?

EDIT:

I found out that the projection file for the NAD27 Zone II projection used is this in case that helps:

PROJCS["NAD27 / California zone II",GEOGCS["GCS_North_American_1927",DATUM["D_North_American_1927",SPHEROID["Clarke_1866",6378206.4,294.9786982138982]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["standard_parallel_1",39.83333333333334],PARAMETER["standard_parallel_2",38.33333333333334],PARAMETER["latitude_of_origin",37.66666666666666],PARAMETER["central_meridian",-122],PARAMETER["false_easting",2000000],PARAMETER["false_northing",0],UNIT["Foot_US",0.30480060960121924]]

EDIT:

Example code showing difference in converting first point of data.

import pyproj

p1 = pyproj.Proj("+init=EPSG:4326")
p2 = pyproj.Proj("+init=EPSG:26742")

a = (-121.330272, 38.547287, 5.661467)
b = (2191840.924977, 321431.770306, 44.012074)

print "Source point", a
print "Target point", b
print 'Converted: ', pyproj.transform(p1, p2, *a) # different :()

The two coordinate systems are:

Geographic Coordinate System: WGS 84 (EPSG::4326)
Geodetic Datum: World Geodetic System 1984 (EPSG::6326)
Ellipsoid: WGS 84 (EPSG::7030)
Prime Meridian: Greenwich (EPSG::8901)
Angular Units: degree (EPSG::9102)

and

Projected Coordinate System: NAD27 / California zone II (EPSG::26742)
Projection Method: Lambert Conic Conformal (2SP)
    Latitude of false origin: 37.6667
    Longitude of false origin: -122
    Latitude of first standard parallel: 39.8333
    Latitude of second standard parallel: 38.3333
    Easting of false origin: 2e+06
    Northing of false origin: 0
Geographic Coordinate System: NAD27 (EPSG::4267)
Geodetic Datum: North American Datum 1927 (EPSG::6267)
Ellipsoid: Clarke 1866 (EPSG::7008)
Prime Meridian: Greenwich (EPSG::8901)
Linear Units: US survey foot (EPSG::9003)
6
  • 2
    Can you expand on this a bit? Are the input values ellipsoidal heights? The output xy values are in US survey feet. What about the z/height values? What vertical coordinate system are they in? NGVD29, NAVD88, or...? I think I can match the values if I convert the input h to H using geoid12a, thus getting NAVD88, then converting to NGVD29.
    – mkennedy
    Commented Sep 22, 2015 at 20:28
  • 1
    For external checks, NGS website and look for NADCON (NAD83 to NAD27), GEOID12a (geoid undulation aka ellipsoidal height and NAVD88 difference) and VERTCON (NGVD29 and NAVD88).
    – mkennedy
    Commented Sep 22, 2015 at 20:45
  • @mkennedy thanks for the response. I'm a bit of a newbie so I'm not sure. I exported the data from a program called Photoscan and it didn't give any options or settings regarding anything except coordinate system. Commented Sep 22, 2015 at 20:49
  • One is height above or below the ellipsoid and the other is not, check your vertical datum
    – ed.hank
    Commented Sep 23, 2015 at 17:29
  • @user3338197 I've added the coordinate description to the original post does this show what the vertical datum is? Commented Sep 23, 2015 at 18:30

3 Answers 3

5

Agisoft Photoscan states in the documentation that it supports many coordinate reference systems, including most of those in the EPSG registry. I was not able to find a definitive statement that they use GDAL or PROJ.4 for coordinate conversions.

Under the assumption that the input coordinates are WGS84 longitude, latitude and ellipsoidal height (m), I used the GEOID12A online tool to calculate the geoid undulation.

Output from GEOID12A
                         latitude        longitude        N      stddev
Station Name          ddd mm ss.sssss ddd mm ss.sssss   meters   meters
USER LOCATION          38 32 50.23320 121 19 48.97920  -30.490   0.0234

The N value is used in the equation, h = H + N, where h is ellipsoidal height, H is geoidal height (appox. mean sea level), and N is the undulation. So add 30.490 to the input value to approximately get NAVD88. That gives us 36.151467 m.

Because the horizontal coordinates are NAD27 State Plane California II (in US survey feet), it's possible that the z values are in NGVD29 rather than NAVD88. I then used the VERTCON application to check the offset for NAVD88 to NGVD29 for the NAD83 coordinate (it doesn't matter whether you use NAD27 or NAD83--converter isn't that accurate). It was reported as 0.733 m or 2.4 USft. So my results still don't match.

Latitude:   38 32 50.2 (N)
Longitude: 121 19 48.98 (W)

NAVD 88 height:   

Datum shift(NAVD 88 minus NGVD 29):    0.733 meter

I also tried using a 3-parameter, equation-based datum transformation, EPSG::1173 and EPSG::1175. The method used by these transformations convert ellipsoid heights between two geodetic datums. Both transformations returned a new ellipsoid height (on NAD27) of around 22.4 meters, so another mismatch.

4
  • I added the projection file for the NAD27 used to the original post does that clarify anything? Commented Sep 23, 2015 at 16:55
  • Unfortunately, it doesn't say anything about the z values. You might have to talk to Photoscan. Things to ask them besides input: WGS84 + h, output is NAD27 CA 2 + ??: Are you using GDAL and/or PROJ.4? If so, is there a way to get the PROJ.4 strings?
    – mkennedy
    Commented Sep 23, 2015 at 16:57
  • I'm just using pyproj, added the code to the original post. Showing issue converting first example data point from WGS84 to NAD27 CA2 Commented Sep 23, 2015 at 17:58
  • According to vdatum.noaa.gov/docs/datums.html#nad27, the NAD27 itself has a built-in error of up to 10 meters. So you can not treat the NADCON grid shift transformation as exact either. It is just the one that is widely used.
    – AndreJ
    Commented Sep 24, 2015 at 3:55
1

I am pretty confident that the heights of the second dataset are the same Us-ft as the horizontal coordinates (which makes some sense). If you multiply them by 0.30480061, you get a constant difference of 7.75344 meters between both datasets.

Furthermore, the height differences from one point to the next in the list is nearly the same after converting from feet to meters, and 0.3048 without.

For the horizontal shift, I assume they use a low-accurate 3-parameter datum shift.

0

According to this post on the Agisoft forums, it seems that switching between datums is not very well implemented.

Setting aside the vertical component of your coordinates, I couldn't figure out how they got from those WGS84 lat/longs to the NAD27 California Zone 2 X/Y values.

I tried several methods to get from WGS84 -> NAD27 and always ended up around an X value of 2191845-2191847 and a Y value of 321449-321454. I don't know how they ended up with 2191840, 321431.

As it stands, I wouldn't trust the coordinates to be very accurate if you switch datums.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.