S111: add write support and validation script

[rouault]

on top of PR #13336

[rouault]

@GlenRice-NOAA Do you wish to give a try to this PR before it is merged (same question for #13417 or OSGeo/PROJ#4603)

[GlenRice-NOAA]

@rouault Sorry for the slow response. Last week was a holiday week here. @erin-nagel and @rmalyankar are having a look and will respond here when they have something.

[rmalyankar]

I am working off others' test reports, have not been able to check it myself, but the following questions came up:

The data coding formats should be compared to the S-1XX codelists which are available on the IHO schema server. E.g., for S-111 2.0.0 see the link on https://schemas.s100dev.net/schemas/S111/2.0.0/index.html

The numeric and camel case codes are both available in those files. The question is whether the label ("Regular Grid", etc.) should also be added, I had planned that the <cat:definition> would be what is displayed to the user. I understand there might be a UI issue of presentation e.g., "Regular Grid" looks better than "regularGrid" but that is a separate matter...

Do the error messages report the check id with each message?

[rouault]

I had planned that the <cat:definition> would be what is displayed to the user

you mean in GDAL metadata items? We have for example the raw dataDynamicity with the numeric value and a DATA_DYNAMICITY_MEANING item with a human readable text for a few coded items. We can generalize that approach for other coded items that don't follow it

Do the error messages report the check id with each message?

The S-158 tests are one version behind the one that is implemented here, so there isn't always a 1-1 match. As far as reporting them in warning/error messages, I haven't done that (mostly for the previous reason). The code is annotated with the check ids, so that unit tests can check if the checks that are supposed to be passed have actually be done, but that's not end user visible.

[rmalyankar]

you mean in GDAL metadata items? We have for example the raw dataDynamicity with the numeric value and a DATA_DYNAMICITY_MEANING item with a human readable text for a few coded items. We can generalize that approach for other coded items that don't follow it

I don't have time just now to explore the source code and its ramifications and implications, but since the enumerations in S-111 clause 12.3.5 are provided in an ISO-format codelists catalogue using that file (or a transformation of it) to map numeric codes to names and/or definitions appears to be a good idea. Given the current file, that implies the mapping 2: regularGrid in the corresponding enumeration, amongst other mappings (and the definition would be "Data at grid points forming a regular grid with constant cell spacing").

Similarly for S-104, which has its own codelists file.

<cat:codeEntry>
 <cat:CT_CodelistValue id="S100_HDF_DataCodingFormat_regularGrid">
  <cat:identifier>
   <gco:ScopedName codeSpace="numeric">2</gco:ScopedName>
  </cat:identifier>
  <cat:name>
   <gco:ScopedName codeSpace="urn:mrn:iho:pub:S100:5:0">regularGrid</gco:ScopedName>
  </cat:name>
  <cat:definition>
   <gco:CharacterString>Data at grid points forming a regular grid with constant cell spacing</gco:CharacterString>
  </cat:definition>
  <cat:description>
   <gco:CharacterString>Regular grids are commonly composed of perpendicularly crossing lines of equal spacing on each dimension, creating square or rectangular cells</gco:CharacterString>
  </cat:description>
 </cat:CT_CodelistValue>
</cat:codeEntry>

(The codelists file will not be in the exchange set so tools would need to provide for it separately.)

PS: There is a table online at the link I gave earlier, generated from the codelists file.