DCEG clause 2.4.7 - Population of attribute soundingAccuracy

[JeffWootton]

Current wording of the final paragraph of DCEG clause 2.4.7:
Spatial quality attributes are carried in the information type Spatial Quality (see clause 24.5). Only point, multipoint and curve geometry and the Meta feature Quality of Bathymetric Data can be associated with Spatial Quality. Currently no use case for associating surfaces with spatial quality attributes is known, therefore this is prohibited; however it is allowable for Spatial Quality to be associated with the curves comprising the spatial edges (boundaries) of surface features. Vertical uncertainty is prohibited for curves as this dimension is not supported by curves.

This paragraph is a little inconsistent in regard to the corresponding guidance in S-57 (UOC), particularly the last sentence of the paragraph that states that "Vertical uncertainty is prohibited for curves as this dimension is not supported by curves", as this is certainly allowed in S-57 for soundings and any Objects having VALSOU as an allowable attribute. This sentence is also inconsistent with corresponding guidance included for the relevant features throughout the DCEG.

My interpretation of this sentence is that it has been included because the vertical (Z) dimension has not been implemented for any feature having curve as an allowable geometric primitive (as has been implemented for point and pointset geometry for the Sounding and DepthNoBottomFound features). While this is correct, the vertical dimension has been implemented for several curve and surface type features via feature attribution (valueOfSounding for example), as was done for S-57. The aim of the encoding of the vertical uncertainty for features carrying depth attributes is to have it be the equivalent to what is done in S-57 - therefore the population of verticalUncertainty on curves, including curves comprising the spatial edges (boundaries) of surface features, should be allowed.

It is therefore proposed that the last sentence of clause 2.4.7 is removed from the DCEG; and perhaps replaced with a clarifying statement that, where required, verticalUncertainty should (or must?) only be encoded on an associated SpatialQuality Information feature instance where the feature associated with the geometry has a value for a depth-related attribute (such as valueOfSounding).

[TDYCARHugh]

Initial thoughts: If the vertical value is a feature attribute then it would seem to make sense that the vertical uncertainty also be either a feature attribute or a reference to an information type from the feature.

Are you suggesting that depth contour feature which is made up of 3 curves could have different vertical uncertainty values for each curve?

For a surface, what does it really mean if some of the curves have a different vertical uncertainty?

Also keep in mind that curves can be shared. Your final sentence would need to be changed (the feature -> a feature):
"verticalUncertainty should (or must?) only be encoded on an associated SpatialQuality Information feature instance where a feature associated with the geometry has a value for a depth-related attribute"

What if the curve is used by more than one feature that has a vertical attribute value? Does the same spatial quality apply to all vertical attributes on all related features? For example a curve for a contour with depth areas on either side. How could you indicate that one depth area has a different uncertainty?

I think that it is simpler that the vertical uncertainty information type applies only to the object that is referring to it. So curve and area features should either have a vertical uncertainty attribute or a reference to an information type and curves/surfaces should not have vertical uncertainty.

[benhazelgrove]

Our use case for this would be Wreck and Obstruction surface features.

The depth contours carry value of depth contour attributes, not value of sounding. The underlying QOBD feature should be the reference for the depth contours. Could we limit clause 2.4.7 to valueofsounding?

The Wreck and Obstruction areas may carry horizontal and vertical accuracy information that the QOBD surface doesn't contain. These features may be derived from targeted, highly accurate surveys that differ from the overlying QOBD general area. Adding the differing values to the wreck and then QOBD feature should allow the data hierarchy to work?