Talk:UKALNS - Revision history

Rmm at 03:32, 14 November 2018

2018-11-14T03:32:03Z

New page

[[User:Rmm|raphael]] 18:29, 15 August 2011 (UTC) from E.M. via email):
The definition is almost ok for me, but I think the last part about predicted tide takes us down a road of historical data, where as 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]

[[User:DavidAcland|DavidAcland]] 17:32, 16 August 2011 (UTC) "...and water level." added to definition to take account of non tidal ports and waterways where predicted water level is published.

== under-keel allowance as an object? ==

[[User:Rmm|raphael]] 18:45, 15 August 2011 (UTC): I think the issue of under-keel clearance allowance is complicated enough that we should consider making it an object (either information or feature). The original idea is [[Talk:UKCLRN|here]] (scroll to 3 December 2010).

The original idea was to make it an information object. If we decide to make it a geographic feature object instead it could get its own spatial object.

It could be associated with WATARE, HRBARE, PRTARE, FAIRWAY, DRGARE, SEAARE or other suitable feature objects.

[[User:DavidAcland|DavidAcland]] 12:31, 16 August 2011 (UTC) I have reviewed our earlier discussion. In practice UKA is normally applied for a whole port or it is in shipping company regulations. It was interesting to note in the Draught Information System for the St. Lawrence Seaway paper how keen they were to avoid clutter on ECDIS screens; that is during voyage execution.

In our case, as I have written elsewhere, we are mainly dealing with the planning situation and so mariners, and brokers need to know the general rule, which is applied quite a long time in advance, even at the point of fixing cargo to vessels and vessels to cargo. So I would hope that we can capture that information in sufficient detail in a complex attribute which can be placed on a PORTARE or a waterway area.

However I am open to persuasion if the case is strong. What are the benefits from making UKALNS into an Information feature?

[[User:Rmm|raphael]] 01:11, 17 August 2011 (UTC): I was under the impression that UKALNS would replace UKCLRN as an attribute of the information object APPLIC/CHALIM. Binding it to a geographic feature reduces my concerns about it quite a lot. I think there's still a (less strong) case for promoting UKALNS to a geographic feature, and I'll try to make it below.

The principle is the same, i.e., making things simpler for the user, but from a different perspective: the potential number of steps needed to reach the information. The assumption is that a Pick Report or other user interface requires one user step for each level "down" (e.g., click a tab, click a "show details" arrowhead, or open the next level in a tree, etc.).

Given that UKALNS an attribute of Port area or Waterway area, the structure is:
 PRTARE
*UKALNS
**UKAFIX
**UKAVAR
***UKAVBB
***UKAVDB
**OPERAT

which makes a human viewer take 4 steps to get to the bottom of the structure from the screen display:
 Pick report -> PRTARE -> UKALNS -> UKAVAR -> UKAVBB

If it is the "the greater of 1.0 m or 5% of the vessel's beam" it is necessary to calculate
 max(UKALNS -> UKAFIX , UKALNS -> UKAVAR -> UKAVBB), which takes at least 6 human steps:
 PRTARE -> UKALNS: 1 step
 UKALNS -> UKAFIX: 1 step
 back to UKALNS: 1 step
 UKALNS -> UKAVAR: 1 step
 UKAVAR -> UKAVBB: 1 step
 compare the results: 1 step

If we extend the model later for formulas, pointers to port rules, or extracts from rules about underkeel allowance, more steps will be needed. It's possible that application vendors can make a user interface which presents all the UKA information in one window, but that is likely to need special-case programming for UKA.

If UKALNS becomes a geographic feature object and we bind UKAVDB and UKAVBB directly to Object-UKALNS (i.e., dispense with complex attribute UKAVAR) fewer steps are needed and applications do not need special-case development.

Screen clutter can be reduced if the user can turn off the display of underkeel allowance as part of normal display customization. I think there is also some benefit in making it a geographic object, because then the graphic display "tells" the user "Underkeel allowance rules apply '''here'''".

