Hello all
There is some more notes on the OGC meeting:
The Meteo-Ocean group announced the completion of the creation of
meteorological symbols available as SVG files. They are going to be
published on GitHub (among others). Johann Sorel has demonstrated in
2010 the feasibility of using such symbology in a Web Map Server (WMS).
This work has been mentioned in the OGC meeting :-) and is part of the
code that we would like to port to SIS. Symbology for aviation may be
added later.
The Meteo-Ocean group is finalizing a "Best practice" paper, hopefully
to be published around March. The main content of this document is
recommendations about usage of vertical and temporal axes in WMS
requests. For example keeping in mind that meteorological data typically
have 2 time axis (one for time of the forecast, and one for the time
when the model has been run), while many meteorologist specialists look
at the "run time" first, acknowledging that non-specialist users will
want to look at "forecast time" first, the document recommends (among
other recommendations) to use the later one as the default time axis.
The Coordinate Reference System (CRS) Well Known Text (WKT) group
started the work for a WKT 2.0 format. There is a long list of issues
with the current WKT format [1], which is understood in different ways
by different implementors. In what-will-be-SIS, we try to handle that
with an enum specifying whether we are parsing an ESRI or GDAL or Oracle
etc. format [2], but the actual list of issues is much longer than that.
They were a discussion about whether WKT 2.0 shall be
backward-compatible with WKT 1.0. Some pushed hard for compatibility.
They were a discussion about the character encoding. I will try to make
sure that the standard accepts Kanjis, Hiragana and similar characters.
An other interesting point mentioned is that European legislation
mandates usage of ETRS89, not WGS84, for international maps over Europe.
So standard and software shall avoid to give special role to WGS84 (e.g.
the TOWGS84 keyword in the WKT format is problematic).
The Sensor Web group reported various experiments. Not surprisingly,
parsing of inefficient file formats was identified as one of the most
important cause of CPU and batteries consumption.
Martin
[1]
http://www.geoapi.org/3.0/javadoc/org/opengis/referencing/doc-files/WKT.html
[2] http://www.geotoolkit.org/apidocs/org/geotoolkit/io/wkt/Convention.html
