Difference between revisions of "Talk:Svcare"
Line 5: | Line 5: | ||
That is a typical master/slave relationship between geo objects. | That is a typical master/slave relationship between geo objects. | ||
− | + | first idea | |
− | STATUS and RESTRN look also wrong, especially the latter one, although I think the first one too. | + | 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. |
− | If | + | 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? |
Revision as of 17:32, 1 October 2008
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?