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 apologies for 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.

DavidAcland 16:05, 30 December 2009 (UTC). Will now look at RUBRIC.

raphael 03:46, 29 December 2009 (UTC):

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

The semantic groups (passage, including deep sea and coastal; approach, including port entry and departure; in port) suggest a temporal perspective to classification (i.e., according to the stage of the voyage). I think additional perspectives would also be useful for applications, such as a goals perspective such as (sailing to the next port of call; completing the paperwork needed at the destination; unloading and loading cargo; obeying the applicable navigation rules; etc.).

DavidAcland 16:05, 30 December 2009 (UTC). It is temporal, up to a point. But really it is more about how the regulation is going to apply. These have to be considered at the appraisal and passage planning stages, which are anything from a few days ahead to a few months ahead. I grouped them semantically so that we could spot the gaps and overlaps and to try to make sense of what looked like a fairly random list. The appraisal and passage planning is not necessarily done in date order; it is definitely iterative; and the deep sea bit is probably done first and last, with most concentration on the approaches and port entry bits. Cargo handling does not really fall into the Navigation domain but of course it is central to voyage planning and to whether to accept the cargo or not. This is the business of the ship manager and probably not the ship's crew, except in the case of the very small and now quite rare group of owner/operators.

ID=2 (traffic):
I think we need something for navigation and collision avoidance, either as part of this item or a new item. Would this item be better split in two? BSH sailing directions contain text about overtaking, passing, and right of way. If we decide to split it I suggest:

ID=2 (routeing): Regulation/restriction/recommendation/nautical information pertaining to Vessel Traffic Systems, Traffic Separation Schemes and recommended routes.

and ID=20(?) (navigation and collision avoidance): Regulation/restriction/recommendation/nautical information pertaining to passing, overtaking, and right-of-way.

(2) "COLREGS": this was intended to cover statements about whether COLREGS apply and where (e.g., Title 33 S. 80.1395 of the US CFR is: "The (19)72 COLREGS shall apply on all waters of Puget Sound and adjacent waters, including Lake Union, Lake Washington, Hood Canal, and all tributaries"). Would this kind of thing belong in either of the above?

DavidAcland 16:59, 30 December 2009 (UTC). ID=2 (routeing) looks OK. ID=20. I recommend great care. Touching anything to do with "right-of-way" is fraught with danger. I think we should be led by Jens on this in order to meet the BSH need. (2) "COLREGS": this is not "routeing". It is strange that this needs to be said, but I assume some numpty must have tried it on saying, "Oh, I did not think these Regs applied to me". COLREGS cover far more than navigation and collision avoidance and I understood that they had universal application. Where they do not apply (and these are the exceptions), it is normally necessary to make this clear and to advise Masters of vessels to remain clear, or to approach other vessels with caution. Normally done as a Note on the chart and in SDs. UKHO handles this sort of thing under a heading of Traffic regulation or Caution associated with a charted area such as what follows at IDs 17 & 18.

jens 12:09, 31 December 2009 (UTC) I would rather see that COLREG stuff in combination with regulations stated by IMO Ship's Routeing Guide. Taking a look to IMO shows that only TSS stuff is regulated by COLREGs. Means something might imply to the mariner that the normal COLREGs do not apply in particular areas. They might think, "Whow, I am sailing in a TSS lane and that gives me the right of way". We all know that is wrong and thus the normal statement is whether COLREGs 10 applies for a particular TSS or parts of it. Furthermore the statement is important for non-IMO adopted TSS. Sometimes national authorities declare that those TSSs are to navigate according to COLREGs 10.
I support David's argument on making a statement where COLREGs not apply.

IDs 17 and 18: "Danger zone", "restricted area", "regulated navigation area", and "limited access area" are covered in two different Parts of the US CFR (165 and 334). It may be possible to combine them for CATRXN purposes - we will investigate this with the test dataset or actual publications.

DavidAcland 11:32, 31 December 2009 (UTC). OK.

ID=16 (miscellaneous safety) and ID=9 (other reporting): No objection to leaving them out if they can't be precisely defined.

DavidAcland 16:59, 30 December 2009 (UTC). OK. Lets delete.

