Talk:CHALIM

jens 17:19, 21 December 2008 (CET)

Initially I added CATREA; works together with RESTRN describing RESARE features and completes this data structure.

I though deeper of these two attributes. I don't see why to use them. If restrictions like these apply the RESARE geometry can be used. That makes the duplication of these attributes superfluous. They are described there.

Remarks shown in brackets are doubtful. That makes in my opinion not much sense.

DavidAcland 16:28, 15 January 2009 (CET)

I came to the same view independantly. I do not see the need for CATREA nor how to use it,if it were retained. I believe resdes will cover restrictions better than RESTRN. Both deleted.

Agree that bracketted remarks can go. Deleted and copied in here for the record:

((((RESTRN and CATREA encode the type of restriction; a short explanation may be given by the use of the attributes INFORM, and NINFORM.))))

DavidAcland 17:26, 19 January 2009 (CET)

Now that we have the attributes agreed, it is worth thinking again about the logic.

1. Most attributes indicate the limits for passage or use of a facility or area.

2. prfmnc is a bit different because as drafted it states what is required. Perhaps we could amend that to read "minimum requirement" for "hull design, main and auxiliary machinery etc".

3. The real problem is the 3 brothers. The definition mentions "...restrictions...". Accepting that we are currently building the data dictionary and not the product specification, and that the binding shown here is only our feeling for the way attributes could be combined in a product, do we need rcmdts and reglts? What I am really getting to is, if the restrictions are fully covered by the attributes, could we remove resdes as well? If we could, that would remove one of our cases where we have an association between info objects.

4. If we do want to keep rcmdts and reglts, we should probably include these ideas in the final phrase of the definition, along the lines "...and an indication of the recommendations, regulations, and restrictions that apply."

DavidAcland 17:50, 21 January 2009 (CET) This used to be restvc

jens 19:09, 21 January 2009 (CET) Make sense. I haven't got objections.

Raphael This object may need a little more clarification about where it should and should not be used. It is tempting to use it everywhere one wants to encode information that depends on vessel characteristics, e.g., compulsory pilotage requirements.

How would "AND" clauses be expressed? For example "single hull tank barge carrying 5000 or more barrels of oil or other hazardous material". Relatedly, if limitations are expressed in terms of both AND and OR clauses, then we may have problems. (A hypothetical example would be "oil tankers carrying more than 10000 barrels, or single hull tank barges carrying more than 5000 barrels of oil". I don't know of such a limitation, but perhaps something like it might be in force somewhere? raphael 07:07, 23 March 2009 (CET)

Update: From the discussion below it appears "AND" combinations are not covered by the coded attributes, and such "AND" combinations would have to be in plain text in the INFORM or TXTDSC of the associated resdes/rcmdts/reglts object?

Also, are capacity bounds expressed in terms of "barrels" needed? raphael 07:44, 23 March 2009 (CET)

jens 19:54, 24 March 2009 (CET)

Raphael, thanks for your comments made. I was not in the office today so I apologize for not having replied earlier. I will try to develop an answer for the first topic tomorrow. (including your update comments)

Regarding the second topic I have in mind, that the "barrel" problems was addressed to TSMAD who should be responsible for the several UNIT attributes. A paper addressing this problem was passed to them. We awaiting their response in due time.

jens 09:10, 27 September 2009 (UTC)

Propose adding "Under Keel Clearance". Authorities moving towards defining UKC rather than maxdrf. That based on investigations showing different interpretations of maximum draught (for, middle, aft, middle of the three, I hpe I got them all :=) ). Examples can be seen in certain Baltic waters. The only problem is that no confirmed definition for UKC exists.
However, that should not hinder us to insert the limitation type to CHALIM. Any objections or consents pls?

raphael 06:49, 2 October 2009 (UTC): UKC sounds like a good idea. The specification will be interesting because UKC is sometimes specified in feet/metres and sometimes as a percentage of the vessel's draft.

3 brothers in relationship to this object

I hoped that would be quite simple, but...

What was our intention with this object? We intended to cover ALL limitations (restrictions, regulation, recommendations). That is probably too much. I checked this object against the other information objects. All (nearly all) have the DATEND; DATSTA; NOBJNM; OBJNAM; PEREND; PERSTA as type A attribute. (by the way, I think we should add those where they are not been added yet)

I thought that was the key to solve the problem. In a first view I recommended to put DATEND; DATSTA; NOBJNM; OBJNAM; PEREND; PERSTA to restvc and to delete the three brothers. We can handle the relationship between the geo object (where the limitations apply) and the restrictions of vessels and well as our three (four if we add nautical information) brothers. That would work fine anyway and I really recommend to do it.

Adhering to this, we will have one major problem. How to handle different limitations and brothers for different types of vessels for the same geo object? One way, the easiest for us, is to continue our initial idea to add inf object to inf objects. The other idea is to handle the reference within the geo object by using ...I don't know. INFORM - bad. Within the written text of the brothers - I'm not convinced that it works. Where else?

