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.