Difference between revisions of "Talk:PLTSRV"
| Line 63: | Line 63: | ||
[[User:Rmm|raphael]] 03:28, 30 April 2009 (CEST) | [[User:Rmm|raphael]] 03:28, 30 April 2009 (CEST) | ||
| − | I was trying to avoid overlapping | + | I was trying to avoid features sharing the same geometry (or even overlapping a little) because I thought it more difficult to understand. It will complicate application processing and portrayal. |
Applications might require logic that loops through all the [[pltsrv]] features at a point. Portrayal code for ECDIS/ECS would have to be prepared to do something reasonable and user-friendly with two [[pltsrv]] features and objects associated with each. For example, if a system pops up an alert when an area is approached, the user probably wants to see one alert not two. | Applications might require logic that loops through all the [[pltsrv]] features at a point. Portrayal code for ECDIS/ECS would have to be prepared to do something reasonable and user-friendly with two [[pltsrv]] features and objects associated with each. For example, if a system pops up an alert when an area is approached, the user probably wants to see one alert not two. | ||
| Line 69: | Line 69: | ||
Also, I think encoders will be asked to attach common information objects, e.g., [[reglts]], to both features. | Also, I think encoders will be asked to attach common information objects, e.g., [[reglts]], to both features. | ||
| − | ENCs and the model can handle overlapping areas, but I think a simpler solution would be better. If there are only a small number of cases where overlapping is necessary with the current model, it might be better to adjust the model so that overlaps are not necessary, and thereby simplify the work of encoders, maintainers, and application designers. Changing feature/attribute bindings might suffice, I am thinking about solutions. | + | ENCs and the model can handle overlapping areas or shared geometry, but I think a simpler solution would be better. If there are only a small number of cases where overlapping is necessary with the current model, it might be better to adjust the model so that overlaps are not necessary, and thereby simplify the work of encoders, maintainers, and application designers. Changing feature/attribute bindings might suffice, I am thinking about solutions. |
Revision as of 03:31, 30 April 2009
Drafted by Northern before SNPWG 6
14.07.2006 Jens deleted superfluous attributes; inserted ass. Inf. Obj.
17.08.2006 DA Do not see the need for us to produce pltrqs
8.Nov.2006 Northern Notice: See our comments given for authority srvhrs: We agree putting all the information into srvhrs
11 Dec 06 DA Added definitions. Pltrqs and catpsv deleted. We see duplication between pltsrv and mrnsrv. Perhaps we need to remove Pilotage from mrnsrv and catmsv? Do not see how rgdata works in this object. Remarks added.
29.01.2007 Jens seen on different places where the pilot requires other data than the e.g. VTS ((Belfast /UKHO NtM 5/07))
SNPWG 7 Added guide to inf obj
SNPWG 7 agreed
19.02.07 Jens added catrgd
14 May 07 DA Replaced guides by rcmdts; reglts; resdes;
SNPWG8 Needs work
05.11.2007 Jens added shprep;and deleted catrgd which is covered by shprep and rgdata which is covered nowhere
11.01. Jens M3 reference
11 Feb 08 DA pltrqs reinstated and added instead of catrep8
12 Feb08 WEG All OK except restvc in shprep
11 Aug 08 DA I think we need the condet on pltsrv in the same way that we have condet on mrnsrv. Added.
jens 13:59, 28 April 2009 (CEST)
I think we should consider chalim for the ProdSpec as well. It will not work in all circumstances and I see the problems software manufactures might have when trying to write the code, but for simple structured pilot regulations it is a little thought worth.
raphael 06:05, 29 April 2009 (CEST) : Yes, or maybe attach some chalim attributes to pltsrv or PILBOP. I will try a few hypothetical cases and see how it works in conjunction with the other attributes especially pltmov and dstntn.
Submitted to Hydro register manager Date
Submitted to Nav register manager Date
Multiple pilot service providers
--raphael 06:54, 29 April 2009 (CEST)
I am trying to model a situtation where there are two agencies providing pilot services for New York Harbor and approaches. The text seems to imply two overlapping (possibly identical) service areas in this region. Does anybody know of similar situations elsewehere?
In such a situation, in general, the way each pilot agency operates, the kinds of vessels they serve, and certain other details can theoretically be slightly different for the different pilot agencies. I wound up using different pltsrv objects which does not seem entirely satisfactory.
(Updated: I'll see if things work out satisfactorily using chalim, but it may not work.)
jens 14:41, 29 April 2009 (CEST)
I have ordered our ENC guys to produce a simple ENC containing only two objects. Both share exactly the same geometry. The pick report on the screen shot shows the two objects. Problems occur in displaying the two objects separately at the ENC. It seems the fist objects is on top of the second.
However, the same procedure can be used for different pilot service sharing the same geometry.
File:Two objects sharing the same geometry.doc caution 1.34 MB
raphael 03:28, 30 April 2009 (CEST)
I was trying to avoid features sharing the same geometry (or even overlapping a little) because I thought it more difficult to understand. It will complicate application processing and portrayal.
Applications might require logic that loops through all the pltsrv features at a point. Portrayal code for ECDIS/ECS would have to be prepared to do something reasonable and user-friendly with two pltsrv features and objects associated with each. For example, if a system pops up an alert when an area is approached, the user probably wants to see one alert not two.
Also, I think encoders will be asked to attach common information objects, e.g., reglts, to both features.
ENCs and the model can handle overlapping areas or shared geometry, but I think a simpler solution would be better. If there are only a small number of cases where overlapping is necessary with the current model, it might be better to adjust the model so that overlaps are not necessary, and thereby simplify the work of encoders, maintainers, and application designers. Changing feature/attribute bindings might suffice, I am thinking about solutions.