Default Clearance Depth calculation for Obstruction and UnderWaterAwashRock

[alvarosanuy]

DEFAULT CLEARANCE DEPTH. The depth value determined for an underwater hazard of unknown depth, based on the depth of the surrounding area.

In DCEG 1.4.0, when valueOfSounding= Unknown, defaultClearanceDepth is to be calculated by determining [minimum depth] and then subtracting 66m out of that number.

• [minimum depth] = depthRangeMinimum value of the shoalest of the depth areas covering the feature.

Note that the auto populated value for defaulClearanceDepth may be amended by the Data Producer if the resulting isolated danger indication in the ECDIS is not considered appropriate.

This -66m is currently used by S-52 CSP and it seems to represent the worst possible scenario for a sunken ship if it was to sit completely vertical on the seafloor (distance from bottom of the keel to highest part of the tallest mast. Please note this figure was researched 30 or so years ago and may not represent the largest measurement possible in 2024).
Back in the day (S-52 origins) the intention was to use a figure so wrecks in 'deep water' wouldn't be highlighted as dangers when their valueOfSounding=Unknown and categoryOfWreck=Unknown. For example, a Wreck in a 100-200m of water would always have, at least, 34m of water over it.

CONCERN: It seems the -66m is also used (at least in S-101) when calculating defaultClearanceDepth for Obstruction and UnderwaterAwashRock. This does not seem appropriate as these features can be of any height and abruptly raise from the seafloor, particularly in the vicinity of volcanic islands (e.g. South West Pacific).

Accordingly, it is proposed that for Obstruction and UnderwaterAwashRock, when valueOfSounding=Unknown, defaultClearanceDepth is not calculated as per Wreck and its value is auto populated with, for example, -100 (a value large enough as to cover the largest tidal height in the world) instead. This will guarantee that these features will always be flagged by the portrayal rules as 'Dangerous to navigation', irrespective of the surrounding depths.

RECOMMENDATION: Investigate S-52 CSP logic for OBSTRN and UWTROC and, if needed, recommend the ENCWG to apply similar changes to S-52 PL [Ed 5.0.0 currently being drafted to implement requirements introduced by MSC.530(106)].

[TDYCARHugh]

The intention behind defaultClearanceDepth was to simplify processing in the ECDIS to avoid having to do spatial query operations and complicated logic. Ideally the ECDIS/mariner would have information about the depth over a Wreck, Rock or Obstruction. In S-52 CSPs were written for these objects to try to handle the case where the VALSOU was not populated. The logic looks at other attributes like EXPSOU and WATLEV to determine if the object is dangerous or shoaler than the surrounding area. For a Wreck the CATWRK is also used. A default clearance is then calculated based on the logic in the CSP. In the WRECKS05 CSP the value of -66 is used as part of the logic but only when the other attributes don't provide another choice. Other choices result in a value of 0. -15 or 20.1. If there is an expectation for producers to fill in a default clearance depth then the logic must be very clear. For example to repeat/document the logic used in the S-52 CSPs for the applicable objects. What is in the current DCEG is not sufficient or correct.

The name 'default clearance depth' seems to indicate that there could or should be a clearance depth.

The best scenario would be that the producer provides an actual depth and if they don't have it then provide a known clearance depth. If neither are provided then the system could define default clearance depth but this should be visible and editable by the producer and probably the mariner so that they know it is not an actual depth.

A known clearance depth would be set by the producer if they have wire dragged over the object or through other means have confirmed that the object is not dangerous for surface navigation with vessels of a draft less than the known clearance depth.

[DavidGrant-NIWC]

I agree with both Alvaro and Hugh's comments. IMO, this needs to be resolved prior to 2.0.

[alvarosanuy]

I agree with both Alvaro and Hugh's comments. IMO, this needs to be resolved prior to 2.0.

