Grouped Soundings and Quality of Bathymetric Data

[JeffWootton]

Paper S-101PT12-06.2, submitted by Australia, included an issue related to the grouping of soundings and their relationship with the underlying QualityOfBathemetricData features. The relevant excerpt from the Paper is as follows:

5. AHO has identified a possible confusing issue with the grouping of Soundings and a possible need for Software Producers to create QualityOfBathymetricData Composition associations automatically on export of products. The way that sounding grouping is handled by software may need to change.
AHO believes that the grouping of soundings should be related to the creation of QualityOfBathymetricData Composition association grouping. These groups would be based on the features that have identical Spatial Quality values rather than feature attribution. This could then be possibly automated as grouping is now in S-57. This would then ensure that the associations are correctly made and the indication of accuracy of data within the area is defined.
The grouping of soundings based on feature attributes such as SCAMIN after associations have been made will create a confusing output in a pick report of an ECDIS for a mariner. An example of this will be the grouping of soundings with differing feature attributes for SCAMIN. Within an association area there may exist 4-5 individual groups based on the feature attributes.
If grouping was managed by the composition associations, then these different feature attributes won’t then be visible to a mariner, as the group has Spatial Quality alone as the defining attribution. AHO would like to discuss the best approach to this encoding.
AHO wishes to discuss the purpose of the Composition Association for an ECDIS and the impact it would have if we were to remove this requirement. This would allow sounding grouping to remain unchanged to today.

S-101PT Members are invited to comment on this issue.

[RichardCoyles]

I agree grouping soundings that have identical Spatial Quality values rather than feature attribution (typically SCAMIN) would be less confusing and would therefore aligning with QualityOfBathymetricData Composition associations.

[benhazelgrove]

As the compilers/producers will need to create a QOBD Composition and effectively associate sounding features to that singular QOBD area, the mariners should expect a pick report to display those with Spatial Quality information related to that area only. What could happen in a dataset is that 2 separate areas of QOBD could have features that also have the same Spatial Quality information which would mean that grouping as we do today could still link those features outside their QOBD area. The best approach would be to use the Composition's created within an S-101 product as the sounding group.

[benhazelgrove]

Attached is a dataset where the Soundings have been grouped within the Quality of Bathymetric Data areas that they belong to. No sounding groups cross outside of any one area.

This was done by manually selecting the QOBD area and using it to select sounding geometry within the area in order to group them. Ideally, software tools should be able to do this automatically on export. The groups have still been created based on Feature attribution and not Spatial Quality due to the limitation of the CARIS tools to include this in grouping. Suggest that it be refined to group identical Spatial Quality values within singular QOBD areas only would be the ideal result.

This DS can be tested in ShoreECDIS for hierarchy of metadata.

101AU005CNS01.zip

[DavidGrant-NIWC]

@benhazelgrove, thanks for the data!

Could you make one change: for at least one area of QoBD, further sub-divide the soundings so that one set uses the SpatialQuality from the QoBD, and the other set overrides the quality from the intersecting QoBD by associating an instance of SpatialQuality with the multipoint geometry.

@JeffWootton: to me, the data model could be modified to better support the production and portrayal:

• Why not just associate the Sounding feature to the QoBD?

  • Would also require removing the capability to associate SpatialQuality with the geometry.
  • 

• Or, require that the multipoint geometry has an association to the SpatialQuality (which is also referenced by the QoBD)?

  • that is, change the multiplicity of INAS in MRID to 1..1
  • btw, I don't think the upper multiplicity of INAS should be "*", but maybe I'm missing something.

With the current modeling you can have a set of soundings which have spatial quality which differs from the quality shown in the ECDIS legend.

[DavidGrant-NIWC]

A similar issue exists with inheritance from QualityOfSurvey. For instance:

