Talk:SNPWG
raphael 09:34, 12 May 2009 (CEST) : I think it might be useful to have an introductory paragraph or two describing the scope of the SNPWG model, i.e., saying what the model is supposed to do and what is not expected of it. The Terms of Reference do not say much more than develop guidelines for preparing nautical publications in a digital format compatible with ECDIS. For example, is the aim to list all possible categories of attributes, or just those thought to be most commonly used? (The latter, I'd say.)
(Update: Also, how literally to interpret the definitions - I just placed an example in the discussion page for ntctim.)
jens 13:32, 12 May 2009 (CEST)
I have replied on the definition issue at ntctim.
Recently I have discussed the completeness of attributes available or only being used. At the moment we have worked out a compromise in our data model. We tried to collect all attributes needed for objects developed by SNPWG. Where attributes have been added for existing objects we collected all attributes provided by S57 too. Although some of those are not needed by SNPWG. The flexibility in S100 might cause the case that we have to mix attributes and attribute values more than today. That should be taken into account when developing the ProdSpec.
The introductory paragraph will be discussed with David. He speaks better English than I ever could.
jens 04:56, 20 August 2010 (UTC) I propose to introduce Time Zone and Day Light Saving Time.
Reasons are Eivind's suggestions and the double check of current existing ECDIS machines which are mostly not be able to handle that sufficiently. The most machines are calculating ETA in UTC and let the mariner do the time calculation. I think it is worth letting the machine do the work.
What do you think?, Worth being proceeded?
DavidAcland 15:12, 25 August 2010 (UTC)
Definitely. Exactly the sort of mind numbing detail for the machine to work out and provide.
raphael 10:44, 21 February 2014 (UTC): Suggest adding feature Coastguard Station (CGUSTA) as a temporary expedient, because it may be needed for Radio Services data. The S-101 DCEG uses it for encoding MRCCs. In the absence of any provision for cross-data-product linkage or references, it may be necessary to include it in radio services data sets. The only thematic attributes needed in Radio Service are featureName and information both of which are complex attributes and inherited from the generic FeatureType class in the application schema.
jens 08:52, 25 February 2014 (UTC) okay, Not all MRCCs belong to the CG though.
That is an existing S-57 feature and we don't have amendments to it. Thus, we can simply use it in our ProdSpec and we should not add it to the collection of features.