Adding curve as allowable geometric primitive for SeaArea

[JeffWootton]

A suggestion has been raised to include curve as an allowable geometric primitive for the S-101 feature SeaArea. The following is the correspondence so far related to this suggestion:

My colleagues realized that some underwater features are not possible to encode as a 2D line and asked me if it would be possible to revise this feature for the S-101.

"The definition of the nomenclature of underwater features is carried out by the GEBCO SUB-COMMITTEE ON UNDERSEA FEATURE NAMES (SCUFN) and files for viewing and downloading are available at the Undersea Feature Names Gazetteer (https://www.ngdc.noaa.gov/gazetteer/ ).
Various types of geological features are available in the gazetteer in a 2D line pattern, for example, Canyon, Fracture Zone, Valley, Sea Channel, Trench, Ridge, Rift, Trough.
However, in HPD the corresponding acronym SEAARE only allows point and area features (point and surface). Please find attached the error in HPD."

I was wondering if it would be possible to insert line-type resources for SEAARE in S-101. If so, what would be necessary to analyze this insertion?
Thank you in advance for your assistance.

Best Regards,

...

S-101PT Secretary response:

Hi.

While the SCUFN may define undersea features as 2D line features, the issue with including this in S-101 ENC is its significance as curve (line) geometry to navigation. Given that that the line geometric primitive was not allowed for S-57 ENC, we simply carried this through to S-101unchanged, although I do recall that there was brief discussion many years ago on the merit of allowing curve (line) as a geometric primitive for the S-101 feature SeaArea, but this was rejected at the time. As I recall, the decision was based on:

• Line is not an allowable geometric primitive for SEAARE in S-57;
• SeaArea (and SEAARE in S-57) has no corresponding portrayal to define the geometry of the feature. Representation in an end-user system is display of the name only (at the position of the point or in the centre of the area as included in the Mariner’s selected screen coverage) when the Mariner chooses to display names; and
• Based on the above, it was considered that encoding a point (or points if the feature is extensive at the optimum display scale of the data) representative of a linear feature to display the name of the feature was sufficient for navigation.

Having said this, however, this can be discussed further if use cases can be presented that demonstrate the relevance of encoding these features using curve geometry to navigation. I have therefore opened a new Issue (Issue #185) in the S-101 Documentation and FC GitHub repository, using this email exchange as the introduction, to facilitate further discussion.

An additional item of note that will need to be considered: During the (dual-fuel) transition period moving from S-57 to S-101, Data Producers will be required to produce and maintain both S-101 and S-57 datasets to service S-57/S-52 ECDIS still being used at sea. Many Data Producers will choose to maintain their “core” ENC data in the S-101 format and convert their data to S-57 so as to provide the corresponding S-57 dataset. Allowing curve as an allowable geometric primitive for SeaArea will require some manipulation of the data when converting to S-57 given that line is not an allowable geometric primitive for SEAARE.

Best Regards,

Jeff.