It's a tradeoff between different considerations. If in the end you decide to keep UKALNS a complex attribute and also retain UKAVAR, that's OK.

[[User:DavidAcland|DavidAcland]] 08:56, 17 August 2011 (UTC) In refering to [[PRTARE]], I was trying to say that it is unlikely that we will have different rules for geographic areas as small as DRGAREs and HRBAREs. However I think we will have to bind to APPLIC in cases where the ship dimensions or direction decide the figure or rule. Likewise in very large ports like Rotterdam, we know that different rules apply: for external anchorages; for entry; for departure, all of which are exposed to weather; to the internal canals and basins; and berths, which are protected; and for different kinds of vessels. I think I saw about 20 different conditions (although there they talk about under keel clearance (UKC)). Things are so complicated there, and there is so much descriptive language surrounding the numbers that it may be impossible to model. This adds weight to Jens's earlier proposal to add INFORM.

The idea that graphic display "tells" the user is compelling. Perhaps a geographic "Underkeel allowance area"
could either share the geometry with a PRTARE in the case where there is only one figure or rule for the whole port, but would have its own geometry where there are different UKAs for different parts of the Port or approach. We could then mediate the rules in the geometry by [[APPLIC]] with multiple instances of [[APPLIC]] and [[UKAFIX]] or [[UKAVAR]] one for each case. This is beginning to sound too complicated.

[[User:Rmm|raphael]] 00:18, 18 August 2011 (UTC): Does this look all right?
*UnderKeelAllowanceArea
**UKAFIX
**UKAVAR
***UKAVBB
***UKAVDB
**OPERAT
**INFORM

UKAARE(UKAFIX=1.0) allowance must be at least 1.0 m in general
 UKAARE(UKAFIX=2.0) <-----> APPLIC(CATVSL=3) allowance must be at least 2.0 m for tankers
 UKAARE(UKAFIX=3.0) <-----> APPLIC(CATVSL=3, INFORM="special rule for vessels painted in purple and gold") allowance must be at least 3.0 m for tankers painted in purple and gold

with all UKAAREs sharing the same geometry

[[User:Rmm|raphael]] 17:22, 19 August 2011 (UTC): Draft definition of UKARE below.

Object Class: Underkeel allowance area
 Acronym: UKAARE Code: ??
 Camel case: UnderkeelAllowanceArea
 Set Attribute_A: [[UKAFIX]]; <del>[[UKAVAR]] (or</del> [[UKAVBB]]; [[UKAVDB]]<del>)</del>; [[OPERAT]]
 Set Attribute_B: INFORM; NINFOM; NTXTDS; SCAMAX; SCAMIN; TXTDSC;
 Set Attribute_C: RECDAT; RECIND; SORDAT; SORIND;
 Associated information object classes: <del> [[NATINF]]?; [[RCMDTS]]?; [[REGLTS]]?; [[RESDES]]?;</del> [[AUTORI]]?; [[APPLIC]]

Definition:
An area for which an authority has stated underkeel allowance requirements.

References:

Remarks:
Under keel allowance is either a fixed allowance in feet or metres or a variable allowance calculated from a percentage of the vessel's draught or beam.

Distinction: none

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 requirements apply, and also to indicate where they apply.

Comment: No comments.

Note for DC&EG: If there are different requirements for different classes of vessels, different UKAAREs may overlap or share the same spatial object. The associated APPLIC, if any, designates the class of vessels to which the requirement encoded in a specific UKAARE applies. Allowed spatial objects: ''Point and Line (added after 22-23 August discussion below);'' Area (should we allow Lines too, for say segments of a navigable waterway at some scales?)

[[User:DavidAcland|DavidAcland]] 13:54, 22 August 2011 (UTC) This looks good.

I see that when this is a geographic feature, we do not need UKAVAR at all, just [[UKAVBB]] and [[UKAVDB]]. [[UKAFIX]], [[UKAVBB]] and [[UKAVDB]] all become optional but we must have one of the 3.

