Talk:RXNCOD

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

RXNCOD (Regulation/restriction/regulation code) is intended to provide numeric codes that identify the information as one of the most common types of regulations (or restrictions, etc.) RXNCOD values are precise enough for an application to display specific alerts. RXNCOD values may correspond to specific text ("e.g., pilotage compulsory"). Applications could use RXNCOD to display specific strings, or provide and handle specific alerts.

jens 08:36, 15 September 2009 (UTC)

Long time ago we discussed the idea of providing more detailed information of res/rec/reg but withdrawn our ideas. We saw that too much differences and dependencies are possible. If we start one we have to collect all (pilotage recommended, stand away from bridge before passage is allowed, do not cross etc.). That was our argument. And presumably we will not be able to collect all, or even we produce an endless list. Thus we decided not to further granulate the information. I see that the code can be used for recommending agreed headlines of res/rec/reg. That would look to me better than the proposed structure; at least at the moment.

raphael 07:25, 17 September 2009 (UTC): Example of headline, please? (I'm wondering whether using it that way might duplicate what CATRXN does.)

Also, my thought was that coding even just the most common 10-15 types might still suffice to cover many or most of actual regulations (rec/res), perhaps enough that applications could do useful things with them even if the RXNCOD list is not a 100% complete and perfect capture.

jens 09:07, 17 September 2009 (UTC)

My problem is that I know what will happen. The minority which is not covered by the values will be the discussion point.

In my previous post I thought on using the values as headlines if one needs to encode res/rec/reg. I know the headlines would rather be suggested than agreed headlines. The most of the res/rec/reg are to be used in conjunction with other features e.g. Quarantine and health . That can be modeled PRTARE/REGLTS and the headline can be quarantine. We should not try to split up each possibility of reg/res/rec. As you know, the Law is endless in variations word wide.
The next escalation can be to model each possible Rules of Thumbs; Key West was experience enough to me. At the moment I can not see that using RXNCOD as it is now is a convenient way.

raphael 02:18, 18 September 2009 (UTC): For the "headlines" idea, would the enumeration be the same as for CATRXN as currently defined or would it be some or all of the current RXNCOD values, or some combination of the two?

jens 05:46, 23 September 2009 (UTC)

Sorry for being late with my response. I was too busy the last days.
However, the headline idea can be a mix of CATRXN and RXNCOD values. I am not convinced that all of those are to be used. As mentioned before I am much in favour to assign the res/rec/reg to a specified feature.

For the problem of different kinds of res/rec/reg pertain to one feature I repeated your post at CATRXN because it seems this is in relationship to this discussion.

   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.

For that case we can use multiple feature objects sharing the same geometry or using different headlines. Both options are possible.
As I stated before the headlines can only be a recommendation for entries to be placed at TXTDSC.
Recently we discussed regs for anchorages in the Brest area (FR). They can be associated to anchorage places/areas. But the regs are divided in very many different headlines. Some of them are dealing with the anchorage itself others with the law behind that regs or the responsible body or the rules how, when, to whom, why, which vsl dimensions etc., means endless.
In that case we spotted that the idea of having an option to assign one reg/res/rec to several features is brilliant. We hope it will become part of S100.
However, the headlines should not be stringent. We should allow flexibility otherwise we will crash. And we can definitely not offer "others". Perhaps it is thinkable to say we offer some headlines options to be used in TXTDSC but the way to spot headlines in any case is to assign a specified tag to that headline. I know that depends on the result of TXTDSC discussion.
What do you think?

jens 05:49, 23 September 2009 (UTC)

Just thought to take the headlines off the TXTDSC. But than we are exactly there where we started. I only wrote this to avoid start thinking that again. :)

raphael 04:39, 24 September 2009 (UTC): Doed "headlines" mean the topic sub-headings in sailing directions? I was thinking of using CATRXN for topics/sub-topics. Would it be possible to get a few samples from SHOM? (French may do, I should be able to figure out enough to understand the problem even though I do not know French.)

For the anchorages question woudl it work to: (1) place the name of the law or issuing authority (if any) in REGLTS/OBJNAM,(2) use or extend CHALIM to describe who and which vessel dimensions, some kinds of "when" (at night?), and (3) keep "How", "when", "why" as text in REGLTS/TXTDSC?

jens 05:34, 25 September 2009 (UTC)

Yes, for the last entry I would suggest such approach.
For the first item I asked FR to provide such example.

raphael 07:53, 2 October 2009 (UTC): Perhaps adding a text attribute for the section title of the regulation (new attribute RTITLE or RUBRIC or ???) to REGLTS would help? (I hesitate to use OBJNAM for too many things.)

Additionally, the codelists for CATRXN and RXNCOD could be revised as needed.

raphael 18:50, 2 October 2009 (UTC): To clarify and adapt the first point I mentioned on October 2, I was thinking of multiple REGLTS objects for the FR example. We could split the regulations over them as appropriate and use the titles of Articles in the new title attribute.

