Sta discussion - Revision history

Jens at 14:42, 26 October 2008

2008-10-26T14:42:10Z

Jens at 14:39, 26 October 2008

2008-10-26T14:39:19Z

Jens at 14:38, 26 October 2008

2008-10-26T14:38:43Z

Jens: New page: ~~~~ I am not 100% convinced but thought we discussed the problem at several places with several SNPWG team members and with several results, proposals or/and ideas. I learned from Eivin...

2008-10-26T14:33:37Z

New page: ~~~~ I am not 100% convinced but thought we discussed the problem at several places with several SNPWG team members and with several results, proposals or/and ideas. I learned from Eivin...

New page

[[User:Jens|jens]] 15:33, 26 October 2008 (CET)

I am not 100% convinced but thought we discussed the problem at several places with several SNPWG team members and with several results, proposals or/and ideas.

I learned from Eivind that it might be a better idea to keep both ...STA objects as they are. The ...STA objects are designated to carry information of the equipment not of the service. Let me explain what does it mean. A service (radio or radar) is using a station somewhere (ashore or in the water or in the sky) from where they transmit or broadcast their information to the mariners. Following this, the equipment needs to have a service area where the mariner gets the information from the service or where he can interact with the service; not with the equipment. I think Eivind is correct. The ...STA are only the relays station in the information chain (information provider <-->..STA<-->mariner/user).

It is to discuss whether we should separate the contact information from both ...STA and start thinking about additional objects again.

← Older revision		Revision as of 14:42, 26 October 2008
Line 8:		Line 8:

	It is to discuss whether we should separate the contact information from both ...STA and start thinking about additional attributes again.		It is to discuss whether we should separate the contact information from both ...STA and start thinking about additional attributes again.
		+
		+	See also my initial discussion at '''[[svcare]]'''

← Older revision		Revision as of 14:39, 26 October 2008
Line 7:		Line 7:
	It is it worth to check this proposal against '''[[RDOCAL]]''' (Radio calling in point). That is the same approach. The area/place where a message has to be sent to somebody is defined. Not the shore based equipment which realized the physical radio wave handling.		It is it worth to check this proposal against '''[[RDOCAL]]''' (Radio calling in point). That is the same approach. The area/place where a message has to be sent to somebody is defined. Not the shore based equipment which realized the physical radio wave handling.

−	It is to discuss whether we should separate the contact information from both ...STA and start thinking about additional ~~objects~~ again.	+	It is to discuss whether we should separate the contact information from both ...STA and start thinking about additional attributes again.

@@ Line 3: / Line 3: @@
 I am not 100% convinced but thought we discussed the problem at several places with several SNPWG team members and with several results, proposals or/and ideas.
 I learned from Eivind that it might be a better idea to keep both ...STA objects as they are. The ...STA objects are designated to carry information of the equipment not of the service. Let me explain what does it mean. A service (radio or radar) is using a station somewhere (ashore or in the water or in the sky) from where they transmit or broadcast their information to the mariners. Following this, the equipment needs to have a service area where the mariner gets the information from the service or where he can interact with the service; not with the equipment. I think Eivind is correct. The ...STA are only the relays station in the information chain (information provider <-->..STA<-->mariner/user).
 It is to discuss whether we should separate the contact information from both ...STA and start thinking about additional objects again.