My inclination would be to suppress the Quartet for simplicity. I would hope we are able to cover all we need to in UKAARE with Inform, but if there is a need I have not seen, no problem.

As a point of detail I understand underkeel allowance to be a published figure or formula. So in your example above with [[UKAFIX]] for tankers =2.0m I would not interpret this as "at least 2m". Similarly, for the purple and gold guys the allowance that they must make or apply is: 3.0m.

I agree the utilty of line spatial objects for waterways but I am having a harder time with point spatial objects for either a port or a berth.

[[User:Rmm|raphael]] 23:36, 22 August 2011 (UTC): I don't see a problem with suppressing the Quartet either. I don't mind dropping Point spatial objects, but the November 2010 draft S101 DC&EG allows Point objects for BERTHS, also ACHARE, ACHBRT, CTNARE, and SEAARE, presumably because ENCs find them useful.

[[User:DavidAcland|DavidAcland]] 08:01, 23 August 2011 (UTC) OK. If CTNARE and SEAARE can be points, then no problems with UKAARE.

[[User:DavidAcland|DavidAcland]] 10:29, 9 February 2012 (UTC) During discussions on the development of MPA application schema, it was decided not to proceed with UKAARE and to keep consideration of underkeel allowance as a complex attribute. This means it must be bound to a geographic feature, via Applicability [[APPLIC]] as in the draft MPA product specification 0.0.2. (February 2012).

[[User:Jens|jens]] 17:30, 10 February 2012 (UTC) I agree. The use as complex attribute bound to a geographic feature was proved by the MPA ProdSpec. We should continue using it as complex attribute.

[[User:Rmm|raphael]] 20:52, 10 February 2012 (UTC): Agreed.

[[User:Rmm|raphael]] ([[User talk:Rmm|talk]]) 04:32, 14 November 2018 (CET): Definition revised according to S-127 comment (change in italics):
 A fixed figure, or a figure derived by calculation, which is added to draught in order to maintain the minimum underkeel clearance taking into account the vessel's static and dynamic characteristics, sea state, ''information from real time sensors'' and weather forecast, the reliability of the chart and variance from predicted height of tide or water level.

Rmm at 20:52, 10 February 2012

2012-02-10T20:52:59Z

Jens at 17:30, 10 February 2012

2012-02-10T17:30:21Z

New page

[[User:Rmm|raphael]] 18:29, 15 August 2011 (UTC) from E.M. via email):
The definition is almost ok for me, but I think the last part about predicted tide takes us down a road of historical data, where as 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]

[[User:DavidAcland|DavidAcland]] 17:32, 16 August 2011 (UTC) "...and water level." added to definition to take account of non tidal ports and waterways where predicted water level is published.

== under-keel allowance as an object? ==

[[User:Rmm|raphael]] 18:45, 15 August 2011 (UTC): I think the issue of under-keel clearance allowance is complicated enough that we should consider making it an object (either information or feature). The original idea is [[Talk:UKCLRN|here]] (scroll to 3 December 2010).

The original idea was to make it an information object. If we decide to make it a geographic feature object instead it could get its own spatial object.

It could be associated with WATARE, HRBARE, PRTARE, FAIRWAY, DRGARE, SEAARE or other suitable feature objects.

[[User:DavidAcland|DavidAcland]] 12:31, 16 August 2011 (UTC) I have reviewed our earlier discussion. In practice UKA is normally applied for a whole port or it is in shipping company regulations. It was interesting to note in the Draught Information System for the St. Lawrence Seaway paper how keen they were to avoid clutter on ECDIS screens; that is during voyage execution.

In our case, as I have written elsewhere, we are mainly dealing with the planning situation and so mariners, and brokers need to know the general rule, which is applied quite a long time in advance, even at the point of fixing cargo to vessels and vessels to cargo. So I would hope that we can capture that information in sufficient detail in a complex attribute which can be placed on a PORTARE or a waterway area.

However I am open to persuasion if the case is strong. What are the benefits from making UKALNS into an Information feature?

[[User:Rmm|raphael]] 01:11, 17 August 2011 (UTC): I was under the impression that UKALNS would replace UKCLRN as an attribute of the information object APPLIC/CHALIM. Binding it to a geographic feature reduces my concerns about it quite a lot. I think there's still a (less strong) case for promoting UKALNS to a geographic feature, and I'll try to make it below.

The principle is the same, i.e., making things simpler for the user, but from a different perspective: the potential number of steps needed to reach the information. The assumption is that a Pick Report or other user interface requires one user step for each level "down" (e.g., click a tab, click a "show details" arrowhead, or open the next level in a tree, etc.).

Given that UKALNS an attribute of Port area or Waterway area, the structure is:
 PRTARE
*UKALNS
**UKAFIX
**UKAVAR
***UKAVBB
***UKAVDB
**OPERAT

which makes a human viewer take 4 steps to get to the bottom of the structure from the screen display:
 Pick report -> PRTARE -> UKALNS -> UKAVAR -> UKAVBB

If it is the "the greater of 1.0 m or 5% of the vessel's beam" it is necessary to calculate
 max(UKALNS -> UKAFIX , UKALNS -> UKAVAR -> UKAVBB), which takes at least 6 human steps:
 PRTARE -> UKALNS: 1 step
 UKALNS -> UKAFIX: 1 step
 back to UKALNS: 1 step
 UKALNS -> UKAVAR: 1 step
 UKAVAR -> UKAVBB: 1 step
 compare the results: 1 step

If we extend the model later for formulas, pointers to port rules, or extracts from rules about underkeel allowance, more steps will be needed. It's possible that application vendors can make a user interface which presents all the UKA information in one window, but that is likely to need special-case programming for UKA.

If UKALNS becomes a geographic feature object and we bind UKAVDB and UKAVBB directly to Object-UKALNS (i.e., dispense with complex attribute UKAVAR) fewer steps are needed and applications do not need special-case development.

Screen clutter can be reduced if the user can turn off the display of underkeel allowance as part of normal display customization. I think there is also some benefit in making it a geographic object, because then the graphic display "tells" the user "Underkeel allowance rules apply '''here'''".

It's a tradeoff between different considerations. If in the end you decide to keep UKALNS a complex attribute and also retain UKAVAR, that's OK.

[[User:DavidAcland|DavidAcland]] 08:56, 17 August 2011 (UTC) In refering to [[PRTARE]], I was trying to say that it is unlikely that we will have different rules for geographic areas as small as DRGAREs and HRBAREs. However I think we will have to bind to APPLIC in cases where the ship dimensions or direction decide the figure or rule. Likewise in very large ports like Rotterdam, we know that different rules apply: for external anchorages; for entry; for departure, all of which are exposed to weather; to the internal canals and basins; and berths, which are protected; and for different kinds of vessels. I think I saw about 20 different conditions (although there they talk about under keel clearance (UKC)). Things are so complicated there, and there is so much descriptive language surrounding the numbers that it may be impossible to model. This adds weight to Jens's earlier proposal to add INFORM.

The idea that graphic display "tells" the user is compelling. Perhaps a geographic "Underkeel allowance area"
could either share the geometry with a PRTARE in the case where there is only one figure or rule for the whole port, but would have its own geometry where there are different UKAs for different parts of the Port or approach. We could then mediate the rules in the geometry by [[APPLIC]] with multiple instances of [[APPLIC]] and [[UKAFIX]] or [[UKAVAR]] one for each case. This is beginning to sound too complicated.

[[User:Rmm|raphael]] 00:18, 18 August 2011 (UTC): Does this look all right?
*UnderKeelAllowanceArea
**UKAFIX
**UKAVAR
***UKAVBB
***UKAVDB
**OPERAT
**INFORM

