Difference between revisions of "Talk:VSLMSM"

From IHO Nautical Information Processing Working Group
Jump to navigation Jump to search
Line 13: Line 13:
 
[[User:Jens|jens]] 09:25, 13 October 2010 (UTC)beside your discussions I amended the resolution of the VSLVAL to real to reflect the results of the discussion at [[VSLVAL]]
 
[[User:Jens|jens]] 09:25, 13 October 2010 (UTC)beside your discussions I amended the resolution of the VSLVAL to real to reflect the results of the discussion at [[VSLVAL]]
  
[[User:Jens|jens]] 10:30, 13 October 2010 (UTC) sorry Raphael, I have problems in understanding that correctly. <br> Using your case 1 (multiplicity =1) one will be forced to create several instances of [[VSLMSM]] to create example 5 (see page). Do I see it correct?
+
[[User:Jens|jens]] 17:26, 13 October 2010 (UTC) sorry Raphael, I have problems in understanding that correctly. <br> Using your case 1 (multiplicity =1) one will be forced to create several instances of [[VSLMSM]] to create example 5 (see page). <br>
 +
Let's try to explain it with an example:<br> Saying example 5 which is to model <br>
 +
  tankers with LOA > 50.0 m and < 100.0 m must use the PILBOP
 +
 
 +
Using your case 1 I have to model<br>
 +
PILBOP it the feature<br>
 +
APPLIC is the associated information object <br>
 +
LIMTYP 2 (required)<br>
 +
LOGCON 1 (and)<br>
 +
CATVSL=3 (tanker)<br>
 +
# VSLMSM [VSLCAR=10 (L.O.A.) VSLVAL=50; VSLUNT=1 (m) COMPOP= 1 (>)]<br>
 +
# VSLMSM [VSLCAR=10 (L.O.A.) VSLVAL=100; VSLUNT=1 (m) COMPOP= 3 (<)]<br>
 +
 
 +
 
 +
 
 +
Using your case 2 I have to model<br>
 +
PILBOP it the feature<br>
 +
APPLIC is the associated information object<br>
 +
LIMTYP 2 (required)<br>
 +
LOGCON 1 (and)<br>
 +
CATVSL=3 (tanker)<br>
 +
#VSLMSM [VSLCAR=10 (L.O.A.); VSLVAL=50; VSLUNT=1 (m); COMPOP=1 (>)], [VSLCAR=10 (L.O.A.); VSLVAL=100; VSLUNT=1 (m); COMPOP=3 (<)]
 +
 
 +
If my interpretation is correct I would prefer option 2. That is only a feeling based on experiences when trying to bring SDs information into our German SDs style. I think our feasibility study has examples saying this and this is in force for <br>
 +
vessels of 50 m in length and above or 15 m in beam or above or over 6 m in draught. My feeling says to me that case 2 is the easiest way for an encoder to transfer the SDs information. <br> What do you think?

Revision as of 17:26, 13 October 2010

DavidAcland 11:10, 5 October 2010 (UTC) I have added a "Units" attribute VSLUNT. I have also changed the multiplicity of the sub-attributes VSLCAR and VSLVAL to make them mandatory.
Multiplicity of VSLUNT is also 1 at the moment but see my post on 5 Oct at Talk:VSLCAR.
I think we can only have a maximum of 2 COMPOPs so I have changed the multiplicity here to 0..2
Does this now work?

raphael 03:28, 8 October 2010 (UTC): I don't see why the number of COMPOPs should be limited to 2, each COMPOP compares the specified characteristic from own ship data to the VSLVAL with which the COMPOP is associated.

Actually the table of sub-attributes on VSLMSM as it is today (07 October 2010) should be changed to have either:

  • multiplicity = 1 and sequential = "n/a" for all rows; and we allow VSLMSM itself to be repeated; or
  • multiplicity = 1..* and sequential = "true" for all rows, and we don't allow VSLMSM to be repeated.

The first means that each instance of VSLMSM describes exactly one condition (so "50m <= vessellength <= 100 m" takes two VSLMSMs). The second puts all conditions under one VSLMSM, but "sequential = true" implies that each VSLCAR+VSLUNT+VSLVAL+COMPOP combination in that VSLMSM specifies one condition (this should be explained in the Remarks or the encoding guide).

jens 09:25, 13 October 2010 (UTC)beside your discussions I amended the resolution of the VSLVAL to real to reflect the results of the discussion at VSLVAL

jens 17:26, 13 October 2010 (UTC) sorry Raphael, I have problems in understanding that correctly.
Using your case 1 (multiplicity =1) one will be forced to create several instances of VSLMSM to create example 5 (see page).
Let's try to explain it with an example:
Saying example 5 which is to model

  tankers with LOA > 50.0 m and < 100.0 m must use the PILBOP 

Using your case 1 I have to model
PILBOP it the feature
APPLIC is the associated information object
LIMTYP 2 (required)
LOGCON 1 (and)
CATVSL=3 (tanker)

  1. VSLMSM [VSLCAR=10 (L.O.A.) VSLVAL=50; VSLUNT=1 (m) COMPOP= 1 (>)]
  2. VSLMSM [VSLCAR=10 (L.O.A.) VSLVAL=100; VSLUNT=1 (m) COMPOP= 3 (<)]


Using your case 2 I have to model
PILBOP it the feature
APPLIC is the associated information object
LIMTYP 2 (required)
LOGCON 1 (and)
CATVSL=3 (tanker)

  1. VSLMSM [VSLCAR=10 (L.O.A.); VSLVAL=50; VSLUNT=1 (m); COMPOP=1 (>)], [VSLCAR=10 (L.O.A.); VSLVAL=100; VSLUNT=1 (m); COMPOP=3 (<)]

If my interpretation is correct I would prefer option 2. That is only a feeling based on experiences when trying to bring SDs information into our German SDs style. I think our feasibility study has examples saying this and this is in force for
vessels of 50 m in length and above or 15 m in beam or above or over 6 m in draught. My feeling says to me that case 2 is the easiest way for an encoder to transfer the SDs information.
What do you think?