Talk:NtM Chart-correction XML - Revision history

Rmm: Text replacement - "wp12183585.server-he.de/npubwiki/wiki" to "wp12183585.server-he.de/npubwiki/nwiki"

2023-05-23T18:24:58Z

Text replacement - "wp12183585.server-he.de/npubwiki/wiki" to "wp12183585.server-he.de/npubwiki/nwiki"

Jens at 07:34, 10 September 2018

2018-09-10T07:34:48Z

Jens at 06:51, 10 September 2018

2018-09-10T06:51:16Z

Jens at 06:47, 10 September 2018

2018-09-10T06:47:45Z

Jens at 06:43, 10 September 2018

2018-09-10T06:43:23Z

Jens: Created page with " ==Images and Symbols== ===Format=== LS: Italy prefers to have them in a true type font format (like Arial, Times New Roman etc). They can be easily managed by all the pro..."

2018-09-10T06:41:13Z

Created page with " ==Images and Symbols== ===Format=== LS: Italy prefers to have them in a true type font format (like Arial, Times New Roman etc). They can be easily managed by all the pro..."

New page

==Images and Symbols==

===Format===
LS:
Italy prefers to have them in a true type font format (like Arial, Times New Roman etc). They can be easily managed by all the production systems, while I see difficulties of tiff and svg formats. <br>
How to display a wreck with the least depth known? With a tiff image of a general wreck and beside the text with the depth value and Wk abbreviation?

JS-F:
The True Type Format could be seen as along term goal. Germany could possibly provide a tool which generates TIFF images for symbols with variable values on the fly. However, the XML should be written in a way that the symbols format is of less relevance. More inportant is to check the IHO capability to host a set of symbols and the provision of a "text description" of each symbol. The latter could be used as a universal translation tool between different symbol libraries.

LS:
I agree with Jens about not going to deep into symbols (format and so on): HO can decide to use one or the other.
At the moment I guess that we come to a common structure of the XML for the “core of a chart notice” (i.e. attributes of ChartCorrectionContent element in Stephan’s UML Diagram).
My idea is to have the following schema/tags:

Language 1
Symbol
Textual description
Additional text
Language 2
Symbol
Textual description
Additional text
Language n
Symbol
Textual description
Additional text

The “Symbol+Textual description” make the part Jens explained in his email letter b).
The Symbol will consist in one of the following type: FILE or TEXT.
The FILE is ok either for tiff images or SVG file (there are XML files). The TEXT will be ok for True Type Font (actually it is only text, formatted: i.e. <FONT face="Font_name" size="5"> 1</FONT>).
HOs can choose where they need to use:
1) only Symbol:  or
2) Symbol+Textual description: Racon(B) or Fl(2)G3s

3) only Textual description: a lighted spherical safe buoy and a radio transponder beacon

4) Symbol+Additional text: joining the followings positions…

or the other possible combinations of elements.

@@ Line 49: / Line 49: @@
 A.
 Based on Ludovicos explanation of how TTF is used, I made a small update to the UML- diagram at;
-http://wp12183585.server-he.de/npubwiki/wiki/index.php/NtM_Chart-correction_XML#Format
+http://wp12183585.server-he.de/npubwiki/nwiki/index.php/NtM_Chart-correction_XML#Format
 By the update, a symbol can be based on either TTF or Image. Hopefully I understood correctly. If not, let me know.

← Older revision		Revision as of 07:34, 10 September 2018
Line 211:		Line 211:
	SE in response on JSF:		SE in response on JSF:
	Regarding the different options for representing symbols, I see the several benfits with option 2. I think that would probably be the optimal solution for the future, but I also think it might be beneficial to start with a basic version (like option 1), while keeping the vision and development of option 2 alive for future implementation.		Regarding the different options for representing symbols, I see the several benfits with option 2. I think that would probably be the optimal solution for the future, but I also think it might be beneficial to start with a basic version (like option 1), while keeping the vision and development of option 2 alive for future implementation.
		+
		+	==Language==
		+	The corrections should be provided in multiple languages.
		+
		+	n the UML there is a separate class '''MultilangString''' to indicate which attributes currently need to be provided in several languages. For example chart-texts are not translated. I think the easiest way to achieve support for several languages would be to provide each language in a separate file.

