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.
raphael 14:37, 25 February 2014 (UTC): Agreed, no need to list it on the Wiki. I have included it in the application schema. Also BUISGL and Landmark, which are also used for encoding the location of a radio station in S-101.
example of page for closed dictionary codelist
Attribute: producer code for IHO member state
Acronym: PRCDMS
Camel case: producerCodeIHOMemberState
Attribute type: S100_Codelist
Data type: (product specification determines)
Definitions:
IHO member state producer code
Tagged values:
| Tag name | Value |
|---|---|
| codelistType | closed dictionary |
| URI | http://iho.registry.site/AgencyCodes/MemberStates |
| encoding | n/a |
Expected Input:
(not applicable)
Definitions
(none)
Reference:
(Permanent location of dictionary) http://iho.registry.site/s100_gi_registry/AgencyCodeRegisters/acr_home.php?register_type=4
Remarks:
This is just an example, the URI is made up, and so is the Reference location. The IHO registry actually has a list but it is an interactive Web page and not an actual list because there isn't as of now a URL where this dictionary can be directly accessed. A real codelist dictionary would have a permanent URL where software could retrieve or access the list, and the list itself would be in some kind of XML format so software could parse it.
The URI tag in the table above identifies the codelist, it could (ideally) be the same as the permanent location.
Dictionaries need to be key-value pairs, in this list the key would be the 2-letter producer code, the value the name of the producer state.
example of page for open dictionary
Attribute: producer code for IHO member state
Acronym: PRCDMS
Camel case: producerCodeIHOMemberState
Attribute type: S100_Codelist
Data type: (product specification determines)
Definitions:
IHO member state producer code
Tagged values:
| Tag name | Value |
|---|---|
| codelistType | open dictionary |
| URI | http://iho.registry.site/AgencyCodes/MemberStates |
| encoding | other: [something] |
Expected Input:
(not applicable)
Definitions
(none)
Constraint:
values not in the dictionary must be of the form "other: XX" where XX is a combination of 2 letters different from any of the entries in the dictionary.
Reference:
(Permanent location of dictionary) http://iho.registry.site/s100_gi_registry/AgencyCodeRegisters/acr_home.php?register_type=4
Remarks:
Like closed dictionary but allows additional values of the form "other: ..."
Misc
briana 17:33, 26 August 2016 (UTC) the S57 Caris link on the menu bar (referred to on the SNPWG page as "A source providing S57 the Feature Object Catalogue is listed at the menu bar for your convenience.") is broken!
--jens (talk) 14:34, 6 September 2016 (CEST) repaired
briana 14:08, 12 December 2017 - two questions on the "deleted" items: 1) how/why were they selected in the first place? 2) how/why were they selected to be deleted? many appear to be of the Natural Conditions S-126 realm and I would like to understand why they were left out.
jens (talk) 08:14, 10 January 2018 (CET) The initial creation based on the scope discussion we had. Later (and based on some kind of use case discussions) we decided that the deleted items have been either replaced by other data model developments or it was simply said that they were no longer needed. The rational of the deleted item section is that we can reanimate and transfer them to the appropriate section if their use has been justified.
raphael (talk) 05:20, 13 November 2018 (CET): The abstract feature classes defined for S-127 should be added.
OrganisationContactArea:
- Definition: A feature often associated with contact information for an organization that exercises a management role or offers a service in the location.
- Remark: It is not a requirement that every instance of the feature be associated with a management, reporting, or service organization.
SupervisedArea:
- Definition: A location which may be supervised by a responsible or controlling authority.
- Remark:
- It is not a requirement that every feature instance be associated with an authority.
- Note that having ReportableServiceArea as well as SupervisedArea allows the subclasses to link to ContactDetails both directly and via Authority, which may not be desirable because it gives encoders two ways to reach almost the same result.
ReportableServiceArea
- Definition: A service area that generally has requirements for submission of information, including communications not strictly considered “reporting.”
- Remark:
- It is not a requirement for every instance to require a report.
- The service can stretch from providing information and guidelines on reporting formalities and when, what and how to report in a specific port to a full exchange of information in a Single Window ship reporting system.