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.
raphael 03:46, 29 December 2009 (UTC): 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.).
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?
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.
ID=16 (miscellaneous safety) and ID=9 (other reporting): No objection to leaving them out if they can't be precisely defined.
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.)
ID=5 (environmental protection): Agreed. How about:
Wildlife and Environmental Protection
Regulation/restriction/recommendation pertaining to nature reserves, protected species, wildlife and habitat protection, environmental protection and pollution
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.
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.
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.
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).
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 intent 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 can not 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 exiting to see in which direction the discussion will develop.
ID = 6 this kind of paper work is IMHO a added value, not to be provided by HOs, I remember having had 30 for Wilhelmshaven (couple of years ago and I afraid the quantity is 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