Talk:Svcare

Agreed by SNPWG8

jens 19:02, 1 October 2008 (CEST)

That is a typical master/slave relationship between geo objects.

  first idea

Assuming my statement above is correct do we need CATROS and CATRA? Both are provided by the master objects. STATUS and RESTRN look also wrong, especially the latter one, although I think the first one too.

  second idea

If master/slave works we can also place the association to the contact details here and let the RDOSTA/RADSTA as they are. That supports Eivind's idea he told me in Brest. He wanted to keep the station which provides the technical equipment alone and separate the service area and the contacts. The contacts do not work necessarily at the location of the RADSTA/RDOSTA (e.g. being remote controlled); see also definition for RDOSTA/RADSTA, but works in any case at the svcare.

What do you think?

jens 15:43, 26 October 2008 (CET)

see also sta_discussion

DavidAcland 16:03, 27 October 2008 (CET)

I think you are right.

I have followed the links to here. RDOSTA does seem to accept that the object is used to obtain a line of bearing and the definiton does mention "point of transmission". It seems therefore with RDOSTA they do mean the antenna but with RADSTA they do not. So it is a bit confusing.

However I believe that the svcare is meant to provide a connection between the conceptual service (what the service is) and the area where it is available. If there is a remote antenna or radar scanner and the people providing the service are in a VTS centre 20 kms away, the master slave relationship is with the VTS even if the geometry of the svcare is partly defined by where the scanners or antennas are located. There are pobably also bureaucratic and jurisdictional limits. The RDOSTA which provides the communications for the service could be somewhere else again. So I am happy to leave the two ---STAs out of the model. I think that that makes mrnsrv and svcare the same thing so perhaps we could delete svcare?

Looking again at RDOSTA I am wondering if perhaps we should move our new attributes away to a new geographic object which might be RadioService - rdosvc? That would again follow Eivind's advice and let the RDOSTA just do the charty thing. The rdosvc would be the geographic area in which all those radio services in NavPubs could be obtained. I think it might be better to do it this way instead of loading up mrnsrv with all those attributes which are very particular to the form of radio transmission.

jens 14:58, 15 November 2008 (CET) ok. I will create a new object called RadioService-rdosvc added with the attributes added to RDOSTA before. It makes sence to delete srvare which is superfluous now. I also think that mrnsrv is bit different from rdosvc. mrnsrv has more to do with the kind/capabilities of service provided.