search

iho-ohi / S-164-Sub-Group

Development and tracking of IHO S-164 Test datasets and user manual documentation
15 stars 2 forks source link

Support file formats tested by S-164 #19

Open DavidGrant-NIWC opened 1 year ago

DavidGrant-NIWC commented 1 year ago

S-164 should test all support file formats intended for use in ECDIS.

Currently, only ASCII and TIFF files are provided.

image

image

image

kusala9 commented 1 year ago

Need agreement from meeting which formats to implement on ECDIS... One for discussion but I would suspect only

could be implemented - they would also need dark pallettes which have been an issue in the past. XML, LUA and video I suspect will be an issue and we should also qualify what HTML elements would be supported in ECDIS too. I think the idea is ECDIS itself should only support static representations of information useful to the end user. But willing to take input from OEMs on this.

Once we agree the formats to be supported we can action the datasets to include examples of each and add to the relevant test.s (which are?)

DavidGrant-NIWC commented 1 year ago

I think adding a JPEG2000 file would be good for now. Note that the remarks on the PDF format suggest that it should not be used in products destined for navigation systems.

Note that JPEG2000 is not valid for S-101 data: "Picture files that form part of the ENC must be in Tagged Image File (TIF) format 6.0."

kusala9 commented 1 year ago

I believe NIPWG would probably want HTML and PDF too but I will try and get some input from NIPWG chair on that. Is the quote above from the S-101 product spec? fine for S-101 to constrain to TIFF only but I believe this is a hangover from S-57 and I'm not sure the constraint is meaningful now. ECDIS should have all its file formats defined in S-98 Annex C really... OEM input required.

rmalyankar commented 1 year ago

HTML is definitely needed.

XML should also be tested. ISO codelist dictionaries, for example, are XML files.

PDF - not on ECDIS, especially since S-100 5.0.0 says :

Product Specification developers should take careful consideration in using PDF as a support file format. It is recommended that PDF never be used in products that will be used on a navigation system as it may impair night vision.

"ASCII" support files should actually be UTF-8 encoded files, always.

DavidGrant-NIWC commented 1 year ago

Is the quote above [S-101 pictures must be in TIFF format] from the S-101 product spec? fine for S-101 to constrain to TIFF only but I believe this is a hangover from S-57 and I'm not sure the constraint is meaningful now. ECDIS should have all its file formats defined in S-98 Annex C really... OEM input required.

It's in the DCEG so it still applies. See DCEG 1.1.0 clause 2.4.12.2, "Reference to pictorial files".

kusala9 commented 1 year ago

HTML is definitely needed.

XML should also be tested. ISO codelist dictionaries, for example, are XML files.

PDF - not on ECDIS, especially since S-100 5.0.0 says :

Product Specification developers should take careful consideration in using PDF as a support file format. It is recommended that PDF never be used in products that will be used on a navigation system as it may impair night vision.

"ASCII" support files should actually be UTF-8 encoded files, always.

XML - agree it needs to be delivered to ECDIS maybe as part of exchange set but I don't believe there's a requirement to "display" to the end user arbitrary XML.

Summary of this thread, currently is display on ECDIS formats are:

Others? When these are agreed examples can be added to the S-164 test datasets. S-98 should be clarified to state which formats are required for display to the user as supporting resources...

rmalyankar commented 1 year ago

Web browsers can display XML to the end user, not with XML tags but as properly formatted user-readable text, given a CSS stylesheet that styles the XML elements. This would simplify production from source material that is available in XML rather than HTML.

If we're going to reduce issue clutter in this repository, this issue and all other S-98 content issues should be transferred to iho-ohi/98-interoperability/issues#7 since we're not discussing tests. or test cases. Transferring requires at least "collaborator" access to this repo, which I don't have.

DavidGrant-NIWC commented 1 year ago

Is there a use case for a mariner/user to benefit from looking at XML? Seems like these files would be intended for machine readability / system implementers.

rmalyankar commented 1 year ago

With a stylesheet they wouldn't be looking at XML, they'd see paragraphs, blocks, as if it were HTML. WIll try to make an example later.

