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 think we have to ensure 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.