Difference between revisions of "Talk:TmIntervalsByDoW"

From IHO Nautical Information Processing Working Group
Jump to navigation Jump to search
m
 
Line 69: Line 69:
  
 
I have also tried to think of a lifting bridge or lock gate, which provides interupted service to navigation during the morning, lunch and evening land traffic rush hours.  At all other periods the land traffic can be stopped to allow vessels to pass.  This means that there is more, possibly continuous, service at weekends.
 
I have also tried to think of a lifting bridge or lock gate, which provides interupted service to navigation during the morning, lunch and evening land traffic rush hours.  At all other periods the land traffic can be stopped to allow vessels to pass.  This means that there is more, possibly continuous, service at weekends.
 +
 +
 +
[[User:Jens|jens]] 11:41, 16 August 2010 (UTC) Let me start with the last problem. It is not more than to suck off the information source. We will leave the path of fuzzing information by verbal description. A lot of work comes.
 +
<br> The first but is much harder and I must say, "Well argued". It is hard to reply (to be continued)

Revision as of 13:41, 16 August 2010

jens 06:27, 16 August 2010 (UTC)
It looks like it was a rainy weekend in Somerset. :)

I see my proposal of a big complex attribute somehow rejected. If the uncertain construction with DYWKRN is the reason I would like to ask Raphael if a construction is possible saying DYWKRN requires the input of two values saying the first value is the start and the last value is the end of a range.
That avoids a bit of code. What do you think?

DavidAcland 09:52, 16 August 2010 (UTC)

Yes; and a BBQ was planned. The cooks grilled under umbrellas. Sadly no photo.


Row Sub-attribute Camel Code Identifier Multiplicity Sequential
1 DYOFWK dayOfWeek 0..1 n/a
2 ?????? dayOfWeekRangeStart 0..1 n/a
3 ?????? dayOfWeekRangeEnd 0..1 n/a
4 TIMREF timeReference 1 *
5 TIMSTW timeOfStartOfWork 1..* True
6 TIMENW timeOfEndOfWork 1..* True













I have amended the multiplicity at rows 5 & 6 above to reflect the current design for WKHRDY and allow for multiple work periods in a day.

The risk seemed to me with rows 1,2 & 3. If they are all optional and will all carry days of the week as enumerations like DYOFWK, how could a production system do any validation checks? And it also seems odd to have three simple attributes with the same lists or am I missing something?

Our earlier construction just looked more rigorous and I think I can accept the added complexity to achieve that.

However I am unsure how we cover a work schedule which has 5 standard days but with two different work patterns for the 6th and 7th days; or indeed for a schedule where there are 4 standard days and different patterns on the 5th, 6th and 7th. And then again, we might have (starting on Monday): Day, Day, 1/2 Day, Day, Day, 1/2 day, very short day.

I suppose with either construction we have to have multiple WKSHEDs:

1) Range 1: First "Day, Day"

2) First "1/2 day"

3) Range 2: Second "Day, Day"

4) Second "1/2 Day"

5) "Very short day"

I have also tried to think of a lifting bridge or lock gate, which provides interupted service to navigation during the morning, lunch and evening land traffic rush hours. At all other periods the land traffic can be stopped to allow vessels to pass. This means that there is more, possibly continuous, service at weekends.


jens 11:41, 16 August 2010 (UTC) Let me start with the last problem. It is not more than to suck off the information source. We will leave the path of fuzzing information by verbal description. A lot of work comes.
The first but is much harder and I must say, "Well argued". It is hard to reply (to be continued)