Talk:PLTSRV - Revision history

Rmm at 19:37, 1 September 2009

2009-09-01T19:37:05Z

New page

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.

[[User:Jens|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.

[[User:Rmm|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]].

[[User:Rmm|raphael]] 07:36, 30 April 2009 (CEST) :

If we associate a [[chalim]] object to [[reglts]] / [[rcmdts]] / [[resdes]] would that suffice? For example, compulsory pilotage for oil tankers would be represented by:

reglts(INFORM="Pilotage compulsory") and chalim(catvsl=3 (tanker)) (how to model "oil" with catcgo or catdhc as currently defined?)

[[chalim]] can't do complex requirements. This really needs an expression/rule language like

if (ship.Draught > 10 AND ship.CategoryOfCargo = "21") then (USE THIS PILBOP).

This obviously adds a major new concept to the model. Might this be acceptable for this edition of the standard, or would it be too complex and better postponed for a future edition?

[[User:Rmm|raphael]] 19:37, 1 September 2009 (UTC): Addition of attribute service access procedure [[SVAPRC]] is proposed, in order to distinguish procedures from other kinds of information.

Submitted to Hydro register manager Date

Submitted to Nav register manager Date

== Multiple pilot service providers ==
--[[User:Rmm|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.)

[[User:Jens|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.

[[Image:Two_objects_sharing_the_same_geometry.doc]] caution 1.34 MB

[[User:Rmm|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.

Rmm at 05:36, 30 April 2009

2009-04-30T05:36:29Z

Rmm: /* Multiple pilot service providers */

2009-04-30T01:31:32Z