← Older revision		Revision as of 06:51, 10 September 2018
Line 105:		Line 105:
	Based on the previous scenario, to achieve interoperability between systems, we need to translate data if production systems are different. It is merely a question of where this data is translated.		Based on the previous scenario, to achieve interoperability between systems, we need to translate data if production systems are different. It is merely a question of where this data is translated.
	It seem that translation into a common symbol format in the “upper row” would provide less hassle. That would mean that TTF- symbols were translate into image files by the producer.		It seem that translation into a common symbol format in the “upper row” would provide less hassle. That would mean that TTF- symbols were translate into image files by the producer.
		+
		+
		+
		+	JSF:
		+	Symbol(s)
		+
		+	We don’t support the intention to make any kind of symbol font mandatory in the exchange xml.
		+	It would result severe problems as the fonts must be available on all computers in the production chain. We have concerns that this could not be internationally implemented (security reason, HOs policies, licensing etc.).
		+
		+	We rather suggest following structure:
		+
		+	Option 1:
		+	Either raster sympols or vector symbols are mandatory. Font and text are optional.
		+
		+	xml:
		+
		+	<symbolLeft>
		+	<symbolRaster></symbolRaster>
		+	<symbolVector></symbolVector>
		+	<symbolFont></symbolFont>
		+	<symbolTxt></symbolTxt>
		+	</symbolLeft>
		+
		+
		+	associated xsd:
		+
		+	<?xml version="1.0" encoding="UTF-8"?>
		+	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
		+	<xs:element name="symbolLeft">
		+	<xs:complexType>
		+	<xs:sequence>
		+	<xs:choice>
		+	<xs:sequence>
		+	<xs:element name="symbolRaster"/>
		+	<xs:element name="symbolVector" minOccurs="0"/>
		+	</xs:sequence>
		+	<xs:sequence>
		+	<xs:element name="symbolVector"/>
		+	<xs:element name="symbolRaster" minOccurs="0"/>
		+	</xs:sequence>
		+	</xs:choice>
		+	<xs:element name="symbolFont" minOccurs="0"/>
		+	<xs:element name="symbolTxt" minOccurs="0"/>
		+	</xs:sequence>
		+	</xs:complexType>
		+	</xs:element>
		+	</xs:schema>
		+
		+
		+	Option 2:
		+	symbolTxt is the only mandatory element. The structure should follow the S-57/S100 conventions.
		+
		+
		+	<symbolTxt>
		+	<BOYCAR>
		+	<BOYSHP>pillar</BOYSHP>
		+	<CATCAM>north cardinal mark</CATCAM>
		+	<COLOUR>black, yellow</COLOUR>
		+
		+	</BOYCAR>
		+	<TOPMAR>
		+	…
		+	</TOPMAR>
		+	<LIGHTS>
		+	…
		+	</LIGHTS>
		+	<ChartLabel>
		+	<Content>Fl.Y.3s</Content> [currently, single attributes in LIGHTS]
		+	<!-- <Style>bold, italic, 6pt</Style> -->
		+	</ChartLabel>
		+
		+	</symbolTxt>
		+
		+	Pros:
		+	- bijective coding scheme
		+
		+	Cons:
		+	- “one Picture says more than thousand words”
		+	- the HO’s will need effort for programming to visualize the symbols
		+	- we have to provide a look-up table which compares text with associated symbols
		+
		+	The associated xsd in that case would be:
		+
		+	<?xml version="1.0" encoding="UTF-8"?>
		+	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
		+	<xs:element name="symbolLeft">
		+	<xs:element name="symbolVector" minOccurs="0"/>
		+	<xs:element name="symbolRaster" minOccurs="0"/>
		+	<xs:element name="symbolFont" minOccurs="0"/>
		+	<xs:element name="symbolTxt" minOccurs="1"/>
		+	</xs:element>
		+	</xs:schema>
		+
		+
		+
		+	Textual description
		+
		+	We agree with Stefans’s suggestion to separate in ChartLabel and TextualDescription.
		+
		+	Style within XML
		+
		+	We strongly recommend to separate content from style. It is the task of xslt to style xml documents.
		+
		+
		+	SE in response on JSF:
		+	Regarding the different options for representing symbols, I see the several benfits with option 2. I think that would probably be the optimal solution for the future, but I also think it might be beneficial to start with a basic version (like option 1), while keeping the vision and development of option 2 alive for future implementation.

