Feature and Coverage Portrayal using SLD/SE

In this context Feature Portrayal is defined as visualizing GML Features, and Coverage Portrayal as visualizing coverage (grid) data using graphical (raster or vector) images. To make these visualizations standardized across different visualization software (WMS, stand-alone clients like meteorological workstations and so on), the visualization rules must be standardized. Within the OGC standards the Styled Layer Description (SLD) and the Symbology Encoding (SE) together are meant for defining these kinds of visualization rules.

This is a wiki page, so please contribute if you have some more information or something does not look right.

Existing visualisation rules of WMO and ICAO

WMO mandates the appearance of hundreds of weather symbols, dozens of line styles and several polygon area fill styles so that professional weather charts are 'interoperable' between meteorologists of all countries of the world. The symbols are robust with respect to poor reproduction, different display technologies and viewing in dim light such as an aircraft cockpit at night. Consequently they use a very limited set of colours. Monochrome options exist for all the styles.

The definitive document is the Manual on the Global Data Processing System, Part II, Appendix II.4, Graphical Representation of Data, Analyses and Forecasts.

ICAO mandates the appearance of Significant Weather (SigWx) and other charts issued to all pilots in the world. They are generally monochromatic, readable in dim light, and relatively insensitive to being transmitted over noisy links.

The definitive document is the Chicago Convention, Annex 3, Appendix 1, Flight Documentation - Model Charts and Forms, which is tightly controlled by ICAO.

As there is some coordination between the WMO and ICAO styles, for convenience, some reference document extracts, existing examples and discussions and work in progress are collected here. In particular, lots of samples, in a variety of formats, of the symbols have been collected, and the first comprehensive set of WMO Weather Symbols, in SVG, has been created.

Work Plan (needs updating)

1. Select some good (challenging enough) visualization examples from the ICAO / WMO weather presentation world [Done]. How much may the different visualizations actually be different to comply with the rules? (pixel-perfect, exact colors & line widths, recognizable shapes & colors, line labels positioned at the center of the iso lines,..). We don't want to re-invent SVG, neither do we want each software to display the SWCs in a completely different way.
2. Get familiar with the capabilities of the current SLD & SE standard versions [Done]. What part of the examples cannot be or is very complicated to describe using them? Gather the existing knowledge from our visualization people: "What information would you want to be included in the SLD/SE to create a visualization like this?"
3. Which of the new CR's proposed for SLD/SE SWG do affect the problematic issues found in the previous point? Are they enough to solve the problems? Do they cause new problems?
4. SLD/SE SWG is proposing a conceptual abstract model to underpin the existing SLD/SE standard(s). The conceptual model seems rooted in a 2D cartographic approach to visualisation, which does not help with scientific data plots, vertical cross sections, Hovmõller diagrams, animations/time lapse image sequences.
5. The SLD/SE approach does not help with 3D simulators, such as for military or aviation training, or multi-player games, or Smart 3D city initiatives.
6. However, the proposed concpetual abstract model for SLD/SE does seem intrinsically independent of specific dimensions. To tackle this, some Use Cases have been formulated.
7. Find out if there are any working implementations of the server products already implementing the proposed SLD/SE changes (perhaps someone is implementing those in OWS-7). Try to visualize the Met examples using those implementations. Are the results good enough? Do they look the same?
8. Propose changes or new CRs to the SLD/SE SWG to fix the identified issues.
9. Write a paper about the process and the results with recommendations for WMS + SLD/SE visualization of the MetOcean domain object and gridded data. Get it published as an OGC Public Engineering Report, perhaps as OGC Best Practice (eventually).

Actions and Roadmap (needs updating)

Near future (December 2009 - June 2010):

• 31st January 2010: Deadline for success / failure cases for MetOcean data portrayal using SLD/SE (posted to the MetOcean DWG posting list on 10th December 2009)
• March 2010 TC Meeting in Frascati: review of the success / failure cases, need for new CRs for the SLD/SE, see Presentation: A MetOcean Wish List for SLD/SE , Presented at Frascati SLDSE SWG meeting, 10th March 2010
• March - June 2010: preparing for the possible CRs for the SLD/SE SWG It is probably not possible to include any new CRs in the next SLD/SE standard version 2.0. because of the time limitations. It is still a good idea to formalize the possible change requests as OGC CRs to be considered in the following standard versions.
• March - June 2010: prepare a table for the different Met Ocean visualization cases with indication of whether they can be expressed in SLD/SE 1.1, in the CRs proposed to the SLD/SE SWG, or not likely to be supported by forthcoming SLD/SE 2.0.
• 20th June 2010: The deadline for submitting change requests to the SLD/SE Standards Working Group for inclusion in the next standards revision.

