MikusRL
commented
8 months ago From the usecases we try to put together the below highlighted becomes an issue for the S-101 ENC service delivery:
This is because this is that "second" and "both ways" link encoding for the ENC TXT and TIF files. One is the link mentioned in the ENC attribute (and which is "forgotten" to add to the S-100 dataset discovery metadata) and the other is encoded then in the support file discovery metadata, see the above.
This somehow needs to be solved. Our proposal was to "revert" the linkings for ENCs to what currently is described in S-100 for the support files. It would be an exception, which needs to be:
- recognized by the S-100 standard and adding an attribute to S-100 dataset discovery metadata to enable to use it in product specifications
- described in S-101PS and
- described in S-98
Or if the support files must ALL without any exception be treated in S-100 the same, then the alternative for the longer run could be proposed for the S-101 to remove (disallow) the linking attribute population in S-101 ENC attribute and leave the link only in the support file. This though would mean that an additional attribute would need to be invented for the support file to know to which object in an ENC it needs to be used This then could also solve the implementation issues currently existing in our desktop exercises trying to implement the support files properly in the service. Although this option then even more requires very strict rules about the combinations of files in the Exchange sets - in which scenarios the support files must be included together with the datasets and the other way round.
Personally in my opinion, it would largely simplify things if the effort would be made now to recognize different possible "support files" in S-100, then strive to describe them in S-98 standard as they work for S-57, and then with the S-100 v.6.0.0 to get the dataset discovery metadata linking to the ENC support files. But I need more support here. And definitely there needs to be more people appreciating and understanding this issue, so it can be discussed and solution agreed.
The description in S-98 with the current available linking options could be by recommending:
- populate the linking support file discovery metadata fields in Catalog.xml - supportedResource, with the caveat, that when the dataset discovery metadata set would include/allow supportingResource (or alike), then the former must not be populated any longer;
- always adding the appropriate datasets and their support files in the Exchange set (like in S-57 - always adding both is the "link" for now. This would solve the usecase for the data distributors who do not have an option to read the link from the dataset attribute field because of dataset encryption.
- only one exception exist here for now - if the support file is a new edition and there is no update/change since the last edition metadata in the supportedResource metadata field (e.g. no added or deleted linked datasets), then the supported resource can be without any dataset provided in the Exchange set.
The highlighted in the following image does not work for the distributors with only encrypted files in the service:
For the first highlight in the following image is there an attribute for the S-101 object holding the checksum string of a support file? And for the second highlight what is not mentioned is that the old support files metadata is also to be included, as the old support files metadata attribute supportedResource must be updated as well (the double encoded backward link!)
And question is whether the old support file must be included as well, or would it be treated as a "fileless" part of this support file updating mechanism.
kusala9
Originally posted by @kusala9 in https://github.com/iho-ohi/S-164-Sub-Group/issues/4#issuecomment-1908453652
This is not exactly about the field in the Catalog.xml, because the attribute is not approved at this stage by the S-100WG, but it was tasked by it to discuss this issue in S-164/S-98 SubGroup to try to describe the support files "service" or "life cycle" management (the traditional ones - known for the S-57 files - TXT and TIF) and describe it in S-98 for ECDIS how it should be implemented from producer through the distribution to the ECDIS.
Referencing documents: This presentation slides 12 to 19 discusses the issue of TXT and TIF support files: https://iho.int/uploads/user/Services%20and%20Standards/S-100WG/S-100TSM8/S-100WG8_PRIMAR%20papers%20presentation.pdf This is the document itself: https://portal.iho.int/share/files/488 The above document originates from this S-101 proposal: https://iho.int/uploads/user/Services%20and%20Standards/S-100WG/S-101PT11/S-101PT11_2023_08.14_EN_Support_File_Management_V2.pdf and Presentation: https://iho.int/uploads/user/Services%20and%20Standards/S-100WG/S-101PT11/S-101PT11_2023_08.14A_EN_Support_File_Management_Presentation.pdf
This document shows the usecases which should be used and extended further as necessary to describe what actually is encoded in catalog.xml support file discovery metadata (or dataset discovery metadata in future - v6.0.0 and beyond) and if and when the support file or/and datasets are or must be present in the exchange set together always: https://iho.int/uploads/user/Services%20and%20Standards/S-100WG/S-100TSM9/S100TSM9-4.17_2023_EN_Management%20of%20external%20resources%20extended%20descriptions.pdf
Then some background and earlier discussions in the proposal papers: From this document 4, 5, 6 and 2 (still as heavily linked for S-101) needs to be discussed: https://iho.int/uploads/user/Services%20and%20Standards/S-100WG/S-100TSM9/S100TSM9-4.15_2023_EN_Exchange%20sets%20containing%20only%20external%20resources%20.pdf and the discussions under the bulet points to review and consider: https://iho.int/uploads/user/Services%20and%20Standards/S-100WG/S-100TSM9/S100TSM9-4.18_2023_EN_S100_SupportFileDiscoveryMetadata%20attributes%20supportedResource%20and%20resourcePurpose.pdf