Schema: Uncertainty of image coordinates

Since the image and dataset coordinates are given in latitude, longitude, and altitude (and time, if you ask a physicist), it is unclear for which axis the image-coordinate-uncertainty-meters field specifies the uncertainty. The cited Darwin Core definition explicitly defines the coordinate precision as the precision of latitude and longitude. Therefore, I suggest defining this field explicitly as the precision of the horizontal coordinates of the image (-set) given in the fields image-latitude and image-longitude.

Furthermore, I propose adding a field for the precision of the image-altitude-meters, as the precision of the height measurement can be very different from the precision of the horizontal coordinates.

A general solution for all uncertain numeric values in the iFDO schema, would be to use an object defining both the value and precision, for example for image-altitude-meters

"image-altitude-meters": {
      "type": "object",
      "properties": {
        "value": {
          "type": "number"
        },
        "precision": {
          "type": "number"
        }
      },
      "required": [
        "value",
        "precision"
      ]
    }

Adding a precision and accuracy quantifier/qualifier for the image-datetime field is also necessary, as the clocks onboard of ROVs/AUVs are not necessarily synchronized / connected to the ship's NTP-server. This would include fields which describes how (automatically | manual) and when they were last synchronized, as well as fields for a field for quantifying the precision of the clocks. This then allows for “sensor-fusion” between the image and other data, so synchronizing these different data sources, which was mentioned as a use-case by chris.jackett@csiro.au of the MARIMBA framework.

added discuss label

assigned to @tschoening

@kheger @soschindler

1. Documentation in JSON schema has been adapted to specify horizontal uncertainty.
2. Uncertainty of image altitude is hard to quantify and measurements are almost impossible to calibrate in-situ. Hence this field was omitted during previous discussions.
3. Numerical iFDO fields follow the (unwritten?) rule that the values are direct childs and thus easier to access vor e.g. visualization dashboards. Could be an interesting extension though when in the future such dashboards become more metadata-aware?!
4. Date and time values must be in UTC and corrected before creating an iFDO. iFDOs shall contain curated metadata and not the raw, ambiguous values created from mis-operated cameras / sensors. Hence an uncertainty value for time was specifically omitted during invention of the iFDO concept. Information on how the time curation has happened can be added to the field image-curation-protocol and/or image-time-synchronisation