If it is necessary to collect these REGLTS object into a specified sequence for some reason, an aggregation object may do, or a new complex information object can be defined.

jens 17:48, 5 October 2009 (UTC)

That sounds to me like a reasonable approach. The title attribute is not limited to any predefined lists. The attribute is also not limited to styles attached in the TXTDSC file. That keeps the TXTDSC discussion separated from this discussion. For certain reasons information composition might require an order of information. Thus I would prefer to see complexity.
In a first iteration the construction developed could be a feature with multiple information objects associated, each information object with one headline and some subtitles/subsection and content related to that subtitle/subsection.
In any case we should consider, that searching for attribute values is not possible in that case. OEMs should provide search capacity for the headlines or the content in the text files. On the other hand the construction allows OEMs to provide a menu tree without loading the whole content and let the mariner select the information needed. That sounds very nice to me now.

Feature
..some describing attributes

..Information object CHALIM if applicable

Information object 1
..OBJNAM 1 (that can be a headline to summarise the information underneath)
..RTITLE (1)1..* (subtitle/subsections of OBJNAM 1)
....TXTDSC (information)

Information object 2
..OBJNAM 2 (that can be a headline to summarise the information underneath)
..RTITLE (2)1..* (subtitle/subsections of the OBJNAM 2)
....TXTDSC (information)

and so forth.

Currently I have neither an idea how the aggregation can improve the idea in a way to provide an information order nor I know how a complex attribute is helpful. For the complex idea I don't know how to define the "sequential" entry for multiple instances of RTITLE. But having such sequential available would be much helpful.

Discussions lead to the question whether it is necessry to provide the RTITLE in any case. We think it will not be simple all the time to find a proper headline but we should have our audience in focus. The mariner will be happy having to read only headlines, select what aplies and studying only the relevant information. Conclusion: RTITLE as mandatory attribute defined in ProdSpec. What do you think?

jens 17:43, 6 October 2009 (UTC)

improved the post Oct. 5.

DavidAcland 13:53, 31 December 2009 (UTC). Again - apologies for my late entry to the discussion.

In this list at present we have have apples and oranges. We start with the format:

[activity][control]; i.e. [Pilotage][compulsory] ...
and then we morf into [activity][not quite sure - probably information].

So that makes me think, perhaps we should go complex, with the added benefit that it would act to restrain the endless list.

First element [activity]:
pilotage; entry; passage (if this is different to entry); anchorage; landing; overtaking; speed; tugs; cargo operations; obtaining clearance from customs, immigration and health authority (together or separate); ...

Second element [control]:
prohibited, restricted (conditionally prohibited (weather, time, vessel dimension)); mandatory; uncontrolled; ...

This approach would use the TXTDSC for the pure information which did not contain control and that would mean that we lose the RUBRIC or "heading" element, which I think is good. So could we have an initial heading element along these lines:
first element [heading (Jens's RUBRIC)]
second element [activity]
third element [control]
For example:
[heading] Northern Right Whale Critical Habitat
[activity] Entry
[control] Restricted
The detail, time of year, type of ship, speed restriction, noise restriction, special lookout, actions to avoid collision would all be in the TXTDSC and may also contain the verbatim national regulation. However this is tricky when it involves translation.

raphael 20:14, 4 January 2010 (UTC): This would be more work for the encoder than I had originally envisaged, but if it it is desired and it works for all the situations, the [activity][control] model should be fine. I think if the content is in TXTDSC, the attribute title (subject, heading, RUBRIC) would be useful to have.

jens 10:08, 5 January 2010 (UTC) ok; checked David's structure with both paper and ENC cartographers. Both confirm that the "entry prohibited" is placed as plain text in the area. The ENC contains a TXTDSC construction with that information. That cause no automatic alarm or indication in an ECDIS. At the moment ECDIS provides an information that an area with certain limitations is in a predefined (by ship's settings) distance.
It seems to me David's structure is very similar to others like geography/cause/effect. That looks fine to me.
Can we come to the conclusion that RUBRIC should be renamed to (subject, heading, topic, theme or ...)? That is an English question now.
Can we agree that LIMTYP will fit David's [control] idea above? Presumably amendments and extensions of definitions are necessary, but generally the idea is brilliant and supports David's construction.

DavidAcland 16:59, 21 January 2010 (UTC) I have taken the RUBRIC idea forward with a new attribute SUBJCT
DavidAcland 15:59, 22 January 2010 (UTC)
... and redrafting the idea of RXNCOD as a complex attribute. Placing the present RXNCOD into Deleted items as RXNCODOriginal.

jens 10:24, 22 February 2010 (UTC) At the moment a have got problems with the RXNCOD idea , as tempting good the idea is as difficult their use will be. Perhaps we should try to think a different way.
If we intent to keep this idea alive why not trying to use only SUBJCT and LIMTYP in combination with CHALIM. At the moment I don't see for what ACTION should be used for. The list is neither representative not complete. It looks more like a loose collection.
In any case I see difficulties to separate the use of RXNCOD and CATRXN.

DavidAcland 10:14, 9 February 2011 (UTC) Trying to progress this area. We have agreed that LIMTYP is replaced by CATREL so I will make that substitution, noting that CATREL also sits directly on APPLICABILITY in the MPA application schema. That may not be a problem.

jens 06:58, 11 February 2011 (UTC)
no problems with CATREL and APPLIC as they are now. RXNCOD makes more headache at the moment.
I see CATREL as a good one in relation that it describes how the information object "APPLICABILITY" controls the relationship between other objects depending on ship's characteristics. I can also see that CATREL can be used to express the level of insistence for or against a course of action. The latter explanation is rather in relation to RXNCOD than the first one. Seeing the proposed definition and intention of RXNCOD I am not sure that it is not a kind of duplication of what was made with APPLIC and CATREL. Seeing further the value 5 of ACTION and compare it with the example given for SUBJCT I have difficulties to identify differences.
What do you think to retire RXNCOD for a while and to reanimate it only if we see it is needed urgently to express content better or more structured. Or alternatively, retire one SUBJCT or ACTION. My preference would be SUBJCT. That keeps the data model more keyword search friendly.

DavidAcland 15:55, 11 February 2011 (UTC) OK To summarise: CATREL is now more or less agreed; we also now have MBRSHP. Jens proposes retiring RXNCOD and SUBJCT. The weakness of ACTION is that it is an endless list. CATREL says that something is "Mandatory" or "Verboten". ACTION expresses what that "something" is. This indicates to me that we have to work on ACTION to make it as complete as possible and have a way of dealing with things, which are not covered, without using "Others".

I think we still have at least three ideas to deal with on this subject: CATTXT, TXTDSC and LAWLAW. I assume that the entire regulation, extracts from it, or an abstract or summary will be in a TXTDSC. Do we still need to find a place for CATTXT to say which of these it is? I have not been able to find it, but I remember seeing LAWLAW somewhere recently. Is this somehow related?

I plan to continue working on ACTION on Monday unless I hear that is the wrong direction.

jens 19:07, 11 February 2011 (UTC) many thanks for keeping my mind running over the weekend. ;)

