Talk:LIMTYP

raphael 22:15, 7 August 2009 (UTC) :

A new attribute Limitation Type is proposed. This attribute is intended to expand the expressiveness of CHALIM by allowing a more precise machine-readable specification of what is meant when a CHALIM is associated with some other object, for example 'negative limitations'. For example, to encode a limitation that applies only to vessels of draught greater than 12m, use LIMTYP=10 (included), MAXDRF=12; to encode a limitation that does not apply to vessels of draft greater than 12m, use LIMTYP=11 (excepted), MAXDRF=12. To encode a limitation that applies only at night, use LIMTYP=14 (new code meaning "applicable at night").

Concerning the enumeration: The first 4 (prohibited, required, permitted, recommended) are intended for use when CHALIM is attached to a facility to capture the fact that it is intended for use by vessels meeting certain limitations. The other two (included, excepted) are intended for use with regulations, etc.

jens 16:49, 14 September 2009 (UTC)

Make sence so far. Do we need to think about a better name widen up the meaning of those adjectives?

raphael 20:30, 14 September 2009 (UTC): Suggestions welcome, also descriptions of problems that arise using the current definitions.

jens 13:04, 24 October 2009 (UTC)

See, for example prohibited: to model anchorage prohibited for all vessels one can model now

• RESARE/RESTRN(1) or
• ACHARE/RESTRN(1) or
• ACHARE/CHALIM/LIMTYP(1).

The second construction is against the ProdSpec (A.51 9.2.3) of S57.

However, it shows that ""prohibited" in combination with something" is more or less occupied by RESTRN.

"Recommended" is being used by STATUS. STATUS is being used in many many other features.

Perhaps we can use "condition" or "stipulation" as attribute name. It would allow a wide use of that attribute as well. That looks fine to my German English, native speakers might see that different. Come on guys, it is your language.

raphael 17:43, 27 April 2010 (UTC): I don't think either "condition" or "stipulation" mean quite the same thing.

This attribute is needed to make it possible to express the applicabilty of and exemptions from regulations, etc. Sometimes regulations, etc., may remove or relax a limitation, perhaps for certain classes of vessels. For example:

CHALIM(LIMTYP = 11) means that the class of vessels described by the other attributes of CHALIM (length, draft, etc.) is exempted.

RESTRN does not work the same way. If we tried to use STATUS we would have to make rules about which of its allowed values could be used, and also define new allowed values.

jens 04:55, 28 April 2010 (UTC) ok. I have got still problems with some LIMTYP value (prohibited) which can cause duplicate entries in chart and NIO (nautical information overlay); see my post 24 October 2009.
On the other hand I can acquire a taste for using LIMTYP for certain conditions. If we not come to a solution here we can bring that to discussion for the next meeting.

DavidAcland 13:18, 11 August 2010 (UTC)

I can see an axis of control with Prohibited at one end and Required at the other. It goes:

Prohibited, advised against, deprecated, uncontrolled, permitted, recommended, required.

The current final two 5 (included) and 6 (excluded) seem to stand apart as drafted. They are different in two ways:

1. They only apply to associated information objects

2. They are not really limitations and the grammer to make them work is different. We would need to constrain 5 and 6 in different ways to 1 to 4 and I am not sure we would either want to do this or could do it.

It may be easier to split these two off and create a separate boolean attribute only containing 5 and 6, which we only place on the information objects we want.

raphael 20:19, 11 August 2010 (UTC): Yes, the final two are different from the others. This attribute gives the relationship between the subset of vessels described by an APPLIC (originally CHALIM) and a place, facility or regulation. Would it do if we changed the name of the attribute to something more general (e.g., RelationshipType, or CategoryOfRelationship)?

(We could use codes 10 and 11 for included/excepted to indicate that they are a little different from the others.)

I have a mild preference for retaining all the above allowed values in one attribute because it keeps the size of the overall model down, is easier to extend if the model needs another kind of relationship in the future, and is one less distinction for encoders to remember and the data capture guide to make. But all-in-all, this is a judgement call and if you think it is better as two attributes, all right.

(Digression: The best modeling solution would be to remove LIMTYP from APPLIC/CHALIM and use its allowed values to label the association between the APPLIC object and the info/geo object at the other end. This is ordinary UML, but I am not sure S-100 allows it. I'll make a UML diagram later today to illustrate this and find out if such would be allowed and welcome in the context of S-100.)

jens 05:49, 12 August 2010 (UTC)
May be I am too stupid to understand that. I try to make a simple example.
Pilotage is required for vessels of 50 m length and above.
We can say PLTSRV/APPLIC(vessels of 50 m length and above)/REGLTS(Pilotage is required; that can be shortened to required because the feature is talking about pilot service); that's all
or we can say PLTSRV/LIMTYP(required)/APPLIC(vessels of 50 m length and above); is that what you are intending to do with LIMTYP?
Saying yes raise one question. For what do we need the three brothers? We can extend LIMTYP with further values and let TXTDSC carry the information. Even NAUTINF can be integrated into LIMTYP with a bit brain-twisting work.

DavidAcland 16:16, 12 August 2010 (UTC)

I like the idea expressed by CategoryOfRelationship. However isn't this just another way of saying Type of association, which seems to me to like a named association?

I remember there was a discussion a couple of years ago about named associations between classes. I think that it settled on there only being one type of association in S-100, which was "Master Slave". I seem to remember that "named associations" are not allowed. However I was assured that our associations of information objects with geographic objects is allowed but that we could not associate an information object with another information object.

In your UML, enclosed with your email, it seems to me that LIMTYP (required - prohibitted) is behaving like a named association but if we can get the same effect using an attribute, OK.

I agree the value of keeping the model size down. I do not feel that creating a gap in the enumerations makes a sufficient differentiation. The enumeration values may be hidden from encoders. If they behave sufficiently similarly and we can make it clear that some values can be used with all features and some are only for use with information features, we can leave it as it is. Jens is all for making it simple for the encoders. I do not like apples and oranges in enumerations. So if we can formulate this so they are "the same kind of thing" it can stay as it is; otherwise lets split it out.

raphael 20:02, 12 August 2010 (UTC): Jens' question: I don't quite understand the second alternative, but if it means this (<---x---> indicates an association named x):
PLTSRV01 <----required-----> APPLIC(length 50m and more)
then the answer is yes (but we cannot do it if S-100 does not allow it).

We still need the 3-brothers because there are more complex regulations (restrictions, recommendations). Extending LIMTYP would get complicated and the end result would be a more fragile model because we could not be sure we had exhausted all possibilities.

David: Yes, that is what it does, achieves (almost) the same result using constructions known to be allowed by S-100. The conceptual result may be the same but the UML model and the encoding are different and conformant to the standard, which should work for implementors.

There is one difference: using a attribute means we cannot associate the same APPLIC object differently to different features; we cannot say:
REGLTS01 <--included---> APPLIC01(length > 50) <---exempted--> REGLTS02.

I think info/info associations are allowed - if not, it is a problem I did not notice when reviewing S-100, and I'll ask Eivind to suggest a change, they are important.

jens 04:42, 13 August 2010 (UTC) David and Raphael, Thanks for explaining it to me. I understand why LIMTYP is necessary now. I haven' t noticed that S100 does not allow my second option.