Talk:RDOSVC

jens 15:11, 15 November 2008 (CET) Please can you check the work done?

DavidAcland 17:05, 24 November 2008 (CET)

In trying to follow the pattern of pltsrv and mrnsrv, I notice that we have not called either of these ... Area. We have just defined the service. I quite like the form "... place where a ... service can be obtained" and perhaps there is a case to reflect this back into pltsrv and mrnsrv.

DavidAcland 10:59, 2 December 2008 (CET)

Having thought a bit more about this, I now find my earlier thoughts were wrong. This Object does define the area and so I have made this clear in the Alternative definition. If you are happy with this please can you put this definition in place of the original.

I think that frqprs is also now finished

DavidAcland 22:41, 5 February 2009 (CET) Many attributes changed to remove Attribute type:A which is denigrated in S-100. Many changed to complex; some simplified to integer; frqprs changed to frqpar. Multiple pairs can be created by repeating FRQPAR. facssp changed to FAXSSP which is more intuitive.

jens 21:49, 12 February 2009 (CET)

most agreed.

faxssp DRMSPD, indcop; see discussion there

FRQTXM and FRQRXV were difficult to understand due to 00.0 resolution but I got it why they become integer; clever solved :-) .

obstim and timtrm is to be discussed again because ISO construction used for TIMSTA, TIMEND can be used instead

DavidAcland 15:42, 13 February 2009 (CET)

Thanks for these points. Now all covered.

jens 09:28, 4 May 2011 (UTC) We need to have a language information attribute. NAVTEX e.g. can be transmitted in English or national language. Shall I add LNGINF to the attributes? I will add it as a place holder now.

jens 11:29, 4 May 2011 (UTC) Additionally, we need attributes for transmission power and for a particular time frame like between 0600-1800 whatever time. Is it a good idea to engage WKHRDY for the latter issue?

raphael 19:23, 4 May 2011 (UTC): Language - must it be free-form (LNGINF) or can it be one of the ISO list (ie., use LANGGE instead)?

Times: WKHRDY should be all right unless there are differences between different times.

DavidAcland 10:42, 13 May 2011 (UTC)

We would need to differentiate when to use this approach instead of TIMTRM.

Looking again at TIMREF, I see we have 1= UTM, 2=LT. I wonder if this is sufficient. It begs the question "What is the local time zone?".

I think we should add a third attribute CATTZN which we have started developing for the TIMZON feature. We could then express the transmission time 0600-1800 in UTM, Local time or in a specified zone time.

jens 17:04, 13 May 2011 (UTC) TIMTRM is not necessarily identical with WKHRDY.
I support the idea of introducing TIMZON too.
I will continue modelling the radio station information next week. In thought having considered all when introduced the radio stuff in Brest years ago. Today I afraid that I have some open issues to solve before being able to say "It is good".

jens 07:18, 17 June 2011 (UTC) Dome some more investigations. Retired "Class of emission" which is not longer needed aboard.
It is very tempting to introduce TIMREF rather then TIMZON. As far as I know all information are been given in a specific time reference of the transmitting station. So, if we have an area in a timezone different of the station's timezone the transmission times will be provided according to the station time. We do have a association between the radio service area and the radio station. So one can compute the differences between both if needed. What we need is to say whether the transmission or the working hours are at UTC or LT.

jens 18:59, 8 June 2012 (UTC) We do have an outstanding issue with the duplication of attributes TRIDCA of RDOSVC and NTIDCH of NAVTEX - both are transmitter identification characters, does the model need both attributes? Thanks to Raphael for having detected the issue. We have to discuss whether we should keep them seperately or incorporate them into a big feature RDOSVC??

raphael 23:33, 10 June 2012 (UTC): I think the two attributes for transmitter identification characters should definitely be combined.
RDOSVC has many more attributes and associations than NAVTEX. Unless the two can be made more alike, keeping them different seems simpler, otherwise the DCEG may need guidelines saying such-and-such attributes and associations are used only if it is not a NAVTEX station.

raphael 01:33, 15 January 2014 (UTC): The matter of two different attributes for transmitter identification characters TRIDCA and NTIDCH appears to be pending still?

jens 13:04, 29 January 2014 (UTC) I would go with the TRIDCA attribute. I think we can retire NTIDCH. Do you agree?

raphael 15:34, 29 January 2014 (UTC): Agreed.

jens 06:05, 18 August 2014 (UTC) WKHRDY is part of SRVHRS. Should we keep both or would WKHRDY become superfluous?

raphael 19:23, 18 August 2014 (UTC): Keep it, because it is simpler. Use the full SRVHRS.WKSHED.WKHRDY approach only when we need the full expressiveness of SRVHRS and WKSHED, like when we want to model a schedule that varies by day of the week. For radio service areas I believe that would be rare.

raphael (talk) 07:47, 23 May 2018 (CEST): TIMREF can be removed from the attributes since NPUB will now definitively use the Z suffix to mean UTC and no suffix to mean local time.
See also the discussion on Talk:TIMOBS about retiring TIMOBS

jens (talk) 15:53, 30 May 2018 (CEST) OBSTIM added to the list of simple atributes, TIMOBS removed from list of complex attributes