To summarise my ideas, the only one which solves all problems is to continue with inf object to inf object and to improve the definition in a way that "restrictions" will not be shown. Independently from that we should add DATEND; DATSTA; NOBJNM; OBJNAM; PEREND; PERSTA as well to make the "normal" handling convenient to the modeller.

David, what do you think? My mind (the German and the English one) is at the death end.

DavidAcland 18:41, 20 January 2009 (CET) OK. I will try it. In any case we are not likely to have lots of combinations of vessel type, cargo types and say length. In many cases we will only have one characteristic in play, say, draught, breadth or cargo. Similarly there may be recommendations for vessels over a particular length of all type of vessel or cargo.

So if we want to widen this beyond "restrictions" to all 3 or 4 brothers, this sounds a bit like "cause and effect"; i.e. "With this condition, this is the impact - result - advice - outcome ..." Of these I prefer "impact" in the way that we write "impact assessments" to indicate the likely effect of a course of action. So this could give us an object called "Impact of vessel characteristics". I will mull this over a bit more and work on a tweek to the definition along these lines.

Talking to Mal tomorrow, 21 Jan, about the value or otherwise of nautinf and to Barry about Info-Obj to Info-Obj associations. Brgds, David

DavidAcland 11:01, 21 January 2009 (CET)

Discussed with Mal.

We concluded that we should build on your idea of "limitations". This is much better than impact and very similar in meaning to "restrictions" but it is a different word and therefore should prevent confusion and ease the semantics. We also think that we should remove the final clause of the defintion, "... and an indication of what restrictions apply."; just leave it blank. It goes without saying that the associated Info objects amplify the origianl information.

We think that natinf should be added to the 3 brothers more or less everywhere. This would allow for the neutral case, where information is provided for the Master to take into account in relation to the current plan being developed or executed.

Met Barry.

What we are doing is fine and is already catered for in the model. We are effectively using a Master/slave relationship, even between Info Objs. As I now understand it, the problem would have been with some other type of "named relationship".

Asked Barry about NOBJNM and OBJNAM on Info Objs. He said that that was fine. In the case of Regulations this is likely to be the name of the Act of Parliament, (i.e. Marine Bill 2007), national regulation, or the Harbour Regulation. These would probably not be populated in the case of natinf, which is likely to be a reported fact.

Redrafted along these lines.

Replaced the following remarks:

This object is used to describe the conditions under which restrictions apply to vessels in a specified area. Restrictions apply to vessels which:

• match one of the values in the ship type attribute;

• exceed the value of one of the “max” attributes or;

• do not meet one of the “min” attributes.

As an example of how this object could be used, ship dimensions or type of cargo could be used in combination with a specified area in which regulations (e.g. length limit or type of cargo restrictions) apply.

jens 13:10, 21 January 2009 (CET) As I always knew, three minds create more thoughts than one. Thanks for your investigations and Mal's and Barry's feedback. I think we got it. I see that there is a way to handle the relationship between different inf object by using OBJNAM and with the geo object by master slave . I my opinion it looks fine now. If you will agree I will follow you soonest.

DavidAcland 14:15, 21 January 2009 (CET)

Good. I have unticked your approval on all 4 brothers because I have made several edits to each in line with this discussion.

jens 04:57, 24 August 2009 (UTC)

Two new attributes proposed by Raphael

LIMTYP to be found at FDD page now

CATRGY to be found at FDD page now

raphael 20:26, 12 February 2010 (UTC): How about adding LIMTYP and CATRGY as proposals to the main CHALIM page too so they don't get overlooked?

CHALIM and Jussland Radio Signals data set

raphael 21:03, 12 February 2010 (UTC): CHALIM does not envisage logical conjunctions ('AND') of its attributes, so encoding limitations such as this (from the Jessland List of Radio Signals) is not easy:

Pilotage is compulsory for the following vessels in the Pilotage District:
...
(ii)Vessels or tugs and tows of 50m or more in length overall which are specified vessels, passenger vessels and vessels carrying marine pollutants in bulk
(iii)Vessels or tugs and tows of 50m and up to 90m in length overall with an operating draught of 6m or more
(iv) Vessels or tugs and tows of 50m and up to 90m in length overall with an operating draught of 4m or more when restricted visibility exists.

I'm thinking of suggesting using an extended version of OPERAT: extend the definition of OPERAT by adding two allowed values, corresponding to 'logical conjunction' and 'logical disjunction'; add it as an attribute of CHALIM.

We could restrict the allowed values of the CHALIM/OPERAT binding to 'logical conjunction' and 'logical disjunction'. (S-100 can do this; otherwise it would have to be an encoding rule.)

An alternative is to define a new attribute ('Logical connective'?) that can take one of two allowed values corresponding to 'logical conjunction' and 'logical disjunction'.

It is also possible to define a small 'expression language' so we could write conditions like:
(vessel.loa >= 50.0) AND (vessel.loa <= 90.0) AND (vessel.draught >= 6.0)

