S100WG7 4.20/4.20A Primary Association between FeatureTypes

[rmalyankar]

If these are going to be in the 5.1 UML / schemas, we should resolve them soon.
Regarding S100WG 4.20, Hugh made a suggestion before WG7, which I am pasting below (blue text) with my annotations (red text).

---

@TDYCARHugh
I agree that the FC is missing some detail to ensure consistent 8211 encoding of associations.

Adding the inverse association information to every binding would repeat the information and leave it open for inconsistencies across the bindings.

[A] What if the role types and multiplicity were defined within the association class (also the list of possible feature types) instead of being repeated on each binding.

[B(1)] Also the first role listed in the Association class would be the primary role for use in 8211 encoding.

    <S100FC:S100_FC_FeatureAssociation isAbstract="false">
      <S100FC:name>Structure/equipment</S100FC:name>
      <S100FC:definition>A feature association for the binding between a navigation aid equipment feature and the structure that supports it.</S100FC:definition>
      <S100FC:code>StructureEquipment</S100FC:code>
      <S100FC:definitionReference>
        <S100FC:sourceIdentifier>9000003</S100FC:sourceIdentifier>
        <S100FC:definitionSource ref="IHOREG"/>
      </S100FC:definitionReference>
      <S100FC:role ref="supportedBy" roleType="composition">
        <S100FC:multiplicity>
          <S100Base:lower>0</S100Base:lower>
          <S100Base:upper xsi:nil="false" infinite="false">1</S100Base:upper>
        </S100FC:multiplicity>
        <S100FC:featureType ref="BeaconCardinal"/>
        <S100FC:featureType ref="BeaconIsolatedDanger"/>
        <S100FC:featureType ref="BeaconLateral"/>
        <S100FC:featureType ref="..."/>    placeholder for the rest of the objects which could be part of the association.
      </S100FC:role>
      <S100FC:role ref="supports" roleType="association">
        <S100FC:multiplicity>
          <S100Base:lower>0</S100Base:lower>
          <S100Base:upper xsi:nil="true" infinite="true"/>
        </S100FC:multiplicity>
        <S100FC:featureType ref="Daymark"/>
        <S100FC:featureType ref="DistanceMark"/>
        <S100FC:featureType ref="..."/>  placeholder for the rest of the objects which could be part of the association.
      </S100FC:role>
    </S100FC:S100_FC_FeatureAssociation>

And the bindings could then be simplified to just identify the role and association class.

      <S100FC:featureBinding roleType="composition"> <!-- "association" I think, but if it's in FC_FeatureAssociation it isn't needed here? - RMM -->
        <S100FC:association ref="StructureEquipment"/>
        <S100FC:role ref="supports"/>
      </S100FC:featureBinding>

[B(2)] To give us something to use with the existing S-100 Ed 5.0.0 encoding we could leave the FC as it is and just identify in Part 10a that only the first role listed in the association class needs to be encoded in the 8211.

---

@rmalyankar
Alternatives:
[C] One alternative to [A] is to encode a navigability attribute. The FeatureAssociation in the example above would become:

    <S100FC:role ref="supportedBy" roleType="composition" isNavigable="false">

and

    <S100FC:role ref="supports" roleType="association" isNavigable="true">

[D] Another alternative to [A] is to put the navigability in the binding, making the featureBinding in the example as follows:

      <S100FC:featureBinding roleType="composition">
        <S100FC:association ref="StructureEquipment"/>
        <S100FC:role ref="supports" isNavigable="true"/>
      </S100FC:featureBinding>

In all cases the encoding format specification or the product specification must state whether datasets encode both or only one, just as in UML the navigability is advisory (the encoding format or PS can make it mandatory for the format or product).

I think [B] works as-is, without changing the FC model - it just requires a statement in Part 10a and appropriate changes to the S-101 feature catalogue.

In both [C] and [D] the role types and multiplicity are defined in the association class as shown in the example.

Where the role types and multiplicity are encoded is, I think, a separate issue from how to designate which role the 8211 encoding must use).

Any further ideas about this?

---

@HolgerBothien
Hi all,
I am in favour of alternative D, adding an information in the binding that makes clear which association must be encoded in ISO8211 and which not.
Though, the term navigable has a different semantic the place to add a Boolean attribute to indicate whether the association should be encoded or not seems to be correct.
The name of that attribute can be discussed. I still think ‘primary’ is an option. The term isn’t used in UML, yes that’s true but this rather about encoding than about UML.
Changes to the FC model and schema would be minimal. If the attribute is required (that I would require) older catalogues are not longer compatible with the schema.
That’s why a new namespace URL is needed.

---

@DavidGrant-NIWC

• Recommend this is discussed via a GitHub issue in [Issues · iho-ohi/S-100WG (github.com) (https://github.com/iho-ohi/S-100WG/issues) rather than via email.
• I lean towards Holger’s recommendation but am fine with any workable solution.
• The discussion does not address all the issues presented in S-100WG7-4.20. Separate issues should be opened to address the following:
  • From feature to information type the binding can only be at the feature type.
    • This is a limitation of the FC model, but not of the GFM.
    • This implies the encoding of these associations is supported, but the relationships cannot be validated.
    • Portrayal cannot process information->feature relationships.
      • The Part 9 portrayal input schema does not support association of Information objects to Feature objects.
      • Part 13 does not provide HostInformationGetAssociatedFeatureIDs
• From spatial types to feature types is no possibility to define the bindings in the FC.
  • A limitation of the FC model, but not of the GFM.
  • Lua portrayal must be used to process spatial->feature relationships within portrayal rules.
    • The Part 9 input schema does not support association of SpatialObject to Feature objects.
    • SpatialObject can only be associated with Information objects.
  • Part 13 does support spatial->feature relationships.
    • HostSpatialGetAssociatedFeatureIDs
    • HostSpatialGetAssociatedInformationIDs

---

@rmalyankar
Adding that attribute (be it "primary" or "isNavigable") to the binding instead of the definition of the association allows half the structure/equipment bindings to have the link encoded from structure to equipment and half from equipment to structure. In theory that is not wrong, but in practice...I don't think it would be good practice. At the least it would add extra work in checking the feature catalogue to check the directions are consistent.

I don't see why it should be mandatory at the S-100 level when only one or two products use it. It should be made mandatory (if necessary) at the product specification level, i.e., in S-101.

[rmalyankar]

The above transcription of the email chain between February 12 and February 27 captures all the discussion to date.

Since there has been no resolution, and since this affects only S-101, I propose adopting the interim solution proposed by Hugh in Edition 5.1. The solution can be carried out by updating the S-101 feature catalogue, which is needed anyway.

@TDYCARHugh

To give us something to use with the existing S-100 Ed 5.0.0 encoding we could leave the FC as it is and just identify in Part 10a that only the first role listed in the association class needs to be encoded in the 8211.

Then deal with updating the feature catalogue model later, for Edition 6.0.

[HolgerBothien]

I think as a work around the proposal from Hugh is good. It works as long as the association don't have the same role at each side. For 6.0 we should change the model/Schema.

[TDYCARHugh]

Before we jump in with both feet on this we might want to consider the potential impact.

Normally we write children out before parents (as this was the convention in S-57) however if we use this new pattern and the existing S-101 FC I think it will mean that parents and aggregation features would need to be written out before the children and component features. Or else we would need to swap most of the association role definitions in the S-101 FC.
There is an impact on an test datasets and updates which could become invalid and would have to be created again starting from new editions.

There is also the paper S-101PT9_2022_08.7_EN_Order_of_records_in_S-101_V1.pdf which defines that child features be written before parents and oppositely for update/delete records.