raphael 21:21, 11 February 2011 (UTC): I'm willing to pursue ACTION and see where it takes us.

jens 12:34, 13 February 2011 (UTC) I suggest to try the model on an example. Following extract of SDs

Compulsory reporting	
  vessels of 50 m length and above including pushed or towed composite units
    only if no report was give to German Bight Traffic Control see C 2.1.1
  vessels carrying dangerous or environmental polluting goods see also chapter A 3.1
    including unloaded tankers if not cleaned, gas-free or completely inerted after carrying petroleum/petroleum products with a flashpoint below
    35° C

can be modelled

Feature: MRNSRV/ CATMSV=1 (VTS)/ 
  Association: SHPREP/ CATREP=1 (Sailing Plan)/ IMOREP=1 (yes)
     Association:  APPLIC / VSLMSM [VSLCAR=1 (length); VSLVAL=50; VSLUNT=1 (m); COMPOP=2 (>=)] 
          Association: REGLTS / CATAUT=15 (maritime) / MBRSHP=1 (included)/ RXNCOD [ACTION=13 (reporting)]/CATTXT=(abstract)/ TXTDSC (if no report was give to German Bight Traffic Control)]  
     Association:  APPLIC / VSLMSM [VSLCAR=1 (length); VSLVAL=50; VSLUNT=1 (m); COMPOP=2 (>=)]/ LOGCON=1/ CATVSL (to be extended by pushed units+towed units)
          Association: REGLTS / CATAUT=15 (maritime) / MBRSHP=1 (included)/ RXNCOD [ACTION=13 (reporting)]/CATTXT=(abstract)/ TXTDSC (if no report was give to German Bight Traffic Control)]
     Association:  APPLIC / CATCGO=7 (dangerous)/ CATDHC=20 (miscellaneous)
          Association: REGLTS / CATAUT=15 (maritime)/ RXNCOD [ACTION=13 (reporting)]/CATTXT=(abstract)/ TXTDSC (what is stated at A 3.1)]
     Association:  APPLIC / CATCGO=7 (dangerous)/ CATDHC=1-20 (all)/ CATVSL=3 (tanker) Actually I have difficulties to specify the given cargo information completely 
          Association: REGLTS / CATAUT=15 (maritime)/ RXNCOD [ACTION=13 (reporting)]/CATTXT=(abstract)/ TXTDSC (what is stated at A 3.1)]

Although the example looks a bit strange I guess, we can employ RXNCOD as complex attribute containing ACTION (to be extended and hopefully completed), CATTXT (to describe the completeness of the information provided) and TXTDSC (to carry the relevant text file).
I don't see SUBJCT, LAWLAW to be used.
It is to consider if CATRXN should b placed elsewhere here. This attribute was developed and is still not used anywhere.

A further thought is about MBRSHP. It is to discuss whether it is possible to use it to include always each second vessel description to each first APPLIC. I am not sure but it looks very tempting.