jens 11:24, 15 February 2010 (UTC) That sounds logical. If S100 allows the logical conjunction/ disjunction go ahead. I would prefer seeing those values added to OPERAT. Keeping them together is better than opening a new attribute whose meaning will be very close to other attributes meaning.
BTW the SDs Jade mapping has also such difficult constructions which are currently modeled by REGLTS/TXTDSC. The information could be more "customized" using "logical conjunction".

raphael 00:16, 16 February 2010 (UTC): Draft for logical connectives added to Talk:OPERAT.

raphael 03:01, 17 February 2010 (UTC): As currently drafted, the specification for CHALIM allows only logical-OR combination of the conditions specified by its attributes:

This object is used to describe the characteristics of vessels, which limit the passage of a vessel, or the use of a facility by a vessel, because the vessel is:

• carrying ballast water.
• matches one of the values in the ship type, cargo type or dangerous or harzardous cargo type attributes;
• or does not match the performance requirements;
• or exceeds one of the “max” attributes or;
• or is less than one of the “min” attributes.

If we introduce logical connectives (see discussion in OPERAT) the Remarks should be updated. Here is a tentative revision of the Remarks:

This object is used to describe the characteristics of vessels, which limit the passage of a vessel, or the use of a facility by a vessel. The characteristics of individual vessels are compared to values of CHALIM attributes to produce boolean values as specified below (missing attributes or null-valued attributes are ignored and not used in evaluation):

• BALAST: TRUE if the vessel is carrying ballast water, FALSE if it is not.
• Category attributes: TRUE if the vessel (or its cargo) match any of the values of the attribute, FALSE if it does not. (Note that some CAT- attributes may have multiple values - see examples.)
• Performance attribute (PRFMNC): TRUE if the vessel does not meet the requirements described in the performance text string, FALSE otherwise.
• Ice capacity: TRUE if the vessel cannot transit ice of the specified thickness, FALSE if it can.
• Under-keel clearance: TRUE if the vessel does not have the required under-keel clearance, FALSE if it does.
• MAX- attributes: TRUE if the vessel characteristic exceeds the given value, FALSE otherwise.
• MIN- attributes: TRUE if the vessel characteristic is less the given value, FALSE otherwise.

The resulting boolean values are combined using the logical connective specified by OPERAT. If the result is TRUE the vessel is included in the limitation described by this CHALIM.

Example:
MAXLOA=50.0, CATVSL=3 (tanker), OPERAT=3 (and): tankers with LOA > 50.0 m.
MAXLOA=50.0, CATVSL=3, OPERAT=4 (or): tankers, or any vessel with LOA > 50.0 m.
MAXLOA=50.0, MINLOA=90.0, OPERAT=3 (and): vessels with LOA between 50.0 and 90.0 m.
MAXLOA=90.0, MINLOA=50.0, OPERAT=3 (and): vessels with LOA over 90.0 and less than 50.0 (a logical impossibility).
CATCGO=5,6, ICECAP=080, OPERAT=4 (or): all vessels carrying either passengers, livestock or both and vessels carrying anything but capable of transiting only 80 cm or thinner ice

As an example of how this information object could be used, ship dimensions or type of cargo could be used in combination with a related geographic object, in which regulations (e.g. length limit or type of cargo restrictions) apply.

jens 10:05, 8 April 2010 (UTC) I do have problems to understand the examples. They max/min is opposite to the definition given in the referring attributes. Can one check that?

DavidAcland 11:30, 9 April 2010 (UTC) Perhaps the difficulty is with the CHALIM definiton. This talks about "limiting" passage, but the attributes talk about "... allowed ... ". The result is that under Raphael's rules if our vessel exceeds the MAXLOA the result is TRUE and so passage is limited, or the regulation applies.

I think I agree with Jens. Examples 2 and 3 look as though they are reversed. Example 2 would be OK for vessels below 50.0m; limited for 50 - 90m; and OK again for vessels over 90n LOA; all a bit unlikely.

Example 3 looks OK for vessels between 50 and 90m.

raphael 16:59, 9 April 2010 (UTC): The difficulty is indeed with the definition of CHALIM, I remember struggling with it back in 2008, especially the combination of "...limit the passage..." with "or exceeds one of the "max" attributes", "or is less than one of the "min" attributes".

jens 17:05, 11 April 2010 (UTC)
I need a couple of more days. As far as I understand, we have two different approaches so far. with or Without logical operators, is that true? If that is true we have to decide which way we will go in the future. At the moment I have no idea. For the mapping we need a common solution.

Simplified version of Characteristics ...

raphael 01:29, 21 June 2010 (UTC): Discussions during mapping and writing use cases suggest that the names, definitions and use of the MAX- and MIN- attributes are hard to understand and use. Here is a simplification which replaces the MAX- and MIN- attributes with numeric ranges (new _HI and _LO attributes), which should be less ambiguous. (This situation cries out for using range notation, e.g., LengthOverallRange =[50.0, 90.0], but S-100 discourages it.)

I also updated the attribute list with CATRGY, LIMTYP and LOGCON, which were proposed earlier.

jens 04:51, 7 July 2010 (UTC)

Generated a new page APPLIC; the discussion related to the new idea introduced during SNPWG12 will be continued there.