Talk:CATRXN

raphael 05:23, 17 August 2009 (UTC) :

A new attribute Category of regulation / restriction / recommendation is proposed. CATRXN (Category of regulation/restriction/recommendation) is a means of categorizing regulations, restrictions, and recommendations by sailing directions topic. Categories include pilotage, traffic, anchorages, etc. Applications would use CATRXN values when they need to collect objects of a class - for example, when they collect all information objects for a specified place that pertain to pilotage, perhaps to display a box with "all pilotage information for place X" on the screen.

Specification (has evolved since the draft pilotage specification)

jens 08:44, 15 September 2009 (UTC)

IMO that makes sense, more than RXNCOD. At the moment I don't see any missing items. We should give it a try. The only thing we have to ensure is that ProdSpec should clearly explain that this is only to describe res/reg/rec pertaining to the information given in the associated information object. We should not run the risk that one is trying to e.g. place natural conditions (value 11) information here.

jens 09:51, 17 September 2009 (UTC)

o.k. the more I m thinking on that the more I am not really convinced that we should use that. e.g. additionally to the problem I posted 15 Sep I am asking: Why not associating the rec/res/reg to the feature which described the topic? We do have pilotage, anchorage, hazards etc. as feature available. In that case value ID 17 would cause a
feature (XX)
.CATRXN=Restriction
.. further attributes
association to RESDES
.TXTDSC (text file).

Looks curious.

Would it not a more efficient way to model
feature (XX)
. further attributes
association to RESDES
.TXTDSC (text file).

That looks better to me.
We know the res/rec/reg belong to that particular feature. Is it really necessary to categories them?
The above example can be adapted by various other attribute value IDs of this proposed attribute.

raphael 20:59, 17 September 2009 (UTC): CATRXN is supposed to be an attribute of the rec/reg/res information object. The feature object would also be associated with the rec/reg/res object (i.e., FeatureX -> RESDES). This is the same as the more efficient way above (Note 1), with the addition that RESDES has a CATRXN attribute. The Remark or encoding guide can stress that the information object is only to describe the regulation (rec/res) and nothing else. I think this also implicitly answers the September 15 question?

As S-100 is currently written only the link FeatureX -> RESDES is allowed, a link from RESDES -> FeatureX would not be allowed (one of our comments to TSMAD asked for the reverse link to be added). Without CATRXN, the only way to know what the reg/rec/res pertains to is when it is accessed through the FeatureX object. I think this makes application design more complex than it need be.

Further, if all rec/reg/res objects are attached only to "special-purpose" objects like PLTSRV or PILBOP, and each such "special-purpose" object pertains to exactly one kind of information then it is possible to classify the reg/rec/res without CATRXN. But if the reg/rec/res is attached to a "general-purpose" object like SEAARE or ADMARE it is not.

Also, there may be different kinds of reg/res/rec for a specific area. If CATRXN is allowed to take any values from its enumeration we can separate different kinds of reg/rec/res even if they are associated with the same feature object.

Note 1: I am assuming TXTDSC does not change anything relevant to this discussion.

DavidAcland 12:21, 20 December 2009 (UTC) Please accept my late entry to this discussion.

I am currently uncomfortable with CATRXN and RXNCOD but am open to persuasion. I hope that the Waterway dataset will help with that discussion. This is central and I remember debating this with Johannes Melles in Copenhagen in October 2005. What we will have to do, to make codification work, is interpret often very subtle drafting of regulation into a discrete number of enumerations. The difficulty comes when we try to match the subtlety in written text by increasing refinement in the model design. To succeed what we will have to do is compromise between the "endless list" and a list of enumerations, which does not quite reflect all the shades of grey carefully crafted into regulation or advice in NPubs.

Now we may try again but it is worth noting that the UKHO SD for the US E coast between Delaware and Cape Canaveral contains verbatim extracts extending to nearly 30 pages from Code of Federal Regulation Titles 15 (Commerce and Foreign Trade), 33 (Navigation and Navigable Waters) and 50 (Wildlife and Fisheries). I have not checked the other SDs for US coasts but I expect them to be comparable.

To succeed, what we will have to do is have both; that is an encoded paraphrased coarse cut view of the regulation, but also supply a link to the full text. That is effectively, what we do now on paper using text for the "coarse cut" view as well.

While not yet persuaded, I will help develop these attributes and see where they take us.

DavidAcland 18:42, 20 December 2009 (UTC)

To analyse the proposed semantic groups, I have re-ordered the list along the following general lines:

passage, including deep sea and coastal; approach, including port entry and departure; in port.

I do not know the provenance of these items. I think that the following general ideas seem right:

traffic; sea areas which attract regulation or restrictions (17 & 18); aids to navigation; ship reporting; natural conditions but I wonder if this ought to be "adverse natural conditons; pilotage.

I have the following specific comments:

ID=2 (traffic)

I would be very cautious about including any comment, advice or information about COLREGS. Best left well alone. If we want something generic about where vessels are constrained as to their route because of TSSs, VTSs, recommended routes, two-way routes and similar, "Routeing" may be a better enumeration name.

If this is the intent of this enumeration, it would probably be best to remove the section "navigation and collision avoidance, for example, overtaking and head-on situations, navigaion in fairways or channels, COLREGS" and stick to something like:

routeing:

Regulation/restriction/recommendation/nautical information pertaining to Vessel Traffic Systems, Traffic Separation Schemes and recommended routes.

ID=17 (restrictions) & 18 (danger zones and restricted area regulations).

These look and feel similar. Could they be combined or the distiction made clearer?

ID=16 (miscellaneous safety). This looks nebulous. Best left out unless we can tighten it up.

ID=9 (other reporting). We have suppressed any attribute that includes "other". The advice has been that it is too hard for encoders. If we have particular reporting requirements other than "ship reporting", I recommend coming straight out with them.

ID=12 (signalling and ship-to-ship communications). There are traffic signals associated with locks opening and bridges lifting. Is this what is meant? Also authorities sometimes mandate that vessels should show specific flag signals to indicate status or requests. This might also be in mind. What sort of ship-to-ship communications is envisaged?

ID=5 (environmental protection). I wonder if we can broaden this a bit to become a "green ware" item? So we would have: "wildlife and environmental protection". I also wonder if "habitat" might find a place somewhere in the definition.

ID=10 (hazards and obstructions). These do not really fit together. "Obstructions" are charted objects on the sea floor. They are dangers in the same way that rocks and shoals are dangers. I do not think we need to talk about them, but if we did they should be separate from hazards. See also CATSHA which indicates types of hazards. So, I think that this should just be "hazards".

ID=6 (security and customs). These are rather different and almost certainly stem from different Government Departments or Ministries. A third area of control is immigration. So we are likely to have regulation in 3 semantic groups from 3 Ministries: customs (Finance or possibly Trade); immigration (Home Office or Internal Affairs); and security (Police, Coast Guard, Defence or Homeland Security); bio-security (Agriculture) is a potential fourth. Nations all have their own particular divisions of responsibility so we will find it hard to get a perfect model with 80 IHO Members and 190 odd nations represented at the UN.

ID=14 (cargo operations). We do not normally get into this. Our remit is really "navigation" and safety of life at sea. However if there is a clear need because Restrictions or Recommendations are included in an HO's books, let's keep this item. If we do keep it, I suggest suppressing "commercial" in the definition because cargo operations regulation probably also applies to military and NGO operations, both of which may fall outside strictly commercial operations.

ID=19 (port facilities) and ID = 4 (port services). These are a bit hard to tell apart. We already have a "Port service" in CATMSV. In that definition, we were thinking of a kind of radio service, which provides control of shipping, like air traffic control. We also have SRVTEC (fairly specific) and SRVREP (fairly generic) which talk about the sort of services that are available. We would need to keep any new attribute IDs aligned or clearly different.

ID=13 (small craft operations). This is a different idea and identifies who is being spoken to (or about) rather than what the subject of the reg/rest/rec/inf is. Although there are regulations for small craft, it is widely understood that these are generally observed in the breach. This is therefore one of the less convincing proposed enumerations.

raphael 18:18, 22 December 2009 (UTC): For CATRXN, I do not think it will be necessary to interpret subtle drafting and nuances in the content of regulations. Instead I hope we can use (with adaptations, if needed) the categorizations that already exist in the official regulations. I would like to discuss RXNCOD separately, because RXNCOD has a purpose different from CATRXN; RXNCOD is the attribute that tries to capture the "basic intent" (coarse cut view?) of the content. I agree that a link to the text of the regulation should be available.

US Coast Pilot volumes list Titles and Parts of the "Code of Federal Regulations" (CFR titles 15, 33, 40, 46 and 50). There are a total of 23 "Parts" listed in the "Navigation Regulations" chapter of the volume I am looking at, which I think is a reasonable number. We started with that list and tried to adjust them as necessary. I expect other regulations from other national and other jurisdictions have similar classifications and hope it will be possible to create a common list of categories.

The new RUBRIC text attribute is supposed to contain the official title of the part, section, subsection or other division of the regulation. It may need a little more work to capture the structure of government codes. The content of RUBRIC could be used to amplify the CATRXN value with the title of the part, section, subsection, clause, etc., from the specific national code.

We will carefully consider the comments on individual enumeration in the suggested list of allowed values.