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)

DavidAcland 11:37, 1 April 2009 (CEST) Hi Raphael,

Mostly good points and it looks as though we agree. The general point about more than in/out is good but "shifting berth" would not be a good example. The pilot would go to the current berth by road or boat. But there might well be river pilot transfer points but these are probably in the inland ENC domain. Agree a little more thought might produce a third or fourth case and so Type Enumeration would be best.

I will draft the changes later today.

I spoke to Ernie yesterday about starting work with Eivind on the Product Spec for the SNPWG PILBOP work decided at Norfolk so this could be in use quite soon in that work. Ernie will try to get these Features and attributes into the IHO NPUB register. David.

jens 12:30, 1 April 2009 (CEST)

Generally I agree with the new proposals.

Initially I thought to use the same object twice or several times. That would cover the problems in the first approach.

Problems will occur trying to model a situation like: a PILBOP is been used for one type of the vsl as primary outbound and for another type of vsl secondary inbound . Ok, that is a very artificial construction, but not unlikely. Thus I confirm to combine all options by attributes in one object rather than my initial idea.

DavidAcland 15:52, 1 April 2009 (CEST)

On the name for the "Arrival or Departure" attribute my feeling this morning was to go with the chart. Now I see BA charts use "Inbound" and "Outbound", "Embarkation" and "Disembarkation" and "Boarding" and "Landing".

Jens and I have spoken. We believe we have three cases: Embarkation; Disembarkation; and Change Pilot (also known as "Shift pilot", "Exchange pilot" and "Handover Pilot). So the name needs to encompass all these ideas. The common theme is the movement of pilots so I am now warming to the name for the attribute to be "Pilot movement" with acronyn pltmov.

jens 20:28, 1 April 2009 (CEST)

Me again. I have had a good run this evening which clears my mind a bit. The reflection of the discussion between David and me is correct. The definitions kindly developed and provided by David work fine for me. Reading the definitions on pltmov I wonder that all entries talking about a kind of boarding; disembarkation is a negative embarkation using a pilot vessel to pick up the pilot and pilot change needs a pilot vessel too. Why not adding them here using L-Type attribute? I know, the L-Type is a bit controversially discussed. But per definition it allows to have 1...n entries. Means we may have constructions using only one attribute value like "primary" and may construct "primary embarkation" as well. What do you think?

Raphael: I forgot to mention that I was thinking about whether Arrival/Departure (as it then was) could be used with other objects too (which is why I thought about "shifting"). But defining it as pilot movement is fine because it is clear that this attribute focuses on what is happening with the pilot rather than the vessel. So I agree with pltmov.

Making catpbp of type L and extending its value set to include embarkation-related values as well as primary/alternate makes it like a complex attribute (but with less structure). Might this not make the encoder's job more difficult, and also complicate the processing software/ECDIS? On the other hand, using type E and pltmov would indeed make multiple coincident PILBOP objects necesssary sometimes. Which would be the better overall bargain? --raphael 00:22, 2 April 2009 (CEST)

Raphael: FYI, Eivind, John Parrott, and I are having an ongoing discussion about pilotage. There may be some discussion about other parts of the pilotage model later via Eivind... --raphael 00:31, 2 April 2009 (CEST)