← Older revision		Revision as of 06:47, 10 September 2018
Line 71:		Line 71:
	C.		C.
	Formatting of the chart labels / textual descriptions. The Racon (B) in magenta caught my attention from the sample below. Should we allow some kind of text-formatting within the textual descriptions? HTML- tags within the XML provide some difficulties if translated for use in systems without HTML- support. On the other hand, formatting of text using different colors could improve readability. Is there a need for us to define / restrict the allowed ways of formatting text?		Formatting of the chart labels / textual descriptions. The Racon (B) in magenta caught my attention from the sample below. Should we allow some kind of text-formatting within the textual descriptions? HTML- tags within the XML provide some difficulties if translated for use in systems without HTML- support. On the other hand, formatting of text using different colors could improve readability. Is there a need for us to define / restrict the allowed ways of formatting text?
		+
		+
		+
		+	MK:
		+	We use symbols (TTF) for the most part but in some cases we have to use text as we do not have enough TTF symbols. We do not use colour for symbols at all. Unfortunately the font doesn’t cover all the symbols, so the rest are simply typed out as text.
		+
		+
		+	LS. in Response to SE:
		+	Regarding (C.), I’m not able to answer about the HTML tags into XML. Maybe, but I’m not sure, another way to by bypass this fact could be make TextualDescription made of 2 elements UnformattedText and FormattedText that can be mixed many times in different order. FormattedText is, in turn, made of FONT, SIZE, COLOR, CHARACTER tags.
		+
		+	SE:
		+	The current data model would allow a symbol to be either a reference to an image file or a character string with a reference to a given true type font. I made this addition to the UML based on the previous discussion, concluding that the format discussion is out of scope of this workshop, and it should be up to the HO to decide on format. Even so, I do also have a concern regarding the use of ttf- symbols in the transfer file. A few points;
		+
		+	• If ttf is used in a transfer file, all the referenced font- files have to be publicly available and either embedded within the exchange set or available at a referenced online location.
		+	• Each system seem to have an individual set of fonts, and in order to cater for all symbols, more than one font set is needed.
		+
		+	Most of the file-samples (our own included) seem structured as documents. This transfer data format should most probably not fit all these structures, but instead be a bit more complex, data-centric, and contain all the data needed to translate (using XSL) between formats.
		+
		+	example of translation into transfer format;
		+
		+	• SOURCE_HO_NTM.XML => SOURCE_TO_COMMON.XSL => COMMON_NTM.XML
		+	• COMMON_NTM.XML => COMMON_TO_RCVR.XSL => RCVR_HO_NTM.XML
		+
		+	If we suppose the source HO (upper left) and receiver HO (down right) are using different schemes for symbols, we need to translate between formats;
		+
		+	1. COMMON_NTM.XML contains TTF- symbols
		+	a. If receiver uses TTF, the font files of all sources must be included in all their systems, in order to use the symbol (?)
		+	b. If receiver uses PNG / SVG, the original font file is needed to convert ttf- symbol into image file
		+	2. COMMON-NTM.XML contains PNG/SVG- symbols
		+	a. If receiver production system does not support symbol- files, he cannot use the data (?) PNG / SVG => TTF conversion possible??
		+	b. If receiver uses image files, he should be able to re-use the provided files
		+
		+	Based on the previous scenario, to achieve interoperability between systems, we need to translate data if production systems are different. It is merely a question of where this data is translated.
		+	It seem that translation into a common symbol format in the “upper row” would provide less hassle. That would mean that TTF- symbols were translate into image files by the producer.

← Older revision		Revision as of 06:43, 10 September 2018
Line 45:		Line 45:

	or the other possible combinations of elements.		or the other possible combinations of elements.
		+
		+	SE:
		+	A.
		+	Based on Ludovicos explanation of how TTF is used, I made a small update to the UML- diagram at;
		+	http://wp12183585.server-he.de/npubwiki/wiki/index.php/NtM_Chart-correction_XML#Format
		+	By the update, a symbol can be based on either TTF or Image. Hopefully I understood correctly. If not, let me know.
		+
		+	Q: Do we need color indication for TTF?
		+	Q: Is TTF symbol always one character, or could it be a longer string?
		+
		+	B.
		+	‘Textual description’ in the sample below could be either a chart label or an explanation. We separate text fields based on whether it is text that is actually shown on the chart (and normally does not need translation, like names on charts, light characteristics etc.), or a description that needs to be translated. In the UML this is indicated by the fact that only some strings are type “MultilangString”.
		+
		+	My suggestion would be to separate descriptions from chart labels, like;
		+	• ChartLabel (no translation)
		+	o Fl(2)G3s
		+	o Racon(B)
		+	• TextualDescription (needs translation)
		+	o a lighted spherical safe buoy and a radio transponder beacon
		+
		+	For visual display the empty fields could be collapsed, so this would mainly be a way to keep a structure of the data.
		+
		+	..on the other hand this is further making me think that the easiest way would be to provide only one language in each file.
		+
		+	C.
		+	Formatting of the chart labels / textual descriptions. The Racon (B) in magenta caught my attention from the sample below. Should we allow some kind of text-formatting within the textual descriptions? HTML- tags within the XML provide some difficulties if translated for use in systems without HTML- support. On the other hand, formatting of text using different colors could improve readability. Is there a need for us to define / restrict the allowed ways of formatting text?