Trips incorrectly show elevation as below sea level

[grant-humphries]

I've come across a few trips that return legs or steps as having an elevation below sea level where it seems unlikely that is true. For the two trips below I've checked those stretches against other sources and they show them as being ~40m higher. These we're initially found on TriMet's production instance (v0.10), but I set up a local instance of v0.20 on my PC and the issue persisted.

See examples in the last leg of this trip, and the latter half of this one.

[abyrd]

We looked into this with @demory at our last routing meeting. It appears that this is due to the vertical datum transformation that we apply to the elevation data. It's not clear why this is happening now but didn't happen in the past. The main thing that changed is that the NED data download service has changed so we're using bulk NED data that we copied to S3 once upon a time. Perhaps the vertical datum of that data is different.

[abyrd]

I'm moving some comments over here from Basecamp for the wider OTP community. In #826 (comment) @grant-humphries is converting some NED-compatible LiDAR data of bridge surfaces to WGS84 vertical coordinates and getting negative numbers, about -4 for the Hawthorne Bridge deck and -12 for the lower deck of the Steel Bridge which is right over the water surface, in the river channel.

The WGS84 system has both an ellipsoid (smooth mathematical surface) and a geoid (irregular estimate of mean sea level). WGS84 height coordinates are relative to the ellipsoid, and the geoid can also be expressed in WGS84 height coordinates relative to the ellipsoid. The geoid varies above and below the ellipsoid by design.

Maps of geoid height show that it's 20-30 meters below the ellipsoid in most of the US:

Which is to say that height above sea level is height relative to the WS84 ellipsoid plus 20 something meters, and negative WGS84 heights are completely normal at low elevations above sea level like Portland (15m).

You can also verify this with the geoid calculator at http://www.unavco.org/software/geodetic-utilities/geoid-height-calculator/geoid-height-calculator.html which shows that at the center of Portland, the geoid is about 22 meters below the ellipsoid, and Portland is about 15m above sea level, so you'd be at -7 meters WGS84 altitude standing on the ground. This places the Hawthorne Bridge deck 3 meters above the typical ground elevation of Portland, and the Steel Bridge lower deck 5 meters below, which makes sense to me.

[abyrd]

Long story short, if we report WGS84 elevations they're going to be negative in coastal areas. We should calculate the height of the ellipsoid above the geoid at the center of the location where OTP is deployed and add that to all reported elevations, and/or only ever use elevations in a relative way.

[abyrd]

I have found an implementation of the ellipsoid -> geoid transform in Geotools. It's in the gt-referencing3D module. http://docs.geotools.org/latest/javadocs/org/geotools/referencing/operation/transform/EarthGravitationalModel.html

We should be able to easily transform coordinates all over the world using this.

I am pushing this ticket back to OTP 1.1 since it doesn't appear to be a bug, just an inconvenient discrepancy between GPS height and height above sea level. @demory @fpurcell let's track this issue here from now on because I believe it's of wider interest to the OTP community.

[barbeau]

I have found an implementation of the ellipsoid -> geoid transform in Geotools

@abyrd Thanks for sharing this! It's something I've been looking for.