Add depth/altitude term or allow negative cameraHeight

[peterdesmet]

At the TDWG meeting, I've been informed of two use cases of underwater cameras (via @sformel and @sachitrajbhandari). Data from these studies can be expressed in Camtrap DP, but miss a field to express depth.

Those use cases are familiar with Darwin Core, which has minimumDepthInMeters:

The lesser depth of a range of depth below the local surface, in meters.

Note that this is below a local surface and not mean sea level (MSL). Using mean sea level as a reference points is an altitude/elevation. E.g. Darwin Core has minimumElevationInMeters:

The lower limit of the range of elevation (altitude, usually above sea level), in meters.

If depth is typically shared in minimumDepthInMeters (local surface), I think we could use cameraHeight, but with negative values, since that field assumes local surface. We would just have to make that explicit in the definition and allow negative values.

@sachitrajbhandari @sformel @tucotuco feedback welcome.

[tucotuco]

I imagine this is to avoid introducing a new term. I think that as long as you make the definition and examples clear it should be fine.

[ben-norton]

I'm inclined to agree. However, I talked to some fish folks. They don't use elevation on the manner you describe. Depth can be the capture depth or a range depending on the height of the net. It's context. They use a term in a manner specific to their needs. So I wouldn't use that as an argument one way or the other. The interesting part is that you're proposing the same type of context based use. It's the vertical displacement from the local horizon. Positive and negative values indicate vertical placement relative to the horizon and the center of the earth.
If the distance between the center of the earth and the camera is greater than the distance between the center of the earth and local surface horizon (there may be another term), then camera height is positive. Otherwise, it's negative.
I know that's a lot of words for a negative camera height, but the logic is sound.

[sformel-usgs]

After thinking about this a little more, I think cameraHeight as a solution will clash with OBIS standard use of min/maximumDepthInMeters because depth is generally described as positive and camera height would be negative. I also think it will feel "wrong" to marine biologists who routinely use depth as a spatial variable and might keep them from embracing the standard. I bounced this off my brother who is a marine biologist at WHOI and he generally agreed.

So, I think that min/maximumDepthInMeters would still be good to incorporate and I see how min/maximumElevationInMeters could also be useful to give more context to the deployment.

Perhaps map cameraHeight to min/maximumDistanceAboveSurfaceInMeters? Here are some examples of what I am thinking, modeled on the example for maximumDistanceAboveSurfaceInMeters:

For a camera mounted 3m off the ground in a tree at 300m elevation: minimumElevationInMeters: 300, maximumElevationInMeters: 300, minimumDistanceAboveSurfaceInMeters: 3, maximumDistanceAboveSurfaceInMeters: 3.

For a camera mounted on a piling, 3m off the ocean bottom in water 10m deep: minimumDepthInMeters: 10, maximumDepthInMeters: 10, minimumDistanceAboveSurfaceInMeters: 3, maximumDistanceAboveSurfaceInMeters: 3.

There is also nice figure in the recently updated OBIS manual discussing various vertical references: https://manual.obis.org/darwin_core.html#location

@EliLawrence developed that figure and has thought carefully about the confusion over how to use the different terms. Perhaps she can weigh in on this.

[tucotuco]

That figure is in agreement with the recommendations in the Georeferencing Best Practices Guide (Figure 9, copied below). However, I would argue that the best way to encode the location of the camera mounted on a piling is simply: minimumDepthInMeters: 7, maximumDepthInMeters: 7 to avoid any confusion and to make the meaning of depth consistent with other locations no mounted on anything.

[sformel-usgs]

@tucotuco I agree with you about the correct way to describe depth would be 7m in that example. I should have thought more carefully about it.

Another argument for encouraging the measurement of both depth and height off bottom is that they could probably be easily measured during deployment (dive watch, tape measure, ROV sensors) and with more accuracy than inferring either from georeferenced bathymetry later on (e.g. secondary use of the data).

[peterdesmet]

Thanks for the detailed feedback @sformel-usgs and @tucotuco

• I agree that cameraHeight is a match for minimum/maximumDistanceAboveSurfaceInMeters. I will indicate this relationship, see Link cameraHeight to dwc:minimumDistanceAboveSurfaceInMeters #359
• Conceptually, I still think that depth could be expressed as negative values. In my opinion, all purple depth arrows in the figure would have been expressed as negative distanceAboveSurface, but it does break down for burrowed sensors, which would not apply to camera traps. But Darwin Core chose different concepts for distanceAboveSurface and depth, so it might be easier if Camtrap DP did too:
  • It will be easier to map to related concepts (rather than "if negative, this is a depth")
  • It might make adoption easier for marine users
  • I still find it a bit confusing if cameraHeight and depth are used at the same time. How should this be interpreted by users? @sformel-usgs @tucotuco any insight there?

[tucotuco]

But Darwin Core chose different concepts for distanceAboveSurface and depth, so it might be easier if Camtrap DP did too:

• It will be easier to map to related concepts (rather than "if negative, this is a depth")
• It might make adoption easier for marine users
• I still find it a bit confusing if cameraHeight and depth are used at the same time. How should this be interpreted by users? @sformel-usgs @tucotuco any insight there?

I agree with the first two points.

If both depth and distance above surface are used (they shouldn't need to be), it has to be for the situation where the camera trap is mounted at a fixed distance above the bottom of a water body. The depth is still the distance below the water surface and the distances above surface are the distances above the bottom of the waterbody. The depth of the water body at the location of the camera trap would be the depth plus the distance above surface value.

[peterdesmet]

Thanks @tucotuco, I mainly take away "they shouldn't need to be". I'll indicate this as such in the definitions of the terms when I add cameraDepth

[sformel-usgs]

Sorry to be late to the game here. I also agree with the first two points. I also agree with @tucotuco , generally speaking it's probably fine to have one or the other. I think I was defaulting to thinking of ROV camera data, where depth and height off bottom are both routinely measured.