The emphasized highlighted portions of the depth contour have spatial quality associated with the curve geometries. These set the Quality of Horizontal Measurement to Approximate. Per the "Hierarchy of Metadata" table in the DCEG, the non-highlighted portions should inherit from the QualityOfSurvey (which doesn't exist in this dataset). If it did exist, the geometries would have to be split on the boundaries of the QualityOfSurvey objects.

Soundings also need to evaluate QualityOfSurvey (to lookup the value of qualityOfVerticalMeasurement); this is to (possibly) add the low accuracy ring to the sounding. This means that if QualityOfSurvey is provided then the positions of the Sounding feature must all fall within a single QualityOfBathymetricData feature AND a single QualityOfSurvey feature (if present).

[JeffWootton]

@DavidGrant-NIWC: The problem is that QoBD is intended to indicate "An area within which a uniform assessment of the quality of the bathymetric data exists" (definition for the QualityOfBathymetricData meta feature). While this will apply to the majority (if not all) bathymetry in the area, it does not necessarily mean that every bathymetric feature in the area has the same quality. The bathymetry may be comprised of information taken from multiple surveys covering the same area conducted at different times and because an existing charted (shoal) depth has not been disproved by a new survey it needs to remain on the chart with its appropriate quality indicator; or individual areas such as isolated shoals, rocks or wrecks may be further investigated (swept or survey interlining) to provide isolated instances where the quality of the bathymetry is higher than the overall quality indication. From this perspective your statement "With the current modeling you can have a set of soundings which have spatial quality which differs from the quality shown in the ECDIS legend" is a cartographic requirement and this is why the requirement is to associate the bathymetric features to SpatialQuality rather than QoBD so as to provide this flexibility. An important thing to note here is also that the majority (if not all) of the bathymetric features within a QoBD feature will be associated to the same SpatialQuality feature as the QoBD itself is.

I think the INAS question is best addressed to Holger although I think that, given that the association of soundings to SpatialQuality is only required for soundings of depth equal to or less than 30 metres, the lower bound 0 is correct.

[DavidGrant-NIWC]

Jeff, thanks for the info.

• My suggestion to change the lower bound of INAS to 1 is intended to provide an explicit association of spatial quality to each multipoint geometry associated with each sounding feature. This would eliminate the need for portrayal to figure out which QoBD encloses the points associated with the sounding feature.
  • The meta-feature guidance doesn't exclude soundings deeper than 30 meters, so those currently inherit the spatial quality associated with the enclosing QoBD feature (assuming no INAS is present). My suggestion would just copy/duplicate this association to the geometry as well as the QoBD.
  • The production system could automate the inheritance (copy the spatial quality from the enclosing QoBD to each sounding geometry, provided the geometry doesn't already have an association).

Although this would change the data model, it doesn't change the FC since the FC doesn't encode information about relationships to spatial objects.

Current Model

The outlined area represents the (implied) spatial relationship, geometry 1 inherits the quality from the enclosing QoBD, geometry 2 overrides the quality of the enclosing QoBD:

Processing required:

• For geometry 2, no spatial evaluation is needed since the quality can be determined via the provided association.
• For geometry 1, evaluate each QoBD feature against the sounding geometry until an intersection is found. then lookup the quality via the association from QoBD.

Proposed Model

The association to spatial quality 1 is made explicit (the red line); spatial evaluation is no longer required:

Processing required:

• Lookup the spatial quality for each geometry via the provided association.

Other Considerations

The concept could likely be extended to support other features (Wrecks, Obstructions) / geometries (Coastline), but I haven't given it much thought.

[TDYCARHugh]

I have comments on several things I see in this issue.

Sounding Grouping
A sounding feature has a set of attributes and relates to a Multipoint geometry. The multipoint geometry can have one or many points included in it. The multipoint geometry can be associated to information types. When soundings are grouped, like sounding features are merged resulting in less Sounding features where the grouped ones have more points in the multipoint. You cannot group soundings that have different attributes or different information links. That is the way the data model is defined it has nothing to do with data production tools.

Grouping by SCAMIN vs grouping by QOBD.
It cannot be one or the other. You can group by QODB but you will end up with separate groups within each QOBD where any Sounding attribute (ie SCAMIN) is different.

If sounding multipoints have explicit links to Information types then the grouping will only group soundings with like Feature attributes and like information associations.

Changing the 8211 encoding to try to restrict multipoint associations to Information types
It is a possible avenue but I would advise against it because this is an implementation change that could have an impact on any system that reads or writes these files. If there is a desire to add another information type in the future (for example an information type that indicates a data source) and use it with a multipoint then it would require implementers to change the software. If we wish to restrict how a Sounding multipoint is related to information types I suggest doing this with a validation check which would be easier to revise if needed. Leave the INAS as it is.

Why we we talking about forcing links to quality information on every object
It seems that part of this discussion is about being able to determine the exact quality of every geometry and to do so efficiently such as traversing a relationship instead of doing a spatial query. I agree that if the information is necessary then it make sense to have an explicit association since spatial queries can be complex to implement and costly on performance.

However, I question the need to know the explicit accuracy on every geometry. I believe that the premise in S-57 and in S-101 is that data is fit for purpose (navigation) with a means to identify the exceptions. I would not expect low accuracy rings to be needed on every sounding. I think we only need to know which soundings are low accuracy or have significantly different accuracy then the ones around them. A mariner should be able to turn on accuracy areas or do a cursor pick from quality metadata and get the impression of overall quality, isolated differences should be easy to determine.

The soundings that would need low accuracy rings should be separated into their own groups with either a feature attribute or link to quality information that indicates how bad it is. In other words only draw low accuracy rings on soundings attributed as being low accuracy, all the other soundings (those without any explicit quality info) are drawn normally. If a producer knows that the quality is consistent and fit for purpose in the entire ENC then they should not need to bloat the file with unnecessary information and associations.

[DavidGrant-NIWC]

I'd be happy with any change which resolves the following issue, ideally by eliminating the need for spatial evaluation.

• S-100 does not currently support determination of the spatial relationship between a single coordinate of a multi-point geometry and some other geometry (the geometry of a meta-feature).
  • This means that any attribute the sounding feature inherits from a meta-feature must be unambiguous (the points comprising the sounding must all fall within a single meta-feature, or the multiple meta-features must share a single value for the inherited attribute).
  • Soundings can inherit some attributes from QoBD:
    • spatialAccuracy and qualityOfHorizontalMeasurrement
  • Soundings can also inherit from QualityOfSurvey
    • qualityOfHorizontalMeasurement and qualityOfVerticalMeasurement

So, in the absence of any other changes we need all the points of a Sounding to fall within a single QoBD and a single QoS (if present). This restriction is necessary to support implementing spatial evaluation in the portrayal.

If we are requiring the geometry to fall within a single meta-feature, why not provide an explicit association between the feature and the meta-feature? Then the portrayal doesn't have to do spatial evaluation.

• Sounding <-> QoBD <-> QoS
• Wreck <-> QoBD <-> QoS
• Coastline <-> QoBD <-> QoS
• etc.

[TDYCARHugh]

I am also interested in removing the need for spatial evaluation from both the ECDIS and Production.

What are the use cases where portrayal would need to examine meta data? I think we should be looking at these cases and see if there is another option without adding a lot of unnecessary overhead in processing and space.

If the portrayal/Alert logic does not need to determine information from meta data then perhaps it would not matter if the multipoints are not split at QOBD boundaries. There might be other reasons to split these for data management or just to be tidy.

If one or a few individual Sounding/Wreck/Obstruction has low accuracy how would you propose the QODB Area features be managed. Would you make very tiny islands around each of these? Probably not.

If we can define that features which are exceptions to the overall metadata must carry attributes or explicit links to information types (quality). Then the portrayal would only need to look for features with explicitly defined low accuracy and portray those differently. Is there any other reason to query surrounding meta data?

I suppose the open question would be "How does portrayal know that the related quality is worse than the surrounding meta data?" Validation checks could be made to find redundant encodings where an explicit link to quality is the same as the quality area the goem is within. ie redundant encoding. Or the portrayal could just check if the quality is low or worse than some threshold and then portray differently.

[DavidGrant-NIWC]

I think I haven't fully understood the S-101 modeling wrt meta-features. See this related issue: #153

Once I'm on the same page with Jeff I'll come back to this.

[benhazelgrove]

Could you make one change: for at least one area of QoBD, further sub-divide the soundings so that one set uses the SpatialQuality from the QoBD, and the other set overrides the quality from the intersecting QoBD by associating an instance of SpatialQuality with the multipoint geometry.

101AU005CNS01.zip

@DavidGrant-NIWC I have attached an updated dataset. In the marina centered on co-ordinates 16-55.13S 145-46.9E, there is a ZOC B QOBD area. Within this area there 3 groups of soundings that are based on Feature attributes. I have amended one set of these soundings to contain Spatial Quality information that has different values to the area's composition.
Of note: The area directly east of this (A1 area) contains an example of soundings that only have Vertical Uncertainty populated within their Spatial Quality attributes and no indication of Horizontal accuracy. This could be another use case example of the Spatial query needing to review the point feature for the Vertical element and referring to the Meta feature for the Horizontal component.

The grouping of the Soundings within this dataset was problematic. As a Data Producer, I needed to identify all the QOBD areas and select each one of them individually to select the soundings within that geometry in order to group them together. This was onerous and time consuming. There was 156 QOBD areas, and each one needed to be addressed separately. The downside of this is that it can be completed correctly the first run through, but a secondary user could choose to group soundings via a Validation check (Select all) command and group any that have been left ungrouped as they are singular to their area but have common attributes with other soundings in other areas. I don't see this as a viable option due to the time it takes to address every area and the soundings within it.

I was only able to add Spatial Quality information to the Sounding features as an attribute in the CARIS software. A user is unable to select a group of Soundings and create an Information Object - Spatial Quality to associate them. I am under the assumption that it is creating the Spatial association on Export by reviewing the attributes populated for each sounding.

[DavidGrant-NIWC]

Sorry it's taken so long to get to this.

Here's a pic where the uncertainty is drawn as a translucent orange circle around each sounding. I've picked on a Sounding feature that has SpatialQuality associated with the geometry:

I have amended one set of these soundings to contain Spatial Quality information that has different values to the area's composition.

Thanks. It's hard to tell from the pic, but I do see that those soundings have an uncertainty of 55m, whereas the uncertainty on the others (inherited from the QoBD) is 50m.

I see that there are some uncertainties encoded as "unknown". This poses some questions and challenges:

• What is the uncertainty applied to the alert in this case?
• If "unknown" is coded on the quality associated with the spatial of the sounding, do we look at the QoBD to try to get a value?
  • I assume that we won't, but if we do, how do we handle the case where there are multiple date ranges in each? We would need to match the dated uncertainty entry between the Sounding and the QoBD. This means the DCEG would need to require that these match one another.

Of note: The area directly east of this (A1 area) contains an example of soundings that only have Vertical Uncertainty populated within their Spatial Quality attributes and no indication of Horizontal accuracy. [...]

The portrayal will use the horizontal value from the meta feature in this case.

The grouping of the Soundings within this dataset was problematic. [...]

I imagine the production systems will be updated to automate this. However, I wonder why we can't have the production system always add an association from the Sounding to SpatialQuality. It's already required for soundings <= 30m.

Having it always present would:

• Eliminate the need for spatial evaluation (at least in the case of determining the horizontal uncertainty of soundings).
• Eliminate the need to specify that the dates must match
• Only increase the size by a small amount (TBD).

Here's a smaller scale view of the dataset with "Ignore scale minimum" enabled:

[benhazelgrove]

@DavidGrant-NIWC @TDYCARHugh

The reality of the sounding grouping at the moment is the compilers need to create the link to the Information Object and the QOBD areas firstly. This is a simple process as the 1 to many relationships is possible.

When they then need to only allow grouping within the singular QOBD area that they sit within, this is a more drawn out process. The team needs to isolate the QOBD area and select via a Geometry comparison the soundings within the area and group them (sometimes more than one group within a single area). This is time consuming in a cell where 150 QOBD areas exist. There is no easy indication in the tools to see if a compiler has already grouped certain soundings in the area, or anything from stopping another user from ungrouping all soundings and re-grouping via attribute similarities as per current S-57 functionality.

I think the ability to have many groups based on feature attributes within a single QOBD area will be ok. As long as they aren't grouped with soundings outside an area where their Spatial Quality information doesn't correspond with the area it sits within.