Talk:WETFCA

Jens 14.01. improved definition and obj name to fit warnings as well (ALRS (3/1) page 22ff added NATION to carry the relationship between catfca (3) and the responsible nation

DA 11 Feb 08 and WEG 13 Feb 08 Agreed

jens 19:40, 1 October 2008 (CEST)

do you think we will have forecast areas valid only for a specified period of time? I couldn't see why to carry restrictions

If you agree pls remove (((PEREND; PERSTA; RESTRN;))) from the article

DavidAcland 19:26, 24 November 2008 (CET)

I do not see a need for RESTRN.

However I can see PEREND and PERSTA being used for ICE forcasts and warnings. I think it is also possible that some forecasts are provided during the main leisure seasons in inshore waters for yachties. So I have tidied up with this.

jens 10:20, 26 November 2008 (CET)

The working majority of the group agreed therefore RESTRN deleted.

I still have problems with PERSTA/END. I see your point but that is probably a wrong thought. The forecast itself can broadcast within a specified period of time. I wonder that the area designator should also have a limited lifetime. I am thinking, the area name specified by a category of area he was given for is valid all over the year. The mariner may expect a kind of weather report in a specified time period. I know from discussions with the Canadians that it is extremely difficult to change forecast areas because they are "burned" in the users' mind.

What do you think?

DavidAcland 17:20, 28 November 2008 (CET)

I see your point. The areas does not change so there is no need for PEREND and PERSTA, even if the service stops within it.

Looking through the discussions I think that we have lost catmsi. I changed it to CATMAB in the summer but did not appear to link it to any Object. catmsi used to belongs on RDOSTA so I have put CATMAB there as in the GEO Objects file at the bottom of the page.

raphael 00:23, 5 April 2014 (UTC): Without attributes describing the broadcast types, schedules, etc. (like RadioServiceArea (RDOSVC) the only useful information this feature carries is area type and name. Suggest binding attributes describing the service (like RadioServiceArea attributes) or making an association to RadioServiceArea. (Perhaps also with RadioStation.)

jens 18:47, 9 April 2014 (UTC) Well, the initial idea was to provide exactly the area and the respective area name and nothing more. I appreciate your idea very much. A binding to a particular service makes sense.
My first thought is saying that we should bind it with RDOSVC. But how should we manage it if we have two RDOSVC areas which provide information for the same WETFCA? If that would cause no problems I would be happy with that solution.

raphael 07:31, 10 April 2014 (UTC): We can leave it as is and depend on the spatial query to find the radio service(s).

jens 14:01, 12 April 2014 (UTC) Sounds good. Let's do so.