search

iho-ohi / S-101_Portrayal-Catalogue

Space to discuss and review IHO S-101 Portrayal Catalogue
31 stars 12 forks source link

Hierarchy of metadata (Gap analysis 19OCT23 Row M) #314

Closed DavidGrant-NIWC closed 1 month ago

DavidGrant-NIWC commented 7 months ago

https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/153#issuecomment-1769765446

image

image

DavidGrant-NIWC commented 7 months ago

@alvarosanuy - the buoy symbol is selected based on the color attribute(s) (R,G,R or G,R,G) not based on the system of marks so I don't think that meta-feature requires evaluation within the portrayal rules.

Attribute usage within current portrayal rules:

Attribute Rule(s) Hierarchical evaluation needed?
marksNavigationalSystemOf LocalDirectionOfBuoyage No
horizontalPositionUncertainty None No
verticalUncertainty None No
horizontalDistanceUncertainty None No
horizontalPositionUncertainty None No
orientationUncertainty None No
verticalUncertainty None No
qualityOfHorizontalMeasurement DEPARE03, DEPCNT03, OBSTRN07, QUALIN02, QUAPNT02, SLCONS04, SNDFRM04, WRECKS05 TBD
qualityOfVerticalMeasurement SNDFRM04 TBD
techniqueOfVerticalMeasurement SNDFRM04 TBD
verticalDatum None No

Calling sequence

Rule Called from
DEPARE03 DepthArea, DredgedArea
DEPCNT03 DepthCountour
OBSTRN07 Obstruction, UnderwaterAwashRock
QUALIN02 QUAPOS01
QUAPNT02 OBSTRN07, QUAPOS01, SLCONS04, WRECKS05
QUAPOS01 Coastline, LandArea
SLCONS04 ShorelineConstruction
SNDFRM04 DepthNoBottomFound, OBSTRN07, SOUNDG03, WRECKS05
SOUNDG03 Sounding
WRECKS05 Wreck
DavidGrant-NIWC commented 7 months ago

SNDFRM04 - Symbolization of depth values.

Called from: DepthNoBottomFound, OBSTRN07, SOUNDG03, WRECKS05

Evaluates:

Attribute On Feature On Spatial Quality On Meta-Feature Purpose
techniqueOfVerticalMeasurement Yes N/A QualityOfSurvey Determine whether to add swept sounding symbol
qualityOfVerticalMeasurement Yes N/A QualityOfSurvey Determine whether to add low accuracy symbol ring
qualityOfHorizontalMeasurement N/A Yes QualityOfSurvey Determine whether to add low accuracy symbol ring

Implementation

DavidGrant-NIWC commented 7 months ago

@jeffwootton @alvarosanuy @tomrichardson6 @TDYCARHugh

Low accuracy / Swept Soundings

I don't think this is going to do what you want. I can't evaluate individual sounding points, I can only check each group of soundings against the geometry of each QualityOfSurvey object. This means that every point associated with a Sounding feature must lie within a single QualityOfSurvey feature (or have no overlapping QualityOfSurvey).

This begs the question of why the production system doesn't just copy the attributes from the QualityOfSurvey onto the individual features / SpatialQuality? Alternatively, the modeling could be updated to provide an association from the feature to the QualityOfSurvey. Another option is to add a cartographic attribute (to indicate the soundings are low accuracy and/or swept). The production system should be able to populate any of these automatically.

In the meantime, I'll continue with the implementation of the spatial evaluation, but I don't have any test data.

Low accuracy curves

You would need a requirement to split curves at the boundary of QualityOfSurvey objects in order to guarantee unambiguous inheritence.

As above, I think it would be better to have the production system copy QUAPOS onto each inheriting SpatialQuality object.

Horizontal / Vertical uncertainty

This analysis doesn't address these attributes because the 1.2 portrayal doesn't evaluate them. However, the next release is expected to evaluate them and (optionally) apply their values when evaluating alerts. How this will be done is TBD, but it will require inheriting the horizontalPositionUncertainty and verticalUncertainty from the QoBD (really from the SpatialQuality associated with the QoBD).

Again, this begs the question of why the feature doesn't have an association to the appropriate QoBD feature.

There probably needs to be more explanation in the DCEG about how to handle encoding of fixedDateRange on the SpatialQuality in cases where date-dependent degradation is to be applied. For instance, is it allowed to have a fixedDateRange applied to the SpatialQuality associated with a geometry when the date range doesn't exactly match a value in the SpatialQuality associated with the QoBD? In other words, can there be date-dependent overrides of the value(s) inherited from the meta-feature?

alvarosanuy commented 7 months ago

@alvarosanuy - the buoy symbol is selected based on the color attribute(s) (R,G,R or G,R,G) not based on the system of marks so I don't think that meta-feature requires evaluation within the portrayal rules.

Noted

DavidGrant-NIWC commented 4 months ago

See: https://github.com/iho-ohi/S-101-Documentation-and-FC/issues/153

DavidGrant-NIWC commented 4 months ago

Note that spatial quality may degrade over time; the implementation must handle multiple SpatialQuality instances with different date ranges.

