Creation of Association Features.

[kusala9]

There are many more association features in S-101 than there are in S-57 (C_AGGR).

• ArchipelagicSeaLane
• Bridge
• DeepWaterRoute
• FairwaySystem
• IslandGroup
• MooringTrot
• RangeSystem
• TrafficSeparationScheme
• TwoWayRoute

this issue is for discussion of how we can create these associations automatically from S-57 (C_AGGR). the main issues/methods I think are:

• If a set of features in S-57 have a C_AGGR linking them together do the features uniquely define which S-101 association they should be associated with. Easy for something like Bridge but possibly ambiguous for some of the routing ones? Need to tabulate which features map to which associations and see if there are any ambiguities
• Evaluate attribution. what is mandatory and what is optional. Are there attributes that need to be carried by the association?
• Is there a validation test/angle here of establishing whether an S-57 C_AGGR and its component features are capable of sensibly defining an equivalent S-101 association?

[Christian-Shom]

This issue specifically relates to Aggregation role types. Agree with Jonathan's analysis. Other questions are:

• it seems that many HOs do not encode C_AGGR in S-57 because ECDIS does not make anything of them. What will DF ECDIS do with S-101 Aggregation? i.e. what happens if a HO encodes individual components of a BRIDGE in S-101, but no BRIDGE Aggregation?
• C_AGGR are not mandatory in S-57 ("may" or "must" in S-57 UOC / warning or error in S-58 if not encoded). Needs to specify if Aggregations are mandatory in S-101 (and level of criticity of the validation checks). The purpose of the above considerations is not to "ignore" S-101 Aggregations, but to see if we could give time to the HOs to construct them (as for Quality of Bathymetric Data attributes versus CATZOC).