Re-evaluating recorded height

[peterdesmet]

In response to gbif/dwc-dp#128 and reopening #30

There are three Movebank height fields we want to translate to Darwin Core. In our mapping, we only map one of the fields if more than one is provided. Currently height above mean sea level takes precedence over height above ellipsoid if both are provided.

height above mean sea level

Definition:

The estimated height of the tag above mean sea level, typically estimated by the tag. If altitudes are calculated as height above an ellipsoid, use 'height above ellipsoid'. Example: '34'; Units: meters; Entity described: event

A value 120 is currently mapped to:

• dwc:minimumElevationInMeters: 120
• dwc:maximumElevationInMeters: 120
• dwc:locationRemarks: elevations are altitude above mean sea level

height above ellipsoid

Definition:

The estimated height above the ellipsoid, typically estimated by the tag. If altitudes are calculated as height above mean sea level, use 'height above mean sea level'. Example: '24.8'; Units: meters; Entity described: event

A value 120 is currently mapped to:

• dwc:minimumElevationInMeters: 120
• dwc:maximumElevationInMeters: 120
• dwc:locationRemarks: elevations are altitude above ellipsoid

height above ground level

Definition:

The height above ground level. For altitudes independent of ground level, use 'barometric height', 'height above ellipsoid', 'height above mean sea level' or 'height raw'. Example: '123'; Units: meters; Entity described: event

We currently don't map this.

---

@tucotuco, we now understand that these - in contrast with previous suggestions - should not be mapped to elevation, but to distanceAboveSurface. How would you recommend mapping the above three fields?

[sarahcd]

There is also a fourth elevation term in Movebank height raw: "Raw values for the height of the tag above ellipsoid or mean sea level, typically estimated by the tag. Values are stored as raw text values because non-numeric characters are used or processing is required to derive the correct height estimate. Best practice is to define values in the reference data. Example: '425, 2D fix'; Units: not defined; Entity described: event

These 4 attributes were developed due to the range in how height estimates are reported by different sensors.

GPS elevation estimates are notoriously poor, and it is inaccurate to report them as the minimum and maximum elevation. In most cases no error estimate is provided. And it's important to report the datum. Could verbatimElevation and verticalDatum be used here? (Also discussed in gbif/dwc-dp#128)

[peterdesmet]

GPS elevation estimates are notoriously poor, and it is inaccurate to report them as the minimum and maximum elevation.

I could agree with that ... let's see if we have a good verbatim term.

Could verbatimElevation and verticalDatum be used here?

1. verbatimElevation is defined as:

   The original description of the elevation (altitude, usually above sea level) of the Location.

   @tucotuco is this an appropriate term to report the recorded height of a logger on a bird? I.e. how high the bird was above a reference surface at that point in time?

2. verticalDatum is defined as:

   The vertical datum used as the reference upon which the values in the elevation terms are based.

   @tucotuco does "elevation terms" include verbatimElevation? I.e. are those two terms intended to be used together?

And it's important to report the datum.

@sarahcd do we have that information? Or does datum refer to "above mean sea level", "above ellipsoid"?

[sarahcd]

The default entries for verticalDatum would be something like the following:

• height above mean sea level: mean sea level
• height above ellipsoid: ellipsoid (typically the WGS 84 ellipsoid)
• height above ground level: ground level
• height raw: undefined

This could be further specified for a given case. Here is some more background:

• https://www.movebank.org/cms/movebank-content/corrected-calculations-for-vertical-interpolation-in-env-data
• https://globalgpssystems.com/gnss/geoids-ellipsoids-and-undulation-height-understanding-the-basics/

[tucotuco]

@peterdesmet
The dwc:verbatimElevation can be independent of the dwc:verticalDatum (it can even define its independent vertical datum with something like, "150m s.n.m". The dwc:minimumElevationInMeters and dwc:maximumElevationInMeters are supposed to be referenced to the dwc:verticalDatum. This allows the information as captured verbatim to be shared, and yet also translated into something more standardized.

@sarahcd Elevation and height above the surface are different concepts in Darwin Core, with different terms. The dwc:verbatimElevation term can be used for whatever you like, of course, but any translation should properly populate the non-verbatim elevation terms, the distance above surface terms, and the dwc:verticalDatum term (even if unknown).

[peterdesmet]

@tucotuco so for the height recorded by the logger (above or below a surface, definitely not always on the ground), you recommend to populate the following terms:

• minimumDistanceAboveSurfaceInMeters
• maximumDistanceAboveSurfaceInMeters
• verticalDatum

Correct?

[tucotuco]

@peterdesmet I'm not sure exactly what you are suggesting so I'll try to be explicit.

If the height recorded by the logger is above the physical surface you would populate

minimumElevationInMeters
maximumElevationInMeters
verticalDatum (upon which minimum and maximum elevation are based)
minimumDistanceAboveSurfaceInMeters (above the point given by maximumElevationInMeters)
maximumDistanceAboveSurvaceInMeters (above the point given by minimumElevationInMeters)

I suspect that is not what the logger is recording most of the time. Instead, I suspect it is recording altitude above a verticalDatum. In that case you would populate

minimumElevationInMeters
maximumElevationInMeters
verticalDatum (upon which minimum and maximum elevation are based)

The latter gives you no information about height above the surface unless you use the geographic coordinates with a digital elevation model to estimate the ground elevation and subtract that from the values in minimumElevationInMeters and maximumElevationInMeters.

[sarahcd]

Thanks @tucotuco: I'm still uncertain about solutions wrt my comment above—regardless of the datum used, the height/elevation measurements usually have low accuracy and no error estimate, so using minimum and maximum distances for occurrences seems misleading.

It's correct that height above ground level is not commonly reported, but it does happen, for example with some local telemetry systems or by researchers for specific studies. In these cases processing has already been done to report the height above ground surface and not above the geoid/ellipsoid.