https://github.com/iho-ohi/S-101_Portrayal-Catalogue/issues/362 image

DavidGrant-NIWC commented 4 months ago

Moved here from #363; note for implementation: image

DavidGrant-NIWC commented 4 months ago

Per conversation with @JeffWootton, these three rows will be removed from the table as the attributes don't inherit values from QoS:

image

alvarosanuy commented 4 months ago

Silly question:

Why is required to spatially evaluate geo features against Meta features when the end result is not going to affect Portrayal or the triggering of Alerts? In the M_NSYS case, why is so important to determine the category of the system of marks a navaid is based on if that info is not going to be used by the PC (even if there are different values encoded in the geo and the meta features). It seems like an unnecessary use of computing power .. Same applies to QoNBD - at the moment, irrespective of the prevalent value (Meta or Geo) ECDIS is not expected to do anything with that info (e.g create buffer zones for the visualization of mariners or influence Alerts). I know the use of accuracies on non-bathymetric features could be introduced based on new MSC.530 requirements but I hope our practical interpretation restrict those broad requirements to QoBD and hydrographically relevant features only.

I hope the Table is just a graphical presentation of Hierarchical relationships between Geo and Meta values and not an OEM requirement to continually evaluate (compute) the prevalent attribute value for each impacted feature when the result won't be of use ... Today, the only use case for me is for the uncertainties of hydrographically relevant features (QoBD).

DavidGrant-NIWC commented 4 months ago

The table is necessary so that encoders and implementers understand how these attribute values are determined/populated.

Agree that currently it isn't necessary to perform spatial evaluation since none of these attributes are evaluated by the current portrayal. This is reflected in my comment above, the last column indicates the attributes use within portrayal (shown below).

My main concern in this issue for PC 1.3 was the evaluation of the three attributes inherited from QoS for application to the low accuracy ring and symbolization of approximate points and curves. Jeff's update to the table should remove this concern and eliminated the need for spatial evaluation when portraying those elements.

Today, the only use case for me is for the uncertainties of hydrographically relevant features (QoBD).

Agree, and the need for spatial evaluation even in that case could be removed if the DCEG is updated to always require spatial quality be associated to the geometry of features which are evaluated by alerts.

image

alvarosanuy commented 4 months ago

The table is necessary so that encoders and implementers understand how these attribute values are determined/populated.

Shouldn't the table also include:

maybe others? I haven't done a thorough cehck.

DavidGrant-NIWC commented 4 months ago

Shouldn't the table also include:

  • VerticaDatumOfData - verticalDatum (Meta) & verticalDatum (Geo)
  • SoundingDatum - verticalDatum (Meta) & verticalDatum (Geo)

VerticalDatumOfData is the last row of the table: image

I don't believe there is any way to override the SoundingDatum. As far as I can tell, verticalDatum on a feature always overrides the VerticalDatumOfData. I think there is still ambiguity in the modeling regarding which attributes the verticalDatum applies to, and have previously proposed that the verticalDatum attribute be part of complex attributes that include the values to which it applies. Something like:

etc.

With respect to this issue, the portrayal doesn't evaluate any of the datums, but this could become an issue if we want to alert on clearances.

alvarosanuy commented 4 months ago

Can we close this Issue as 'Implemented in PC 1.3.0'? As far as I understand, all elements to enable the correct attribution of Hydrographic features' Uncertainties are in place. All other entries in the table do not require hierarchical evaluations at this point in time.

DavidGrant-NIWC commented 4 months ago

As far as I understand, all elements to enable the correct attribution of Hydrographic features' Uncertainties are in place.

The inheritance of uncertainties is not in the current PC. It has been prototyped for soundings but is not included in the current catalog. Presumably the prototype implementation will also work for other isolated dangers with point geometries. The solution for curves and especially surfaces is undefined. Note that the DCEG prohibits SpatialQuality to be associated with surface geometries.

This issue is targeted at PC 1.4 because we are awaiting the S-101 alert requirements necessary to meet MSC.530. We may or may not need to implement inheritance to meet those requirements; it depends on whether (or how) the DCEG / encoding requirements are changed.

alvarosanuy commented 3 months ago

The inheritance of uncertainties is not in the current PC. It has been prototyped for soundings but is not included in the current catalog. Presumably the prototype implementation will also work for other isolated dangers with point geometries. The solution for curves and especially surfaces is undefined. Note that the DCEG prohibits SpatialQuality to be associated with surface geometries.

This issue is targeted at PC 1.4 because we are awaiting the S-101 alert requirements necessary to meet MSC.530. We may or may not need to implement inheritance to meet those requirements; it depends on whether (or how) the DCEG / encoding requirements are changed.

Noted, Thanks.

DavidGrant-NIWC commented 1 month ago

This issue is targeted at PC 1.4 because we are awaiting the S-101 alert requirements necessary to meet MSC.530. We may or may not need to implement inheritance to meet those requirements; it depends on whether (or how) the DCEG / encoding requirements are changed.

Direction is that portrayal will not be responsible for applying accuracy to alerts. This will become an OEM responsibility and direction will be provided in S-98 Annex C.

Closing as OBE