Difference between revisions of "SNPWG2"
| Line 311: | Line 311: | ||
==Data Capture and Encoding Guide (DCEG)== | ==Data Capture and Encoding Guide (DCEG)== | ||
| − | + | ===General information=== | |
[[User:DavidAcland|DavidAcland]] 09:37, 24 November 2011 (UTC) | [[User:DavidAcland|DavidAcland]] 09:37, 24 November 2011 (UTC) | ||
| Line 381: | Line 381: | ||
3. At a later stage we should try to amend the FC XML to include the fields that Jens designs into | 3. At a later stage we should try to amend the FC XML to include the fields that Jens designs into | ||
the MS Word MPA DCEG. | the MS Word MPA DCEG. | ||
| + | |||
| + | ===MPA DCEG=== | ||
| + | |||
| + | The current status can be downloaded (Link)|here | ||
==more== | ==more== | ||
Revision as of 10:21, 22 December 2011
SNPWG has to develop a Product Specification to enable ECDIS manufacturers to build software able to display NPUB information on an ECDIS screen. Following sub-pages provide discussions on the UML model and the ProdSpec for several NPUB problems. The SNPWG Wiki administration is trying to provide the files in a convenient way; but we can not guarantee to fit all requirements.
Scope
xxxxx
Product Specifications
Generals
Initially we tried to adapt the S-100 ProdSpec as much as possible. That was good for the learning process.
However, we have had a discussion resulting that we have to develop a ProdSpec S-10x for NPUBS and it is likely that such a specification can differ from S-100. We also discussed two options of a NPUB ProdSpec
- a totally new NPUB ProdSpec starting from scratch
- a NPUB ProdSpec using S-57 and charted content as much as possible, adding only those features relevant for nautical information.
The result is to follow the latter option. That avoids some work for us because we do not have to develop the charted content again. How that works can also be seen at the UML models. Only features useful for SNPWG work are copied from S-57. All others remain untouched.
What is currently under discussion? Do we need to build several ProdSpec or can we combine all ProdSpec proposed below into one NPUB ProdSpec. We will see what the future brings?
Waterways
The waterway ProdSpec is being discussed between Olav and Jens. The files reflecting the discussions are stored here File:Product Specification Waterways.doc
Pilotage
xxxxx
Marine Protected Areas
A product specification is under development.
UML Models
We propose to display a jpg. file providing a preview of the UML model here or at the sub-pages and a link to the uml file for those who intent to work with UML.
Discussions are to be placed to the discussion page which has a similar structure like this page. The contacts provided are hosting the UML diagrams. It is strongly advised to contact them before trying to amend the attached UML files. The e-mail addresses are to be obtained from the IHO/SNPWG website if not known. We intent to avoid too much duplications of the work done.
And now enjoy studying diagrams.
Product Specification Scope
pls contact jens (BSH) if amendments to the diagram are desired
the UML file is stored and can be downloaded here File:ProdSpecScope.uml
Non Geospacial Scope
pls contact jens (BSH) if amendments to the diagram are desired
the UML file is stored and can be downloaded here File:NonGeospacialScope.uml
SNPWG Application Schema
pls contact jens (BSH) if amendments to the diagram are desired
the UML file is stored and can be downloaded here File:SNPWG Application Schema.uml
Waterways
The idea behind the diagram is simple now. A waterway area (for SNPWG interest) contains only non-chartable information. We associate rec/res/reg/natinf to that area. If the rec/res/reg apply for a specified type of vessel the association is using that deviation.
The reason why no SEAARE is involved now is that we intent to avoid having two features with the same name and different spatial. That might cause confusion.
the UML file is stored and can be downloaded here File:WaterwayPackage.uml
Recommended Tracks package
the UML file is stored and can be downloaded here File:Recommended tracks package.uml
Pilotage
The UML file for the pilotage model depicts attributes, enumerations, etc. in diagrams separate from the main diagram. Also, there are some omissions and shortcuts in this diagram, for example, ordinary UML enumerations are not quite the correct model for S100 enumeration value lists (doing that correctly in UML will take a lot more effort and complication and at this point of time I am not even sure StarUML can show it properly). The objects and attributes in this version are Jeppesen proposed updates (as of July 16) to those on the Wiki.
pls contact raphael or john (Jeppesen) if amendments to the diagram are desired
the UML file is stored and can be downloaded here File:PilotageMappingExample10.uml
Marine Protected areas
raphael 19:49, 7 October 2010 (UTC): MPA application schema in Enterprise architect format, for the SNPWG13 MPA product specification work can be downloaded here: File:MPA application schema.zip.
DavidAcland: 14:50, 29 November 2010 (UTC) A slightly later version of the MPA application schema is shown here as a JPEG:
jens 12:05, 4 March 2011 (UTC) The image below shows that latest development status
File:MPA Domain Objects.jpg
Regulations/Restrictions/Recommendations/Nautical Information
The MPA UML diagram (see above) reflects the current status of implementing the Quartet.
Data Capture and Encoding Guide (DCEG)
General information
DavidAcland 09:37, 24 November 2011 (UTC)
Notes of SNPWG Tele-conference 16 November 2011 on way ahead for MPA Data Capture and Encoding Guide
Taking part: David Acland, Jens Schroeder-Fuerstenberg, Raphael Malyankar
Apologies: Eivind Mong – Represented by Raphael
Agenda Item
1. General understanding of the output.
Identification of a DCEG as a required step. What one looks like and what it should contain. How it is produced is secondary.
2. Identify the presentation of the output: Are we aiming for a rough document like the feature catalogue that Tom made? Or a print quality document like the output of a word processor?
Much more the former.
3. What should be the presentation of this output, i.e. how does it look on the screen?
Layout is not important What is required at this stage is to know the content Jens will start by bringing the ideas together in Microsoft Word.
4. Need to agree the general structure of DCEG
In general for complex products there could be a need to organise subject matter by theme. This means that a DCEG would not just be an alphabetical presentation of features and how to use them. Instead the DCEG may be organised by high level subjects, which then lead the user to advice on what features and attributes to use to encode the information. For MPA with just one geographic feature this idea cannot be realistically expressed. Raphael said that to generate a good looking DCEG is not trivial and would take many weeks of effort.
5. Need to understand the architecture required to generate the DCEG
The long term aim is to develop DCEGs from the XML feature catalogue. That is when a new version of the FC is produced, the first cut DCEG is created from the revised FC. Only the new or changed parts of the new DCEG will need revision. However if generated automatically, manual amendment may not be easy. (I am not sure how this is done technically but can conceive that there are tools that could do it. It may need a database. Raphael mentioned Docbook4 or Docbook5, FIXML and DITA.)
Post meeting Note, 23 Nov 11, from Raphael:
“About item 5, the technical solution will probably take some combination of a database, use and perhaps adaptation of a standard XML vocabulary DocBook4/5, S1000D or DITA XML, commercial XML editing tools, and some code development (probably SQL or XSL transforms). We (probably especially me?) should put our heads together with Tom and find out more about the internal architecture of the IHO registry, especially its database and what it can and cannot do. Devising our architecture as an extension to that may be the best way to go.”
Way ahead.
1. We need to Review the FC put together by Tom Richardson and check it against our current understanding of the product. Remarks in it should be directly related to the feature and not stray into how it is used. 2. Jens will draft a DCEG based on the FC. Remarks in this document should cover how the feature or combination of features and attributes are used to encode information. Sources could include remarks on the Wiki feature or attribute page, the Wiki discussion pages or any of the recent BLAST studies. 3. At a later stage we should try to amend the FC XML to include the fields that Jens designs into the MS Word MPA DCEG.
MPA DCEG
The current status can be downloaded (Link)|here