ID=12 (signalling and ship-to-ship communications): Both kinds of signals. "Ship-to-ship communications" is for general regulations governing ship-to-ship communications (who must have a radiotelephone, maintenance of listening watch, etc.)

DavidAcland 16:59, 30 December 2009 (UTC). Who must maintain listening watch is normally to do with ship-shore. Ship-to-ship communication, particularly in close-quarter situations, is deprecated. The expected conduct is to apply "The rule of the road" and that's it. If this is about whether you have an RT capability, that is really about equipment standard and not really about navigation.

ID=5 (environmental protection): Agreed. How about:

Wildlife and Environmental Protection
Regulation/restriction/recommendation nautical information pertaining to nature reserves, protected species, wildlife and habitat protection, environmental protection and pollution.

DavidAcland 16:59, 30 December 2009 (UTC). Agreed. Let's amend.

ID=10 (hazards and obstructions): I agree that these are separate concepts. I thought they might fit together from the perspective of the question of "what natural or manmade features does the mariner need to be particularly careful about when navigating near (and what are the relevant rules)"? No objection to splitting them and seeing if that works better.

DavidAcland 16:59, 30 December 2009 (UTC). OK. Lets split.

ID=6 (security and customs): Agreed about the differences. I approach this from the point of view of "what government paperwork do I need to provide (that is not directly connected to navigation)?". Retaining this as a single broad category would reduce problems with differences between countries as well as limiting the length of the CATRXN enumeration, but we can try it both ways and see which works better.

DavidAcland 16:59, 30 December 2009 (UTC). OK. I note Jens' 30 required reports. I can see that there is a need to help mariners with this but it is a big subject and something which I suggest is somewhere down the track. I suggest we park the form-filling.
At CATAUT we have "customs" but not "security". Instead we have "military", "police", "coast guard", "immigration", "maritime" and "port". "Security" could be delivered by any of these depending on the national implementation, and may be others. Perhaps we should add "security" to CATAUT
I do not think they fit together HERE and if we think of an airport, they really are diferent functions. Listening to the news story this week about the attack on the NW airliner over Detroit and its fallout, that is all about "security" and not about "customs". Similarly piracy, armed robbery and hijack - all security. I recommend splitting.

ID=14 (cargo operations): I agree with suppressing "commercial". There is text with information pertaining to cargo loaded/unloaded at specified wharves in HO publications (in more detail than CATCGO), this would apparently belong in NATINF; I will look for regulations, etc.

DavidAcland 17:14, 30 December 2009 (UTC). Agreed then.

ID=19 (port facilities) and ID = 4 (port services): "Facilities" is for physical facilities, "services" for tugs assistance, waste disposal and similar services. There are chunks of text concerning wharves which could be coded as NATINF(CATRXN=19, INFORM/TXTDSC="text"). Will work on better definitions.

ID=13 (small craft operations): I agree that it is different from the temporal perspective. But from another perspective, it allows applications to answer the questions like "what do I, as a small craft, need to know"? It might also allow an application for oil tankers to exclude information that applies only to small craft (or place it at the bottom of the list of regulations, or display it in a more compact form).

DavidAcland 17:14, 30 December 2009 (UTC). I can see what we are trying to do. So far we have been rigorous in avoiding apples and oranges in our selection of attributes. I am reluctant to lower the logical standard. I think the "small craft" flag should be in another perhaps boolean attribute. I wonder if there are other types of vessel which would turn this into a list? Which makes me think of CATVSL. Could we add "Leisure" to CATVSL and get what you need? I thought we had it there but for the moment cannot remember why it is not. With respect to Jens' comment below about a definition for "small craft", see UKHO SDs, Explanatory Notes, first article. "Admiralty Sailing Directions are intended for use by vessels of 150gt or more." The implication is that "small craft" are smaller that this limit. A few years ago we changed the text from "...vessels of 12m or more in length." to try and get round the problem of gin palace inflation. That has not really worked and we have been outflanked again vide Port Hercule. That is why I think the change in concept to "Leisure" works. We have the same people having fun (or not) in their bigger boats, and many are over 150gt - the boats that is.

