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