Imprecise values in minimumDistanceAboveSurfaceInMeters

[peterdesmet]

Reviewer of data:

Please consider deleting the minimumDistanceAboveSurfaceInMeters field. In the O_AMELAND dataset the entries
range from -405 (depth) to 6467 (elevation), both of which are unbelievable and make the other entries suspicious.

My answer:

Values in this field are based on what is recorded as height by the GPS tracker. These records can show outliers. We prefer to provide the raw value (as available in the source record), rather than setting a cut-off, which can vary from project to project.

@sarahcd @tucotuco what would you suggest?

[tucotuco]

Same philosophy as for the other issues in this series. Do not mess with the raw data.

However, it is not clear to me that the concept is being followed properly and that the data are correctly mapped. I would expect the GPS to record elevation above the geoid (unless set to use another verticalDatum. This concept is elevation in Darwin Core, not distanceAboveSurface. The two would only be the same if the elevation at the coordinates was zero with respect to the verticalDatum being used. Please record the verticalDatum, of known, or the rest of the data will have an added and unnecessary elevation uncertainty. See Elevation and Distance Above Surface in Georeferencing Best Practices.

[peterdesmet]

The measured values are "height above mean sea level" (or similar UvA-BiTS definition: "Altitude above sea level measured by GPS tag in meters"). Positions can be above land or water, on the ground or in the air.

If I read the instructions in the Georeferencing Best Practices, this seems to align with Altitude:

A measurement of the vertical distance above a vertical datum, usually mean sea level or geoid. For points on the surface of the Earth, altitude is synonymous with elevation.

But how does one record altitude in Darwin Core? Distance above surface makes a distinction between over land or water (and requires a range), Elevation seems reserved for points on the surface of the Earth. The DwC QRG mentions "altitude" in minimum/maximumDistanceAboveSurface, but where and how do I record that the reference point is always the "mean sea level"?

---

Note that in some cases the measured values can be "height above ellipsoid" (not mean sea level). Once I know where to record the "mean sea level" or other other ellipsoid, we should be able to express those as well.

[tucotuco]

Your case is very clearly elevation. You would use distanceAboveSurfaceInMeters=2, for example, for a bird 2m over the surface of a lake at 1000m elevation. Elevations beg for a dwc:verticalDatum. Distances above surfaces are with respect to a local surface, which itself is at an elevation. In the case of a bird flying over the sea, the elevation would be 0, the verticalDatum would be mean sea level and the distanceAboveSurfaceInMeters would be the altitude at which it was flying.

[peterdesmet]

I'm still not entirely following how I should populate the terms then:

• minimumElevationInMeters: 0 (all records)
• maximumElevationInMeters: same as minimumElevationInMeters (so maybe better to not add?)
• verbatimDatum: mean sea level (or some code to express that?)
• minimumDistanceAboveSurfaceInMeters: 2 (variable value derived from source field "height above mean sea level)
• maximumDistanceAboveSurfaceInMeters: same as minimumDistanceAboveSurfaceInMeters (so maybe better to not add?)

[tucotuco]

Are all records over the ocean? Or over locations with elevation=0?

If all you have is altitude, then use that for elevation and forget distanceAboveSurfaceInMeters because you have no way to get that without subtracting the recorded altitude from the calculated elevation from a Digital Elevation Model at the coordinates, and that would introduce error.

Populate every field you can. Don't leave minimums without maximums unless the upper extreme really is unbounded.

[peterdesmet]

No, records can be over ocean and land, but they all have elevation=0 (mean sea level) as the basis for their recorded height. Would I express that as minimumElevationInMeters=x; maximumElevationInMeters=x then (no other fields)?

[tucotuco]

Yes, that is how I would do it, adding a comment to that effect in locationRemarks.

[peterdesmet]

Conclusion:

• Heights above mean sea level are altitudes.
• Since they are in reference to mean sea level (and not the local surface), it is best to express that in min/maxElevation, not min/maxDistanceAboveSurface
• A specific vertical datum is not recorded, and thus cannot be provided in verticalDatum
• To avoid people thinking that the elevations are wrong because they don't match a DEM at the coordinates, provide context in locationRemarks: elevations are altitude above mean sea level
• To avoid people thinking that there is an unknown upper limit to the altitude range, provide the same value in both min and max elevation.

[peterdesmet]

Updated in 8b890d7

Results in: