Talk:UKAARE

DavidAcland 11:06, 25 August 2011 (UTC)

Starting UKAARE following 2 email discussions mid august 2011.

Justification:

Making a geographic feature object for locations where underkeel allowance requirements apply simplifies the data model and allows graphic displays to emphasise to the viewer that underkeel allowances apply, and also to indicate where they apply.

The first edited email string is below:

By Acland David August-15-11 11:53 AM

I have made ammendments to the wiki in the last few days to take account of our SNPWG13 decision to recommend new definitions to the IHO dictionary for underkeel clearance and underkeel allowance. Since we last looked at the application schema, Jens and I, have discussed the effects on the model where ports use ship's beam as the input to underkeel allowance. This is sometimes the case with very large tankers, with a large beam. When they roll there is a large increase in draught and in fact this can be the most significant effect. So the underkeel allowance is calculated on a percentage of the beam, which is then added to draught. I have amended the UML model at the attachment and also updated the wiki starting here: UKALNS.

Please could you all look at these changes and comment or agree them by close of business 19 August. If we do agree, I realise that this will involve some rework for Tony in the MPA feature catalogue. The discussion is here: Talk:UKCVAR. UKCVAR has now been retired and is at the deleted items in the SNPWG wiki.

By Eivind Mong Aug 15, 2011 at 10:14 AM

Think my turn in the difficult chair is not over yet. The definition is almost ok for me, but I think the last part about predicted tide takes us down a road of historical data, whereas the trend today with underkeel allowance is one of real time data. So I recommend the wording reflect this, and in addition use the term water level, as a number of harbours are not tidal harbours (e.g. Montreal) and in others there is much greater effect of weather conditions on the available water column than tide has (e.g. Hamburg). So in conclusion, I recommend changing the last part of the definition:

From … and variance from predicted height of tide. To …and variance from height of water level (predicted or real time).

As extra curricular reading if interested, the link below is for the St. Lawrence Seaway specification for a dynamic under keep clearance (allowance) system using more real time data for the calculations. http://www.greatlakes-seaway.com/en/pdf/DISImplementationSpecRev3.pdf

By: Acland David August-16-11 6:18 AM

Hi Eivind, Welcome back. A couple of problems here.

You are quite right about Historic data. When Mariners plan that is what they have to go on; i.e. prediction based on what happened in the past. You will see that Chart 4792 Port de Montreal has a Water Level Note and a table for the monthly water levels at Varennes based on the 20 year series 1987- 2008. I could not find anything equivalent in the ENC.

Underkeel allowance is all about adding a handful for safety. It is not very scientific because it is a coarse allowance for 5 effects:

a. squat,

b. ship movement due to sea state,

c. siltation or survey error,

d. change in water level due to passage of weather systems known in NW Europe as tidal surge and

e. errors in predicted height of tide (or water level), my brackets.

Using real time water level is an attempt to remove the errors introduced by d and e. Clearly it is also useful in rivers where the water level changes seasonally and predicably, but only with limited precision and levels can change a lot in a few days.

Where real time water level is in use your amended language would imply "... variance for real time water level." and I do not think that this means what you want to say, although there must be a slight variance along the stretch of river or estuary covered by a tide or water level gauge. But there is also a practical problem. You cannot know what the real time water level will be when you are doing your planning, perhaps days or weeks ahead. Also in the case of Montreal the water level is broadcast by AIS. You will only start to pick this up when you are close, anyway less than a few hours away. That is too late for when you are planning your cargo. However it could contribute to a "Go Nogo decision" during voyage execution.

Under keel allowance is a figure, or a rule (10% of beam) which is published by the Port or other authority.

The Montreal reference is an interesting read and I note that:

The primary purpose of the Draught Information System is to increase the safety of navigation by providing the mariner with additional information about the under keel clearance. (Paragraph 6)

Under keel allowance and underkeel clearance are related but not the same things.

So to meet the non tidal case I suggest we simply say:

"... and variance from predicted height of tide or water level."

By Eivind Mong,16 August 2011 15:34

Perhaps my understanding of underkeel allowance is different from yours, but trying to keep it simple, my understanding of the use here is to communicate a set value that a navigator must account for when calculating under keel clearance as part of planning his voyage into a port, waterway or some confined waters. I’ve also heard the term safety margin used. The system put in place in the St. Lawrence Seaway (using realtime data, high definition bathymetry, etc) allows a reduction in the safety margin when in use. So in effect there are two values in the Seaway, one when using predicted water level and another when using a type approved system utilizing real time water level. How do we account for that in UKALNS when the definition is tied to predicted tide and water level values?

Furthermore, and as interesting information CHS has a system in the St. Lawrence river (for both the tidal and non tidal part of the river) called SINECO (bottom of page http://www.tides.gc.ca/english/DataAvailable.shtml). This system contain a water level forecast of up to 30 days, and is also broad cast by internet, so a vessel planning a voyage from Europe to Montreal or further into the Great Lakes can know what water level to expect along the St. Lawrence river part of his voyage. I think this system is covered by the definition as you have proposed.

And last, I wondered about the use of the terms “tide and water level”, as I would understand tide as a sub type of water level, but I have noted the naming of the IHO working group TWLWG, so I am ok with that part of the definition as well.

By Acland David August-16-11 11:47 AM

Thanks for this further input. I was looking for instances of forecast water level. I agree this is a good example.

I do not think we should be getting into the special case of the Draught Information System in St Lawrence Seaway any more than the Taranaki case.

We need to be able to handle in the NPUB product what the Ports or local Authorities stipulate to be used.

I see that there is no mention of underkeel allowance in the Draught Information System in St Lawrence Seaway. This is not entirely surprising because it seems to me that they are moving to a higher level of detail than is in practice in most ports.

I also looked at the TWLWG Terms of Reference and was at the HSSC meeting when the "water level" bit was pushed in.

But I take it that you are happy with the definition as amended in my suggestion this morning.

By Eivind Mong, 16 Aug 2011 17;02

The definition in itself is fine, but my question on how to handle the dynamic underkeel clearance systems (DUCS) arising remain. More and more spots around the world do dynamic underkeel clearance by various means, the Seaway is just an example (the one which I know best), and at the moment the SNPWG model does not address this. We can make a conscious decision to ignore dynamic underkeel clearance for the time being, and proceed with the definition you suggested this morning. It would make the interim easier, but then we must keep the DUCS in mind for the future.

Definition string ends here. New string on the model below.

By Raphael Malyankar 15 August 2011 19:57

In addition to the updated definition, I think under-keel clearance is complicated enough to merit consideration as an information or feature object. More information and a link to the original proposal are on the discussion page for UKALNS.

By Acland David Tuesday, August 16, 2011 5:52 AM

Replied on the wiki page here:UKALNS

By Raphael Malyankar 17 August 2011 02:24

I have made the case for UKALNS as an object on the Wiki.

By Acland David August 17, 2011 9:20 AM

Further comment on wiki ... warming to the idea of UKA Area.

By Raphael Malyankar 19 August 2011 18:37

I have drafted a definition of UKAARE at Talk:UKALNS.

Should we simplify it by binding CATVSL, CATCGO, VSLMSM, and similar attributes directly to UKAARE, and dispensing with the association to APPLIC? For example UKAARE(CATVSL=3) would indicate that the requirements in that UKAARE object apply only to tankers. It would of course be a little different from the rest of the model, the question is whether simplifying this part of the model is worth the difference.

By Acland David August 22, 2011 7:54 AM

I have been thinking about the syntax of APPLIC. I do not think that we want to have large stacks of UKAAREs on top of each other. So if there is only one rule for all vessels, I think we can bind directly. However with multiple rules, it make more sense to me to use the UKAARE once and have multiple APPLICs, once for each condition.

I have also responded on the wiki at UKALNS

By Raphael Malyankar 23 August 2011 01:00

Were you thinking of binding UKAFIX, UKAVDB, UKAVBB to the APPLIC for the multiple-rule situation? That might work.

I have also responded on the Wiki to the Point and Quartet issues.

The current S-100 model makes modeling this kind of thing awkward. One of the ideas in Eivind’s email last week was developing a way to encode rules.

By Acland David Tuesday, August 23, 2011 1:33 AM

I said OK for Point on the wiki.

As you know APPLIC came out of CHALIM. So in the back of my mind I see APPLIC as a CHALIM on steroids. So APPLIC means characteristics associated with an area which attracts a rule. Our Area is UKAARE. The Characteristics are: CATVSL; VSLMSM; etc. Then we need the "limitation" or rule which in this case is UKAFIX; UKAVBB etc.

I understand where Eivind is coming from because here we have two different kinds of attributes. One kind sets the condition; the other the rule than applies when the condition exists. Is this OK or does it run contrary to modelling conventions? Should we be explicit about which is the condition setter and which the "limitation" or "rule"? Or are we just drafting what goes into the DC&EG for APPLIC?

By Raphael Malyankar August 23, 2011 12:51 PM

Your understanding is right, but we are already being unconventional by trying to model such concepts using only objects and attributes (S-100 forces us to do it that way), so there is really no firm convention which applies. Being conventional would mean encoding rules literally as rules, for example as:

Rule 1: IF (ship.type = 3) THEN (UnderkeelAllowance = 3.0) IN PRTARE(OBJNAM=’Hamburg’)

Rule 2: IF (ship.type <> 3) THEN (UnderkeelAllowance = 2.0) IN PRTARE(OBJNAM=’Hamburg’)

Eivind and I suggested SNPWG take up encoding of rules in general as one of SNPWG’s blue-sky projects, but that is for the future.

For now, we are trying to decide where the UKA “limitation” attributes should be bound, without stacking UKAAREs. The “limitation” attributes (UKAFIX, UKAVBB, UKAVDB, OPERAT) can be:

1. bound to a geographic feature object (UKAARE or other)

2. bound to the same information object as the “characteristics” attributes,

3. bound to a distinct information object which sits between the geographic feature object and the APPLIC (for example,

PRTARE<---->REGLTS<---->APPLIC or PRTARE<---->UKALNSInfoObject<---->APPLIC)

All approaches work (in the sense that there is no logical flaw), we should pick one and the DC&EG can explain it to encoders.

If we use (1) we need to stack UKAAREs (or other geographic object) in places where there are different rules.

If we use (2) we have to bind “limitation” and “condition” attributes to the same information object.

If we use (3) we have to use an intermediate information object (either a new info object or one of the Quartet)

Alternative (1) is ruled out. If we pick (2), I would prefer defining a new, specialized information object which has both the limitation and characteristics attributes – it keeps the contagion (so to speak) out of APPLIC. Which of approaches (2) and (3) do you prefer?

By Raphael Malyankar August 24, 2011 05:55 AM

I have given this some more thought. Let me try to simplify my previous email.

The questions you ask are good ones, but most of them stem from our attempt to model this kind of concept using S-100, which is not designed for this. So I think we should just try to make this correct (no logical errors in the encoded data), efficient (for the mariner), and parsimonious (applying Occam’s razor). Beyond these three principles, we should not worry much about where we bind the “limitation” and “characteristics” attributes.

By David Acland 24 August 2011, 16:52

OK. I am delighted to apply Occam's Razor to our work.

It is also good to read your advice that we should not worry too much about where we bind the "limitation" and "characteristics" attributes. So unless I hear caution from anyone else, tomorrow morning I plan to transfer this string to the wiki and take your outline design for UKAARE as a geographic feature onto the SNPWG FCD page. David

raphael (talk) 23:20, 8 January 2018 (CET): The discussion page for complex attribute underkeel allowance has a note dated in February 2012 saying it was decided not to proceed with UKAARE and to keep consideration of underkeel allowance as a complex attribute. However, the draft S-127 model includes an Underkeel Management Area feature. That opens the question of whether to revive this feature "Underkeel Allowance Area" or define a new feature "Underkeel Management Area". I'll proceed with the latter (new feature) for now.

jens (talk) 10:50, 9 January 2018 (CET) I remember that discussion. The whole Underkeel Clearance discussion based on the fact that we should provide information on Underkeel Clearance. The current situation is from my point of view devided in two sections: an "Underkeel Allowance Area" and an "Underkeel Management Area". But before proceeding with both or one of both we have to consider whether the term "Underkeel" should be better defined as "Underkeel Clearance". Consequently the two terms should be "Underkeel Clearance Allowance Area" and an "Underkeel Clearance Management Area".

The "Unterkeel Clearance Allowance Area" defines the spatial where an authority defines Underkeel Clearance values (that was the purpose of the complex attribute to cover all conditions) and the "Underkeel Clearance Management Area" defines the spatial where the Underkeel Cearance will be managed (based on current weather conditions or sea state, or whatever).
The latter is on what the UCKMSPT is working on. As Mike was saying. we provide only the information on how to open the door. Everything behind the door is up to them.