Talk:Catpbp

Request clarification of when inbound/outbound would be used rather than primary/alternate. Since the type is E, coding a place with, for example catpbp=1,3 (primary, outbound) would not be allowed.

One possibility is changing the definitions of the values to encode combinations (e.g., 1= inbound primary, 2=inbound alternate, 3=outbound primary, 4=outbound alternate). (This may require that the type be changed to L so that places that are both inbound and outbound can be encoded.)

Another possibility: 1=inbound and outbound primary; 2=inbound and outbound alternate; 3=inbound only, primary; 4=outbound only, primary; 5=inbound only, alternate; 6=outbound only, alternate.

(The potential problem I see with these is that more values make encoding errors more likely...)

In some places, there are different boarding places for vessels of different draft. Might it be necessary to specify how such boarding places must be encoded (e.g., all "primary")?

Revised --raphael 22:28, 23 March 2009 (CET)

I just noticed that "4: inbound" is a value for catpbp, as well as "inbound" being one of the string values suggested for dstntn. Both catpbp and dstntn are attributes of PILBOP. --raphael 07:54, 25 March 2009 (CET)

DavidAcland 15:15, 30 March 2009 (CEST) Hi Raphael,

Thank you for these posts.

We have discussed these attributes quite a lot in the past and had an attribute "Direction" to handle the In/Out pair. We also had to contend with the Upriver/Downriver pair as well as other similar pairs, triplets and long lists of destinations. It is also quite common to see PILBOPs which carry descriptors such as "Tankers". As this was moving towards the "endless list" we settled for the unstructured dstntn as a string.

I do recognise that Primary/alternate and In/Out are apples and oranges and we should prevent that illogical structure. To remove the encoding ambiguity we could remove the enumerations 3 and 4, leaving just the Primary (1) and Alternate (2). Alternatively we could remove the "inbound" example from dstntn, revert to our earlier model and limit the options for "direction" to "arrival" and "departure". Unfortunately this does not always translate into "pick up" and "set down" because in some cases a Deep sea or Channel pilot is disembarked as a port pilot is embarked and vice versa. Also "Direction" is not the best title because it is too close to "Directions", which means something quite different, so we would need to find a different name perhaps "Arrival or departure".

If we went this way we would have catpbp and "Arrival or Departure" with either 2 enumerations each or as type Boolean; and we would keep dstntn shawn of the example "inbound"; and we could add catvsl to deal with the "tankers" case in my opening paragraph above.

Would that solve the problem?

raphael Hello David, I agree about catpbp and catvsl, and about retaining dstntn as an unstructured string. Arrival/departure needs more thought.

• I think the model needs an attribute for arrival/departure, otherwise it would be difficult for a program to classify and sort PILBOP objects by vessel arrival/departure (assuming such classification would be useful for future applications - I strongly suspect it would be).
• Should that attribute address only arrival and departure, or also cover certain other movements such as shifting berths? I think it should (tentatively) cover just arrival/departure but be an enumeration so that its value set can be extended if necessary.
• I believe places used for both arrival and departure would be represented by the absence of this attribute.
• It does open the door for encoders to use either dstntn or arrival/departure to represent inbound/outbound, but dstntn as an unstructured string is definitely needed, so I don't see an alternative.
• I can't think of a better name for "arrival or departure", but I'll keep thinking about it.

So I think we end up with 4 attributes:

• catpbp: 1:primary; 2:alternate
• catvsl: (as described on its own page)
• dstntn: Any string value not representable by "arrdep"
• arrival or departure (arrdep)?: 1: arriving or approaching; 2: departing; Type: E (if there are more than 2 values, L might be better)

Thank you for considering this. It is up to you to decide what weight to give to the different points I made.

--raphael 09:44, 31 March 2009 (CEST)