Incorrect drawing of some Area patterns

[alvarosanuy]

Dedicated Github issue to discuss topic presented by dKart (@IngaFjellanger) in the paper below (bullet point 11):

Comments to Portrayal Catalogue_last version.docx

Extract from paper:

11. The NODATA03 is incorrectly drawn. In order to draw a symbol staggered order, the value of the second vector must be equal to a half of the value of the first vector , i.e. 3.51 instead of 6.02

[alvarosanuy]

Initial comment provided by Hugh on 27/7/22:

I traced through the conversion of each and found the following.

NODATA03 – Reported Problem: pattern is not drawing staggered as expected. Assessment: can’t find any problem. I think the programmers have misinterpreted how the pattern fill is supposed to work. S-100 part 9 probably should have more details and examples about this. I have some notes I can add to the github issue.

[IngaFjellanger]

FixedAreaPatterns_comment#11.zip Here is more samples and xml files to avoid the problem. Note that xml files have wrong header

[TDYCARHugh]

The Pattern fill in S-100 works by placing rows and columns of point symbols. When you think of the point symbols as a rectangle the vector pattern placement looks like this:

The conversion from DAI into S-101 separated the DAI pattern instructions into a point symbol and an S-100 symbolFIll instruction.

The DAI used was from S-52 4.0.0.

The first step of the conversion parsed the DAI format into an XML structure like this: Pattern converted into XML `

PT01414

<PATTERNDEF>
  <NAME>NODATA03</NAME>
  <TYPE>Vector</TYPE>
  <PATTERN>Staggered</PATTERN>
  <SPACING>Constant</SPACING>
  <MINDISTANCE>00100</MINDISTANCE>
  <MAXDISTANCE>10000</MAXDISTANCE>
  <PIVOTPOINT>
    <X>02942</X>
    <Y>01040</Y>
  </PIVOTPOINT>
  <BOUNDBOX>
    <WIDTH>00602</WIDTH>
    <HEIGHT>00396</HEIGHT>
    <ULX>02342</ULX>
    <ULY>00645</ULY>
  </BOUNDBOX>
</PATTERNDEF>
<EXPOSITION>area of no chart data</EXPOSITION>
<COLORS>
  <COLORREF>
    <INDEX>A</INDEX>
    <TOKEN>CHGRD</TOKEN>
  </COLORREF>
</COLORS>
<VECTORS>
  <PENCOLOR>A</PENCOLOR>
  <PENWIDTH>2</PENWIDTH>
  <MOVETO>
    <X>2342</X>
    <Y>1041</Y>
  </MOVETO>
  <DRAWTO>
    <X>2542</X>
    <Y>1040</Y>
  </DRAWTO>
</VECTORS>

`

The coordinates were next all shifted using the pivot point so that the new pivot point is 0,0. Then a point symbol was made from the drawing instructions NODATA03P.svg and a symbolFill was made using the header information NODATA03.xml.

The conversion was not meant to attempt to fix symbols or recalculate bounding boxes etc it was meant to replicate the S-52 symbol content.

There is some strangeness in the S-52 DAI for this pattern. The symbol has a width of 6.66mm (including linewidth) which includes a 2mm long and 2pixel wide line followed by a 4mm space. The line is drawn from -6 to -4 with respect to the pivot point which means that it would draw 6mm to the left of the start of the pattern.

It seems it would be better if it started at an X= 0 and went to X=2.

The conversion set up V1 and V2 as follows. If the pattern is linear V1 x = symbol width + MINDISTANCE, y=0 V2 x= 0, y=0

If the pattern is staggered V1 x = symbol width + MINDISTANCE, y=0 V2 x= symbol width , y=symbol height + MINDISTANCE

It seems that the results reflect the input coming from the DAI. The pattern and symbol could be rationalized without changing the net result but there does not appear to be anything wrong with the conversion.

[DavidGrant-NIWC]

Use files provided by @IngaFjellanger in PC 1.1.0

[alvarosanuy]

Portrayal subWG meeting - 11th January 2023

1. Decided to use new files provided by @IngaFjellanger above. @DavidGrant-NIWC to update header and upload to this space so Alvaro can commence registration of the new versions in the IHO GI Registry.

2. For PC 1.1.0.

[mikan66]

Portrayal subWG meeting - 11th January 2023

1. Decided to use new files provided by @IngaFjellanger above. @DavidGrant-NIWC to update header and upload to this space so Alvaro can commence registration of the new versions in the IHO GI Registry.
2. For PC 1.1.0.

What do we want the header to be? Currently: <?S100lineage source="S52Preslib4.0" format="S100Ed2" version="0.1_dKart" creationDate="2022-04-01"?>

All other existing fills have: <?S100lineage source="S52Preslib4.0" format="S100Ed2" version="0.1" creationDate="2015-03-03"?>