jens 10:05, 29 December 2009 (UTC) I used reg as an abbreviation for reg/res/rec/nautinf
ID=2(Raphael's new proposal) in general: again, for what should be CATRXN used for? Having the feature (well HYDRO coded), associate reg, put the reg into the TXTDCS would provide the information on the place. The diversion through CHALIM works optional.
ID=2 (Raphael's new proposal) in particular: if we intend to keep that structure alive; looks fine

ID = (20?) in general: can be modeled using RUBRIC (You see I love the rubric idea)
ID = (20?) the division looks fine but refer to part four of German Shipping Law which offers more options

IDs 17 and 18 it seems to me we have the same situation like years before when trying to figure out what all the different "CATMSVs" of Marine Service mean. The outcome of former ~30 was 5 entries.

IDs 9 and 16 let go; no problem with leaving them out

ID= 12 visual signals are underrepresented in the model right now. But using
a) SISTAW/CATSIW offers the purpose of the signal for warnings
b) SISTAT/CATSIT offers the purpose of the signal for traffic.
Add either a PICREP of the signals shown and their interpretation or describe both verbally in reg. What to prefer is worth being discussed further.
I cannot remember regulations regulating Ship-Ship communication. Which channel to be used for ship-ship is common seamanship or company regulated. The most of the "keep this frequency clear" discussions disappeared with AIS carriage requirement.

ID = 5 in general: can be modeled by associating reg to the charted feature.
ID = 5 in particular: da steigt mein englisch aus.

ID = 10 although I think that can be also covered by associating reg I am interested to see in which direction the discussion will develop.

ID = 6 this kind of paper work is IMHO an added value, not to be provided by HOs, I remember having had 30 for Wilhelmshaven (couple of years ago and I afraid the quantity has not gone down)

ID = 14 if we run the way to the end that will make CATCGO superfluous.

ID = 19 and 4; see David's comments

ID = 13 the only problem I see is to define what a small craft is. Having found a definition if should be possible to use CHALIM to assign the relevant reg.

A short step to German Shipping Law

raphael 08:25, 30 December 2009 (UTC): (Just a short note for now, I will be taking a break the rest of this week.)
CATRXN only indicates to the application (in general terms) what the chunk of text in INFORM/TXTDSC is about. Applications could use it for functionality that needs more than location, especially if the reg is attached to a "general-purpose" geo object.

I don't quite see how CATCGO and similar attributes help...using additional attributes along with regs would result in a more complex model, complicate programming, and make more work for encoders, because they would do more analysis of the text to determine CATCGO values, not just decide that "this paragraph is about cargo".

---

jens 13:00, 31 December 2009 (UTC) reg is being used as an abbreviation for reg/res/rec/nautinf in my comments
Today is the last day of the year and time to start the discussion from scratch. We are too much engaged in details and the meta level for this problem is not clear right now. Quit often in the past, particularly during my ships planning and operation work it was necessary to clear the mind and start thinking again.

Generally I think we should decide the purpose of the NPUB information we provide:

• do we want to provide structured information to the mariner (as stated in the name ECDIS for what we are working for),
• do we want to provide a dataset which enables machine to assist the mariner with decisions to make according to the circumstances found and with no or limited responsibility for that decision,
• do we want to provide information apart from the origin HOs domain?

I'm not convinced that the latter 2 ideas have an IMO mandate.

The second question is whether and for what we should need CATRXN? I think it would be somehow necessary. My new thoughts are quit simple: If associate reg to an area like SEAARE which describes a feature not particularly we have no chance to distinguish the information we intent to provide in a convenient way. That means not to generate any decision assistance, we just provide the information better structured.

If we can agree on the CATRXN idea we can say: some items of the previous CATRXN are in such a close relation to particular features that they will be better placed there than on a "general" feature like SEAARE. My idea is to define only a few CATRXN which can be used if/where particular feature does not apply and my first ideas are:

1. navigation
2. environment protection
3. animal protection
4. cargo operation (I'm a bit in doubt about that, but thought it is worth being archived for discussion)
5. security
6. customs

The good is that RUBRIC enables us to provide a structured information (like a menu on top of the text). And RUBRIC can be used for all, the reg/RUBRIC stuff and the reg/CATRXN/RUBRIC combination.

Additionally, we give the private sector room to add value to the data HOs provide; e.g. particular services, facilities, operation information, agency related information.

What do you think on that new approach. Worth being followed?