This schedule tries to be inline with the SLD SWG milestones:

Use Cases

There are at least two important use case categories related to the meteorological data exchange:

• Discussion and information exchange between domain experts, like weather forecasters on duty. Need to be able to communicate complex weather information, including uncertainty issues.
• Publishing weather data for users outside the meteorology domain experts. Need to make sure the information is interpreted correctly and that the information can be trusted.

MetOcean DWG activities connected to the visualization issues considering these use cases will be listed in this page and its subpages.

Feature Portrayal

GML Feature data to visualize: Weather Information Exchange Model (WXXM), Weather Object Modelling Language (WOML), OGC O&M based features for observation data,...

Aviation ICAO Annex 3 SIGWX chart style and the WMO chart styles for professional meteorologists exist, but the format is not directly applicable for Feature Portrayal. Also the current SLD/SE standards may be insufficient for expressing these legally mandated visualization rules.

Information about the ICAO & WMO requirements (by Chris Little):

1. One symbology is the aviation one, specified in: Annex 3 - Meteorological Service for International Air Navigation Part II - Appendices and Attachments 17th edition, 18 November 2010, Appendix 1 Flight Documentation - Model Charts and Forms.

Annex 3 refers to the Chicago Convention http://www.icao.int/icaonet/arch/doc/7300/7300_9ed.pdf. I cannot find any online version, probably because ICAO Publications Department charges $177 for it.

Actual maps - try http://www.flyingineurope.be/aviation_weather_maps.htm

2. The WMO symbology is mainly in the WMO Manual on the GDPS (Global Data Processing System) - again a paper document.Some symbols here http://www.rap.ucar.edu/weather/info/about_wxsymbol.html Rather more here: http://www.weathergraphics.com/dl/wxchart.pdf, with simplified indication of how they are plotted (grouped for visualisation). Slightly more explicit explanations, though rather dated, but shows how we did it by hand at http://www.tpub.com/content/aerographer/14269/css/14269_167.htm and http://www.tpub.com/content/aerographer/14269/css/14269_166.htm and http://www.tpub.com/content/aerographer/14269/css/14269_168.htm.

This is probably better http://www.srh.noaa.gov/jetstream//synoptic/wxmaps.htm and http://www.australianweathernews.com/current_AWN_charts_guide.shtml.

This is probably best: http://www.srh.noaa.gov/jetstream//synoptic/sfc_plot_symbols.htm

Again, some sample maps at http://w1.spc.woc.noaa.gov/exper/mesoanalysis/s4/sfcmap.pdf

Goals

• make sure that the next versions of the SLD/SE standards will be capable of expressing the WMO/ICAO visualization rules.
• make sure that the feasibility of feature portrayal for real weather data features using SLD/SE is proven within an OGC IE or some other public testbed projects with more than one feature portrayal implementation (possible already in the context of OWS-7?)
• make sure the WMO and ICAO are willing to publish (and host) their current visualization descriptions as SLD/SE documents

Coverage Portrayal

Coverage portrayal for meteorological (gridded) data using domain conventions including

• isoline visualization of geophysical parameter fields, like pressure and temperature (with labeling conventions)
• coloring and hatching conventions for areas with geophysical parameter values below or above certain thresholds (temperature at 850 hPa?)
• wind and wave visualizations with special arrow symbols indicating both the strength and the direction of the field grid points
• stream line visualization of wind, sea currents(?). Note that these are NOT trajectories.
• what else? Any special visualization requirements for cross sections, radar data, satellite data,...?
• Animations are often used, sometimes with moving and changing symbols following flows.

Standards & OCG Working Groups To Consider

At least the following OGC SWGs are of interest here:

• SLD/SE 1.2/2.0 (?) SWG
• WMS 1.4 (?) SWG

