Talk:APPLIC

---

The _HI and _LO attributes can be defined like this:

Definition: Draught, upper bound

Acronym: DRF_HI

Camel case: DraughtUpperBound

Attribute type: F

Definition: The upper bound of a numeric range for vessel draught.

Resolution: 0.01 m or 0.01 ft

Format:

xx.xx

Example:

12.56 for a maximum draught of 12.56 metres.

Remarks:

No remarks

jens 06:35, 6 July 2010 (UTC)

ok, I understand that. It sounds logical.

May I point to two items I identified as either being a problem or offering room for improvement. 1. How works LOGCON 2? I have problems to develop and to understand an example which satisfied me.
Using your first example I would assume that if LOGCON is been set to 2 the regulation applies for either vsl over 50 m length or tankers. Is my assumption correct?
2. I discussed the problem with Martin this morning and some very interesting ideas are on the table now.
Is it thinkable to state certain characteristics like draught, length, beam, air draught etc. as complex attributes and introduce logicalComparisonOperator.
That would reduce the quantity of attributes used and offers much more flexibility. A further reason why I am suggesting the complex type is that in the two examples you provided only max and min parameters are settled. The term "vessels of 50 m length or more" is not settled.

Example:

Attribute: name to be defined
Attribute type: Complex

Sub-attribute	Camel Code Identifier	Multiplicity	Sequential
VSLCAR	vesselsCharacteristics	0..*	True
????	value	0..*	True
COMPOP	logicalComparisonOperator	0..*	True

VSLCAR (length, beam, draught, air draught, GT, NT, DWT, DPL ) is just an idea, depending on the result of the discussion, we can keep or bin it.
COMPOP has to be to developed and should provide various comparison operators; see http://de.wikipedia.org/wiki/Logische_Operatoren or the English version http://en.wikipedia.org/wiki/Logical_connective
However, the German version provides the better symbols :)
The definition of LOGCOM must provide the relation between the value given in the model and the real ship's value.

That would give the result:
1. VSLCAR=draught; value=10.5; COMPOP=(>=) the regulation applies for vsl of 10.5 m draught and above
2. VSLCAR=DWT; Value=2000; COMPOP=(=) the regulation applies for vsl of exactly 2000 DWT
3. VSLCAR=length; value=150; COMPOP=(<) the regulation applies for vsl of less than 150 m length

Using your first example
[complex attribute [VSLCAR=length; value=50.0; COMPOP=(>)]], CATVSL=3 (tanker), LOGCON=1 (and), LIMTYP=2 (required); associated to a PILBOP object: tankers with LOA > 50.0 m must use the PILBOP

If the example should work for tanker between 50 and 100 m length the coding is like this
[complex attribute [VSLCAR=length; value=50.0; COMPOP=(>)], [VSLCAR=length; value=100.0; COMPOP=(<)]], CATVSL=3 (tanker), LOGCON=1 (and), LIMTYP=2 (required); associated to a PILBOP object: tankers with LOA > 50.0 m and < 100.0 m must use the PILBOP

What do you think?

raphael 22:46, 6 July 2010 (UTC): Only short answers today; let's create a new page for APPLIC and discuss it there (no need to make new pages for its new attributes yet, we can discuss them on the Talk:APPLIC page).

The new complex attribute is theoretically OK. I want to think about the practical issues some more: how easy/difficult it might be for encoders to understand; integer vs. float limits; specifying data validation tests.

ComparisonOperator (COMPOP) is better than LOGCOM (which is likely to be confused with LOGCON).

LOGCON=2 (or): Yes, that is how it would work (and a HI/LO pair would define a range, not separate conditions).

jens 04:58, 7 July 2010 (UTC) ok. I replaced LOGCOM by COMPOP.

I don't understand your reservation against Integer vs. Float from 2 views:
1. From the ship's theory point of view it is not impossible to provide also information which is currently given as Integer as Float or vice versa. Indeed, ship's theory information on GT or NT are rounded to Integer after a high accuracy calculation with Float.
2. From the data point of view I think it is not impossible for software developer to calculate with Float in the BE although Integer is presented to the FE user and vice versa.

raphael 23:52, 8 July 2010 (UTC): (1) I agree in principle with the VSLCAR-COMPOP idea.

(2) Making NewComplexAttribute itself repeatable (instead of its sub-attributes) might be easier for humans and software (encoders, validators, displays). That is, for vessels of length 50.0 to 90.0:

NewComplexAttribute(VSLCAR=length; COMPOP=(>=); value=50.0)
NewComplexAttribute(VSLCAR=length; COMPOP=(<=); value=90.0)

instead of
NewComplexAttribute(VSLCAR=length; COMPOP=(>=); value=50.0; VSLCAR=length; COMPOP=(<=); value=90.0)

