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 for 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 to not 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.