There are other newer files (not fill files but for example line style file DSCWTR51.xml) where source is defined as : source="dKartOffice" and version="0.1"

[alvarosanuy]

@mikan66 - Please discuss with @DavidGrant-NIWC first as he was at the meeting. If not standardisation has been done on any other files so far (mainly due to a lack of guidance on this topic) then I would suggest proceed as it is and worry about possible standardisation at a global scale later down the track ......

Please confirm NIWC's preference and let me know your way forward. I need to make sure I register the same files in the GI Registry. If you update any of the fields, please update the new file versions to this space.

[DavidGrant-NIWC]

I don't think this matters too much because the metadata should not be used by the ECDIS. I believe it's mainly intended to be used by the PC developer for traceability and configuration management.

That said, after a little investigation I've found that:

• S-100 specifies the required metadata format for SVG files
  • https://schemas.s100dev.net/schemas/S100/5.0.0/S100PC/20220705/S100SVG1.xsd
• S-100 does not describe a file format (other than "XML") for AreaFills or LineStyles.
  • The format of the classes within the file are defined in https://schemas.s100dev.net/schemas/S100/5.0.0/S100PC/20220705/S100SymbolDefinition.xsd
  • No metadata format is described
  • There is a de facto format for Metadata
  • Included via XML processing instructions: http://xmlplease.com/xml/pi/

AreaFill and LineStyle processing instructions:

• S100lineage carries attributes which match the SVG file metadata available in the "Description" element, minus the publisher.
• S100Meta carries "name" and "exposition" attributes, which match the SVG file "title" and "desc" elements respectively.
• S100Meta is not intended to be processed by the ECDIS - the name and description from portrayal_catalogue.xml should be used.

Recommend that at least for now we standardize on matching the metadata content of the SVG files without changing the current XML processing instructions. We should add the "publisher" attribute	Processing Instruction	Attribute	Description	Recommended content
S100lineage	publisher	Who is publishing the file.	"IHO" (most of the existing SVG files contain "IHB")
S100lineage	creationDate	When the file was created	Self explanatory.
S100lineage	source	Origin of the file contents (for traceability)	"S-52 PL x.y.z DAI TOKEN", "https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/92", etc.
S100lineage	format	The format of the file	S-100 9-13.3.31 FileFormat: "svg" for symbols, "xml" for others
S100lineage	version	The version of the file	"1.0" for initial registration
S100Meta	name	The name of the fill pattern or line style	Match the file name (minus the file extension)
S100Meta	exposition	Describes the fill pattern or line style	What it represents, not necessarily what it looks like

Example:

[alvarosanuy]

Recommend that at least for now we standardize on matching the metadata content of the SVG files without changing the current XML processing instructions. We should add the "publisher" attribute

@DavidGrant-NIWC & @mikan66 - Thank you very much for the research and the summary. From now we should strive at using these conventions when creating new files but would you update the files already created by @IngaFjellanger and that the PsWG decided to implement in PC 1.1.0 ?? Related issues (like this one) have a comment for @DavidGrant-NIWC to review/update the header of the files (and upload the new versions). Whatever decision you make when processing these issue, please make sure you make it clear so I know how to proceed with the registration of the associated files.

[rmalyankar]

The file formats are defined by the schemas for linestyle and area fill:

• linestyle: https://schemas.s100dev.net/schemas/S100/5.0.0/S100PC/20220705/S100LineStyle.xsd
• areafill: https://schemas.s100dev.net/schemas/S100/5.0.0/S100PC/20220705/S100AreaFill.xsd

Using XML processing instructions to provide metadata is an unsanctioned loophole. S-100 Appendix 9-B clause 9-B-2-4 Metadata says:

The IHO S-100 working group is encouraged to define a metadata Schema for use with S-100 symbols.

Since I am working on the 5.1 schemas now, this would be the perfect time to define and formalize metadata for SVG files. The "SVG1" file includes publisher.

https://schemas.s100dev.net/schemas/S100/5.0.0/S100PC/20220705/S100SVG1.xsd

[mikan66]

1. I support standardizing the metadata at future schema revision, (recommend a new issue or discussion topic), but there are no production tools the output anything in proper format that I know of. This means manual edits every time for new symbols.
2. Reviewing and changing all the existing files is a large undertaking and I don't recommend it at this time
3. I will "clean-up" the new symbols (specific to this issue) in a minor way to mirror the existing older files metadata.

[DavidGrant-NIWC]

metadata discussions should be carried out in https://github.com/S-101-Portrayal-subWG/Working-Documents/issues/103

[alvarosanuy]

Implemented in PC 1.1.0

New xml files (with updated header) for NODAT03, VEGATN03 & VEGATN04 were generated by @mikan66 in https://github.com/iho-ohi/S-101_Portrayal-Catalogue/issues/138.

@alvarosanuy has registered them as new versions of the existing areaFill instances in the GI registry.