(The integer/float issue is a bit complicated...it might be better on its own page.)

We need to work on watertight and simple definitions for the new attributes and sub-attributes.

jens 06:57, 9 July 2010 (UTC)
I have no objections against the multiplicity of NewComplexAttribute instead of multiplying sub-attributes. That sounds good to me too.
I have initiated the integer_float page. If we need to have it just follow the link I set in your post. :)
I will discuss the definition part with David. If we all agree to follow the complex/COMPOP idea it is time to do some work on that. Perhaps we should replace VSLCAR by VSLDIM (vessel's dimension). I will discuss that with David.

DavidAcland 10:52, 13 July 2010 (UTC)

I do not see the essential difference between the Max and Min attributes and the Upper and lower bound. Is the problem the word "allowed"?

And w.r.t. Jens's question about "Vessels of 50m length and more", is this not just "MINLOA = 50m" ?

DavidAcland 14:59, 13 July 2010 (UTC)

Direction of travel discussed with Jens 13 Jul. This is becoming pretty technical and I agree with Raphael, that we need to keep in mind the encoders. We should work hard to keep the concepts and the language as simple as possible. On the other hand the approach which reduces the number of attributes on CHALIM or APPLIC also seems sound to me.

I agree that integer will probably serve us better than float. I do not believe the encoders will see the difference because I would expect the production software to make the conversion from a sensible draught of 10.3m to 10300 if we select integer with three decimal places. Although I do not understand why it would make a difference, we have already decided to try and use gml instead of ISO8211 for the MPA product specification.

I have not thougtht about LOGCON before. Now after just a few hours thinking about it, it seems a bit uncertain to me. When we have possibly 10 or more other attributes on CHALIM or APPLIC, the concept of all being true or just one not being true seems problematic. And in a pair of cases, in one a vessel is over 100m in length but does not have a pilot on board, and in the other the vessel is not over 100m in length but does have a pilot on board, LOGCON = 2 but the regulations are probably different. So at the moment, I can see the simple case, but not that it is unambiguous in all cases. I think we are back to Jens's word of the month "bijective". It feels as though the idea could be useable and workable in a complex attribute; in a feature with multiple attributes, it is looking more difficult. Perhaps we have to limit the use of LOGCON to a small group of attributes.

On the LOGCOM versus COMPOP acronym discussion, I would prefer to keep both starting with "LOG". This follows the convention we have used elsewhere, where similar pairs or groups of attributes have similar acronym constructions. There is already and S-57 attribute COMCHA and in that instance the "COM" stands for "communication". I therefore propose "LOGCOP". Interesting though how we are worrying about something which will not even exist in S-100 because it will all be CamelCase. Another way to increase the difference to LOGCON might be to change that acronym as well.

So I think it is worth pursuing APPLIC with Jens's complex attribute "name to be defined" above. I need to be convinced about LOGCON.

raphael 06:24, 20 July 2010 (UTC): I agree that the new complex attribute ("Condition"?) is worth pursuing. Jens, feel free to make new pages and revise APPLIC, or tell me if I should make the new pages...

About LOGCON: For the two cases, there would be two different APPLIC objects, one for "(length > 100 m) and (without a pilot on board)", the second for "(length <= 100 m) and (with a pilot on board)".

If a condition is too complex, it can be split up into different APPLIC objects.

If we want to say "not X", for example, "cargo is not dangerous or hazardous" we need logical negation (I thought we could simplify things by leaving that out, but will now try to make up a simple way to include it).

(Acronyms/names - let's think about them some more - calling >, <, >=, etc., "logical" does not sound right - to me "logic" means AND, OR, NOT, IMPLIES, etc.)

DavidAcland 14:12, 7 October 2010 (UTC)
New subject. In late September and early Oct 2010 we discussed whether the Register of a vessel would be required and if so, how to capture it. S-57 NATION at the moment leaves out many countries with Shipping Registers, including several with large tonnages. Decided to make no change to our model at this stage but to suggest to TSMAD that NATION is brought up to ISO 3166-1 or that S-100 directly refers to this instead of being an Appendix of an Annex of an internal IHO publication, as at the moment. If we find we do need to capture vessel's Register in the near future, we can add NATION to APPLIC to see how it would work but with the understanding that NATION is incomplete and leaves out important Registers.

jens 08:17, 15 October 2010 (UTC) David, who is bringing the NATION issue to TSMAD attention?

DavidAcland 16:37, 5 November 2010 (UTC) TSMAD reported at HSSC in Rostock that S-57 Annex A was either going to be reviewed or removed but they are still just thinking of "Producing Agency" rather than the more generic use of nationality. I think this is now covered but needs watching.

jens 13:58, 4 November 2011 (UTC) Do we need to add "Speed"? It is possible that certain reg/res/rec/ninf apply only for vessels with specific/less or more speed.