DavidGrant-NIWC commented 1 year ago
rmalyankar commented 1 year ago

The content could be delivered as text or HTML just as easily via XSLT transform at the producer.

There is no way most producers will agree to accept the responsibility of writing XSLT transforms to generate HTML from whatever XML source material they might have. I am not even going to suggest that.

The use case is mentioned above: source material in XML. Everything doesn't turn up conveniently formatted as HTML.

It requires two support files ("XML" and "other").

Just handle the CSS file as an "other" file, then. That will end up being necessary anyway.

DavidGrant-NIWC commented 1 year ago

If there is really a use case for formatted text delivered as XML (which product is asking for it?) then CSS should be added as a support file format so that it can support XML support files. S-100 or S-98 should then be updated to indicate that the system is responsible for styling XML with supporting CSS files. Consideration should be given to handling day/dusk/night color palettes. These changes would require a change proposal and would not be available until S-100 v6.

Alternatively, the product spec could use the existing capabilities to deliver XML and CSS (via "other") and require styling as a product-specific functionality. Or they could just deliver text/html/pdf.

Getting back on track (which formats should be included in S-164) I'd recommend just adding tests as products indicate a need and as they provide/request supporting test datasets.

kusala9 commented 1 year ago

Web browsers can display XML to the end user, not with XML tags but as properly formatted user-readable text, given a CSS stylesheet that styles the XML elements. This would simplify production from source material that is available in XML rather than HTML.

If we're going to reduce issue clutter in this repository, this issue and all other S-98 content issues should be transferred to iho-ohi/98-interoperability/issues#7 since we're not discussing tests. or test cases. Transferring requires at least "collaborator" access to this repo, which I don't have.

Reason for this being in S-164 repo is that all the formats we decide will be implemented need test cases in S-164 somewhere.

I think we have, so far...

File formats supported for portrayal in ECDIS in pick reports (as opposed to file formats supported for delivery to ECDIS)

any others? We can feed these back as initial data requirements for test datasets and resolve XML and HTML.

MikusRL commented 5 months ago

As I understand that out of this decision: https://github.com/iho-ohi/S-101-Documentation-and-FC/issues/113#issuecomment-1944436558, for S-101 PS ENC Support files specifically only the formats ".TXT" for UTF-8 ENC textual information support files and ".TIFF" for ENC pictorial support files is agreed for 2.0. This is to clarify specificly for S-101 ENC Support files tests part in particular. I understand then that there is no need for S-101 ENC Support files in formats ".XML" or ".HTM" for UTF-8 ENC textual information support files and ".JPEG" for ENC pictorial support files for backward compatibility to S-57 sake during the Dual Fuel period. Correct?

But of course the S-100 other system Support files for S-101 and any Support files for any other Product Specification (S-102, S-104, S-111) discussed earlier here above that decision does not impact - they still can be added in the Exchange sets, also alongside S-101 datasets if and as needed, and tested in S-164 for ECDIS particular functionality testing, which also could also impact the S-101 data portray or other S-101 data or ECDIS behavior. Also correct?

This comment is because we had a small initial discussion in the Support files TG with David Grant, and we did interpreted the mentioned Jeff's comment bit differently initially. Looking for the clarification specifically for the expected interpretation of S-101 v.2.0 ENC Support files expected tests in particular in the initial operational S-164. Thanks. FYI @DavidGrant-NIWC , @kusala9 , @jeffwootton, @rmalyankar , @tomrichardson6, @skjeves

rmalyankar commented 5 months ago

The referenced issue https://github.com/iho-ohi/S-101-Documentation-and-FC/issues/113 is about S-101 support picture files only. It does not affect HTML or XML.

DavidGrant-NIWC commented 5 months ago

S-101 support file comments should be resolved in https://github.com/iho-ohi/S-101-Documentation-and-FC/issues/159

kusala9 commented 1 month ago

this can now track the addition of all formats in the existing test dataset, and their inclusion in exchange sets (with applicable tests). I think the only additional format (after all that) is JPG2000. HTML, XML, PDF are all out.