UKAARE(UKAFIX=1.0) allowance must be at least 1.0 m in general
 UKAARE(UKAFIX=2.0) <-----> APPLIC(CATVSL=3) allowance must be at least 2.0 m for tankers
 UKAARE(UKAFIX=3.0) <-----> APPLIC(CATVSL=3, INFORM="special rule for vessels painted in purple and gold") allowance must be at least 3.0 m for tankers painted in purple and gold

with all UKAAREs sharing the same geometry

[[User:Rmm|raphael]] 17:22, 19 August 2011 (UTC): Draft definition of UKARE below.

Object Class: Underkeel allowance area
 Acronym: UKAARE Code: ??
 Camel case: UnderkeelAllowanceArea
 Set Attribute_A: [[UKAFIX]]; <del>[[UKAVAR]] (or</del> [[UKAVBB]]; [[UKAVDB]]<del>)</del>; [[OPERAT]]
 Set Attribute_B: INFORM; NINFOM; NTXTDS; SCAMAX; SCAMIN; TXTDSC;
 Set Attribute_C: RECDAT; RECIND; SORDAT; SORIND;
 Associated information object classes: <del> [[NATINF]]?; [[RCMDTS]]?; [[REGLTS]]?; [[RESDES]]?;</del> [[AUTORI]]?; [[APPLIC]]

Definition:
An area for which an authority has stated underkeel allowance requirements.

References:

Remarks:
Under keel allowance is either a fixed allowance in feet or metres or a variable allowance calculated from a percentage of the vessel's draught or beam.

Distinction: none

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 requirements apply, and also to indicate where they apply.

Comment: No comments.

Note for DC&EG: If there are different requirements for different classes of vessels, different UKAAREs may overlap or share the same spatial object. The associated APPLIC, if any, designates the class of vessels to which the requirement encoded in a specific UKAARE applies. Allowed spatial objects: ''Point and Line (added after 22-23 August discussion below);'' Area (should we allow Lines too, for say segments of a navigable waterway at some scales?)

[[User:DavidAcland|DavidAcland]] 13:54, 22 August 2011 (UTC) This looks good.

I see that when this is a geographic feature, we do not need UKAVAR at all, just [[UKAVBB]] and [[UKAVDB]]. [[UKAFIX]], [[UKAVBB]] and [[UKAVDB]] all become optional but we must have one of the 3.

My inclination would be to suppress the Quartet for simplicity. I would hope we are able to cover all we need to in UKAARE with Inform, but if there is a need I have not seen, no problem.

As a point of detail I understand underkeel allowance to be a published figure or formula. So in your example above with [[UKAFIX]] for tankers =2.0m I would not interpret this as "at least 2m". Similarly, for the purple and gold guys the allowance that they must make or apply is: 3.0m.

I agree the utilty of line spatial objects for waterways but I am having a harder time with point spatial objects for either a port or a berth.

[[User:Rmm|raphael]] 23:36, 22 August 2011 (UTC): I don't see a problem with suppressing the Quartet either. I don't mind dropping Point spatial objects, but the November 2010 draft S101 DC&EG allows Point objects for BERTHS, also ACHARE, ACHBRT, CTNARE, and SEAARE, presumably because ENCs find them useful.

[[User:DavidAcland|DavidAcland]] 08:01, 23 August 2011 (UTC) OK. If CTNARE and SEAARE can be points, then no problems with UKAARE.

[[User:DavidAcland|DavidAcland]] 10:29, 9 February 2012 (UTC) During discussions on the development of MPA application schema, it was decided not to proceed with UKAARE and to keep consideration of underkeel allowance as a complex attribute. This means it must be bound to a geographic feature, via Applicability [[APPLIC]] as in the draft MPA product specification 0.0.2. (February 2012).

[[User:Jens|jens]] 17:30, 10 February 2012 (UTC) I agree. The use as complex attribute bound to a geographic feature was proofed by the MPA ProdSpec. We should continue using it as complex attribute.

Rmm: /* under-keel allowance as an object? */

2011-08-22T23:42:20Z