Talk:UKALNS

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. [1]

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?

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 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.

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?

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.