Others? WCS (digital signatures contained inside the WCS results (see Validity and Integrity)?

Requirement / Capability Table (for SE) (needs updating)

The new SE 2.0 will be based on the existing OGC Implementation Standard OGC 05-077r4: SE 1.1.

The Change requests considering the Symbology Encoding listed in the SLD/SE SWG charter are (unfortunately accessible only for OGC Members through the OGC Portal):

• OGC 07-105: SE Change request for thematic mapping,
• OGC 09-014: OWS-6 Symbology Encoding (SE) CR, and
• OGC 09-043r1:Enhancements to Symbology Encoding in Support of IHO S-52 and UKHO AML

Below is requirement / capability table for the Meteo portayal visualization cases. Use the case titles to get detailed information including realistic data and visualization examples (work in progress)

		Supported in standard or change requests
Type	Visualization case	SE 1.1	OGC 07-105	OGC 09-014	OGC 09-043r1	Likely in SE 2.0	Trivial tiling (WMTS)
Feature	Single WMO Symbols	yes	n/a	yes	yes	yes	unverified
Feature	Directed frontal lines without endings	unverified	unverified	unverified	unverified	unverified	unverified
Feature	Troughs and other lines with endings	unverified	unverified	unverified	unverified	unverified	unverified
Feature	Rain and cloud areas with symbol filling	unverified	unverified	unverified	unverified	unverified	unverified
Feature	WMO Synop plot using combined symbols	unverified	unverified	unverified	unverified	unverified	unverified
Feature	SigWx chart jet lines with internal structure	unverified	unverified	unverified	unverified	unverified	unverified
Feature	SigWx chart borders of sig weather (line & area)	unverified	unverified	unverified	unverified	unverified	unverified
Coverage	Isoline charts from continuous grid data	unverified	unverified	unverified	unverified	unverified	unverified
Coverage	Stream Line charts from continuous grid data	unverified	unverified	unverified	unverified	unverified	unverified
Coverage	Color contour charts from continuous grid data	unverified	unverified	unverified	unverified	unverified	unverified
Coverage	Wind arrow charts from continuous grid data	unverified	unverified	unverified	unverified	unverified	no
Coverage	Wind barb charts from continuous grid data	unverified	unverified	unverified	unverified	unverified	no

It is most likely that important visualization cases exist in addition to these. The table is open for your additions.

Validity and Integrity

There are at least three data integrity issues connected to the official data visualization using canonical (legally mandated?) visualization rules:

1. checking the validity of the visualization rules (are these rules official and not tampered with?) and
2. checking the validity of the data to visualize (is this data officially approved not tampered with?).
3. checking the validity and integrity of the final visualized product or layer

The both first and the second case are valid for external portrayal service providers. The authorities for the first issue in the meteorology context could be WMO and ICAO and a national weather service for the second issue. The third issue concerns the end-user client validation capabilities, and thus possibly out-of-scope of the OGC WS standards.

One technical way of dealing with these issues is using digital signatures, like W3C recommendation for XML Signature Syntax and Processing (XML-DSig). Assuming the visualization rules are defined as SLD/SE documents, the digital signatures of those documents may be provided by the mandating authorities as detached XML signature documents.

For the data validity issues it may be more convenient to include the signatures inside or attached to the actual data. This solution makes it easier to validate the data at any point in the data delivery or presentation chain as both the data and the signature to check its integrity are directly available for processing.

For Feature data, this would mean including XML-DSig signature elements in the schema either by using wrapping signature elements around the signed Feature elements (enveloped signatures) or including the signature elements as properties in the Feature types (enveloping signatures). On the other hand, there are some strong arguments against signing XML content, because of the bit-volatile nature of XML. For these reasons, signing the data stored in a binary form may be more appropriate in some situations.

For Coverage data, the integrity checking is probably somewhat more difficult, as the data (grid) served as input to the portrayal process is in most cases only a subset of bigger data set approved by the publishing authority. In many cases it would be infeasible, if not impossible to validate the data subset provided as a result of a WCS query against the original data set.

Some image formats (JPEG 2000) allow including XML, in this case the digital signature data, inside the image format itself to provide or the end-to-end integrity validation of the portrayed data. XML-based vector graphic formats like SVG or KML could be signed using the XML-DSig.

The work already done by the OASIS Security Assertion Markup Language (SAML) community should be considered at least as a starting point for the MetOcean DWG work in the integrity and validity context.

-- IlkkaRinne - 08 Dec 2009

-- ChrisLittle - 21 Feb 2013