-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect drawing of some Area patterns #92
Comments
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. |
FixedAreaPatterns_comment#11.zip |
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: The coordinates were next all shifted using the pivot point so that the new pivot point is 0,0. 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. 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 staggered 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. |
Use files provided by @IngaFjellanger in PC 1.1.0 |
Portrayal subWG meeting - 11th January 2023
|
What do we want the header to be? Currently: All other existing fills have: 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" |
@mikan66 - Please discuss with @DavidGrant-NIWC first as he was at the meeting. 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. |
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:
AreaFill and LineStyle processing instructions:
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. |
The file formats are defined by the schemas for linestyle and area fill:
Using XML processing instructions to provide metadata is an unsanctioned loophole. S-100 Appendix 9-B clause 9-B-2-4 Metadata says:
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 |
|
metadata discussions should be carried out in #103 |
Implemented in PC 1.1.0 New xml files (with updated header) for NODAT03, VEGATN03 & VEGATN04 were generated by @mikan66 in iho-ohi/S-101_Portrayal-Catalogue#138. @alvarosanuy has registered them as new versions of the existing areaFill instances in the GI registry. |
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:
The text was updated successfully, but these errors were encountered: