6.12 Additional vertical datums

[rmalyankar]

The TSM8 proposal for additional vertical datums in S-100 metadata has been updated based on discussions in TWCWG, to recommend an S-100 codelist, add "hydrographic zero", delete the two generic datums, and add an epoch attribute for vertical datum.

See the revised proposal for details.

[rmalyankar]

A new edition of ISO 19111 has been published recently, but in the absence of any initiative to update S-100 to use the new edition of ISO 19111, I will provisionally [1, 2] assume that S-100 Edition 5.0.0 will continue to use ISO 19111:2007. Note that representing epoch as "1997.0", etc., will not be possible in S-100 metadata if the type is changed to "date". (The ISO 19111:2007 definition of CD_Datum attribute realizationEpoch (see below) mentions "1997.0" as a possiblity but the implementing schemas (from GML) use the XML schema date type which does not allow that form.)

The time after which this datum definition is valid. This time may be precise (e.g. 1997.0 for IRTF97) or merely a year (e.g. 1986 for NAD83(86)). ...

1. The structure and attributes of the Datum class (including epoch) have changed in the latest edition of 19111. If anyone thinks S-100 should be updated to use the latest edition, now would be a good time to say so.
2. Internal dependencies in the ISO schemas permitting. These are yet to be checked and it is not impossible that S-100 may be forced to update because of internal dependencies in ISO models/schemas..

[DavidGrant-NIWC]

Closed dictionary distribution

• Would need to be as a support file - can't distribute as a catalogue because that isn't supported by Part 4.
  • Alternatively, could be made available via the registry (but would require extensions to S-100 Part 2)

Schema / Encoding

• The codelist encoding of datums is inconsistent with Part 4 encoding of horizontal datum, which uses separate fields to encode horizontalDatumReference and horizontalDatumValue.
  • The proposal is encoding three pieces of information in a single attribute
    1. "other: " is used to distinguish between predefined enumerated values or an extension
    2. "EPSG_" is used to distinguish use of EPSG vice IHO registry
    3. datum is indicated by remainder of encoded value
  • Recommend encoding these separately, similar to horizontal datum
    • verticalDatumReference: "Enumerated", "Extended", or "EPSG" (enumeration)
    • verticalDatumValue: characterstring representing the camelCase or EPSG code, e.g. "meanLowerLowWater", or "5866"

Vertical Epoch

• Why no epoch for sounding datum?
  • May need a class to hold this attribute along with the vertical datum to which it applies.
  • e.g. change type of verticalDatum and soundingDatum to MyVerticalDatumClass
• Part 6 uses ISO 19111:2007, Part 4 should match.
• Name should be realizationEpoch for consistency with ISO / Part 6.

Note that representing epoch as "1997.0" [...]

• The limitation on encoding of epoch is consistent with the S-100 definition of Date (ISO 8601:2004 complete representation, basic format)
  • There is no restriction on precision, e.g. an epoch of "1997.2" is encoded as "19970314",
  • Note that the other example also can't be encoded as shown, "1986" must be encoded as "19860101".
  • Recommend harmonizing encoding of epoch of the geodetic datum with the encoding of the vertical epoch(s)
    • S-100 Date type prefered vice existing CharacterString ("G1762").

[rmalyankar]

I agree that sounding datum should also have an epoch. Will define a class as suggested for both vertical and sounding datums, to hold this and the datum identifier. Will use date as the type for the epoch attribute (the standard XML Schema date type, just like the ISO and OGC schemas).

S-100 has always had different encodings for horizontal vs. sounding/vertical datums (a legacy from S-57, I believe). Note that sounding/vertical datums have an enumeration associated (S100_VerticalAndSoundingDatum) but horizontal datum does not. Any change to the structure of horizontal datum encoding in metadata, or splitting of vertical & sounding datum into ...Reference & ...Value attributes should be a different proposal.

Introduction of dictionaries to hold datums should also be a separate proposal. The last S-100 metadata meeting agreed to the codelist type. Conventions for how the "other: ..." value should be encoded do not change that, nor do they introduce extra standard values - the paragraph in bold about application software not being required to process informtion encoded as "other: whatever" still applies.

[DavidGrant-NIWC]

Introduction of dictionaries to hold datums should also be a separate proposal. [...]

It's in the subject proposal:

[rmalyankar]

It was discussed at the last S-100 metadata web meeting and deprecated.

[DavidGrant-NIWC]

It was discussed at the last S-100 metadata web meeting and deprecated.

Then the proposal should be updated to indicate this.

[rmalyankar]

Revised version of proposal has been posted.

[rmalyankar]

Vertical and horizontal datums use different practices for epoch: "decimal year" (1993.0) and range (1983-2001). The ISO 19111:2007 and GML "date" type works for neither practice. Also, the new Edition 3 of 19111 (which has not been adopted for S-100 Edition 5.0) uses a more generic type (Measure, presumably intended to be a time measure, but allowing "decimal year" encoding).
Either:

• the type of realizationEpoch should be reverted to a string type for S-100 Edition 5.0.0, or
• retained as a date type, with the understanding that it will probably change when ISO 1911 Edition 3 is incorporated.

Either way, additional or revised instructions as to what to encode in the epoch attributes (epoch and realizationEpoch, in dataset discovery metadata and S100 vertical datum) are needed to ensure consistency across product specifications and with common practices elsewhere.

[rmalyankar]

Moved to the IHO GitHub site for WG6:
[Link] (iho-ohi/S-100WG#3)