@TDYCARHugh & @DavidGrant-NIWC - Is there a modelling change proposal to consider or are we looking at recreating the related CSPs as S-101 PC Rules (this would also require changes to existing features' modelling)?

The timeline towards Ed 2.0.0 refers to a 1.5.0 version that would be developed 'in parallel' while 1.4.1 is reviewed by the S100WG (Letter to members should be sent out on Monday 29/7).
The timeline at the end of S101PT L5 does not detail the pathway from 1.5.0 (e.g closing date) to 2.0.0.

@TomRichardson6 - Do we have room to make modelling changes before 2.0.0, if required to address this topic? I personally believe that it's significant enough as to try and fix the issue before S-101 2.0.0 (it should be resolved before the S-101 Pack goes to HSSC - S100WG Chair should be notified of the additional work required and that would occur while 1.4.1 is out for voting - not ideal but .....).

If needed, changes to S-52 PL could be processed 'to match', as part of the NE currently in preparation by the ENCWG.

[DavidGrant-NIWC]

I don't believe the modelling should change. S-52 had to come up with a value based on the information it had available; in S-101 the encoder is responsible for coming up with a reasonable default value. The only issue to be resolved is to provide the encoder reasonable guidance to populate the default value based on the feature to which it applies.

As Hugh has pointed out, you may not want to copy exactly what S-52 does.

Worst case, you could set the default to -15 (or -100 as you proposed) in the production system and the HO can override as needed.

[TDYCARHugh]

I think the model is ok. What I think should change is the guidance. I don't think that defaulClearanceDepth should be a 'system' attribute in the sense that it must be seen, validated and likely edited by the data producer when an actual depth is not available. I am ok with the production system providing tools to calculate an initial value based on a well documented algorithm but I don't have confidence that an algorithm would always produce the desired result. For example the production system does not know if the area has been swept to a certain depth or if there has been enough traffic over a wreck to know that there is safe clearance.
My recommendation would be to change it from defaulClearanceDepth to clearanceDepth and make it a regular attribute so that producers and mariners can see it. I think it would be useful for a mariner to see that the producer did not set value of sounding but did indicate a safe clearance value.

[alvarosanuy]

@TomRichardson6 - We need a decision on this.

My preference is:

For ALL features (Wreck, Obstruction and UnderwaterAwashRock) and when valueOfSounding=Unknown - Production tool to automatically populate (system attribute) defaultClearanceDepth= -100. Data producers can manually adjust this number if they want to.
defaultClearanceDepth ------ Will not be calculated from [minimum depth]. By default, it will always be -100 (absolute value).

If somebody would like to treat Wreck differently and calculate defaultClearanceDepth as [minimum depth] - NN (tallest ship in the world), please note that, a quick Google search will show that today there are a few ships taller than 70m (air draught) and their total height (from the keel) would get close to 100m (the -66 (NN) in S-52 should be updated or the CSP re-written).

[TomRichardson6]

@alvarosanuy it is possible to make modelling changes before 2.0.0 but they would need to be significant ones. Noting other comments it seems that this only impacts the DCEG where we agreed to provide guidance on how these values must be calculated. I tend to agree that amending this for Wrecks to -100 would make sense but in that case S-52:100 should be amended accordingly. But I think applying this for UnderwaterAwashRock and Obstruction needs further discussion. Like Hugh I do not see this as an instance where producers would be changing the value as they might for others such as flare bearing. If they want to change the outcome here they should use WATLEV and EXPSOU which I think is why we retained EXPSOU.

[alvarosanuy]

VTC Meeting on 05AUG2024

Thanks to @TDYCARHugh @DavidGrant-NIWC @TomRichardson6 @JeffWootton @benhazelgrove for attending last night.

We decided:

• CSP affecting UWTROC, OBSTRN and WRECKS will be migrated into a tabular, easier to read, version and incorporated into the DCEG (Section 30.1). @JeffWootton was tasked to draft the first versions and then circulate them for comments by Monday 12/8.
• DCEG 30.5 correctly describes the way surroundingDepth is to be calculated (No changes required).
• Production Software manufacturers are responsible for calculating and encoding the default values for these 2 'system' attributes (defaultClearanceDepth & surroundingDepth) during ENC compilation.

Please let me know if I missed (or incorrectly interpreted) something.

Thanks

[JeffWootton]

Based on the discussions held at the dedicated VTC meeting held on 05/08/24 and further iterative email exchanges made during the development of the required table, the following is the final version to be included in S-101 Edition 1.5.0 based on the existing S-52 Conditional Symbology Procedures. NOTE: There are essentially to versions of the Table included - one including Obstruction, UnderwaterAwashRock and Wreck in a single table; and the other splitting the features into separate tables. For ease of reading it has been agreed to include the version containing each feature in a separate table in the DCEG.

defaultClearanceDepth Table.docx

[benhazelgrove]

Thanks Jeff

I have run some examples of real-life S-57 encoding through to S-101 this morning and wanted to see if everyone thought this was the right interpretation of the table.

This example has CATWRK = 1, EXPSOU = 1, VALSOU = Unknown and WATLEV = 3
The wreck sits in 5-10m of water in Sydney Harbour. Therefore, using the table I have populated SD = 5 and DCD as 20.1.

Do we think this is correct or should it have been DCD = - 61?

Either way we have an illogical instance. We have a Non dangerous wreck in 5-10m of water, always submerged with either 20.1 or -61 populated for DCD.

If it didn't have CATWRK = 1 then it would be more suitable as DCD would = 5m. What if we were to propose that in depths less than 20m where the above conditions are met, we populate DCD = Least Depth + 0.1?

[JeffWootton]

Hi Ben.

You raise a good point. There is a problem with the logic in the Wreck table. I have gone through the CSP again and corrected the table as follows (red indicates changes; strike-through indicates deletions):

Wreck_defaultClearanceDepth Table.docx

Based on your example (but see my additional comment below), because the wreck lies in a single 5-10 depth area (attribute depthRangeMinimumValue is known), defaultClearanceDepth will equal "Least Depth" which in this case is 5.

I should also note that there is an error in your encoding. The DCEG specifies that exactly one of the attributes categoryOfWreck or valueOfSounding must be populated, not both. The table is therefore required to cover both scenario's where exactly one of these attributes is populated (the other attribute has a "/" to indicate that it must not be populated). I have therefore also corrected the entries having a "*" and removed the comment at the bottom of the table is this is not allowed in S-101.

[benhazelgrove]

Thanks Jeff

Yes there is an encoding error there. I had populated VALSOU=Unknown on all instances of our wrecks in this product that had an empty valueofsounding, using a Change all command. This was to test a work around to allow for the gap where CARIS wasn't allowing Unknown to be added on the attribute for valueofsounding. This won't occur once the fix is deployed to a version of the software to allow Unknown to be populated.

[alvarosanuy]

defaultClearanceDepth will equal "Least Depth" which in this case is 5.

Shouldn't it be: defaultClearanceDepth = "Least Depth" + 0.1 (in the example, 5.1m)? EXPSOU in the encoding = 1 (within the range)

[DavidGrant-NIWC]

Shouldn't it be: defaultClearanceDepth = "Least Depth" + 0.1 (in the example, 5.1m)? EXPSOU in the encoding = 1 (within the range)

The S-52 CSP will use "Least Depth" (5).

Review of the Wreck table:

• The height column can be removed; it doesn't affect the value of defaultClearanceDepth.
• Entries for VALSOU="/", CATWRK="Unknown" are missing.
• This row is invalid; one of valueOfSounding or defaultClearanceDepth must be populated with a non-null value.
  
• This row (2nd from the last) is incorrect; clearance depth can only be zero when CATWRK is unknown:
  

Here is a simplified version:

[alvarosanuy]

The S-52 CSP will use "Least Depth" (5).

I was trying to highlight the shortfall in the logic. It would be worth considering changes to the S-52 CSP now that it will be open

[JeffWootton]

@DavidGrant-NIWC :

• While the height column has no impact on the calculation of defaultClearanceDepth, I would prefer to prefer to keep it for completeness for the intended target audience for the DCEG, which is the data producer.
• Good pick-up with the "VALSOU="/", CATWRK="Unknown" are missing". I have amended the table accordingly (changes in red - also addresses your last bullet):
  defaultClearanceDepth_Wrecks.docx
• For the 3rd bullet - I think this is an error in the conditional mandatory statement for defaultClearanceDepth for the Wreck feature. The condition is that height has not been populated; and category of wreck is populated or value of sounding is populated with an empty (null) value. I have corrected the conditional statement at clause 13.5 accordingly.

@alvarosanuy :
I am not sure this is a shortfall in the logic. This logic is only being used to provide the system with an indication of the least depth of a feature where the actual least depth is not known. There is no exposure of this value to the end-user and the value errs on the side of safety (by only 0.1m), regardless of the value populated for expositionOfSounding.

[alvarosanuy]

@JeffWootton

This logic is only being used to provide the system with an indication of the least depth of a feature where the actual least depth is not known.

If the Safety Contour is set to 5, the Wreck shouldn't be highlighted as a danger to navigation. By populating EXPSOU, the producer is telling us that the wreck has, 'at least', 5.1m of water over it.
Going with DRVAL1 as Least Depth may be simpler or currently used in S-52 but not logic based on the attributes encoded.

[TDYCARHugh]

Where does the non-dangerous Wreck is >20m come from?
I looked in S-4 and logic that seems to indicate that dangerous means it is dangerous to a vessel capable of navigating in the vicinity.

I have a question about the rows in the table that are setting to 20.1 or deeper.

For a non dangerous wreck:
If the Least Depth is 15m can a Wreck be classified as category or wreck =1 (non-dangerous) and if so does it make sense to be setting the clearance depth to 20.1?
I am wondering if it should be if Least Depth < 20.1 then use Least Depth for the clearance and otherwise use 20.1 or Least Depth-66.

[JeffWootton]

Hi Hugh. I think the whole point of the determination of defaultClearanceDepth is to (try to) ensure that the correct performance is produced in the ECDIS based on the population of this attribute, noting that it is only populated by the production system if the wreck has not had attribute height populated and valueOfSounding is empty (null); and that the attribute will: 1. Not be visible (not even in the pick report) to the end user; and 2. Is editable by the Data Producer if they consider that the resulting isolated danger indication (or lack thereof) in the ECDIS is not considered appropriate. For your question on a non-dangerous wreck being determined as being > 20m, this has come from the S-52 WRECKS05 CSP and my assumption that the developers of S-52 were using S-4 at the time that this depth was determined (I note here that the shoaler of the 2 depths cited at B-422.7 for delimitation of criteria for wrecks is 20m). For your second question, I note (1.) above and the performance that actually occurs in the ECDIS. A wreck that is encoded by the Data Producer as non-dangerous (categoryOfWreck = 1) will display and alarm as non-dangerous regardless of the depth area (used to determine Least Depth) that the wreck lies in, as long as the Mariner sets the safety depth to a depth that is shoaler than 20.1 metres. In the example that you have given, if the depth area is encoded as a 15-20 DepthArea (therefore Least Depth is 15), and the defaultClearanceDepth is set to Least Depth if the Least Depth is < 20.1, then the wreck will display and alarm as an isolated danger if the Mariner sets their safety depth to 15.1 metres, even though the Data Producer has indicated in the encoding that the wreck is non-dangerous within that depth area. This to me defeats the purpose of having set a default “threshold” depth of 20 metres to distinguish between a “dangerous” and “non-dangerous” wreck where no depth information for the wreck has been provided by the Data Producer. I know that in this example if the Mariner sets their safety depth at 15.1 the safety contour will be set to the 20m depth contour, but the Data Producer would still expect the wreck to display as non-dangerous in this case even if the Mariner selects to display isolated dangers in areas shoaler than the safety contour. I hope this makes sense – I spent many hours poring over the relevant S-52 CSPs to develop the tables at clause 30.1 and have received some feedback from Dave and others that have required changes to the tables in the DCEG, and I think we now have a good reflection of the performance that would be achieved via the S-52 CSPs in these tables. To me the improvement is providing the mechanism for the Data Producer, if they have some evidence such as deeper draught vessels being able to traverse the area safely, to be able to amend the value appropriately. Happy to discuss further as required.