Yes, thank you very much for all of the wonder write-ups you have provided those of us who couldn't be there. I have a couple questions though.
1. All the metadata "formats" still seem to favor XML. Was there any mention of serializing to JSON instead? 2. Apache Tika is really good stuff and there is some ongoing work to get Tika working with GDAL via @jwhite. Any thoughts on that integration? Thanks! Adam On Jan 18, 2013, at 1:17 AM, Mattmann, Chris A (388J) wrote: > Hey Martin, > > On 1/17/13 3:59 PM, "Martin Desruisseaux" > <[email protected]> wrote: > >> 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. > > That sounds great. Demos and real things we can show with SIS (like > oceanography examples) would be great! > >> >> 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. > > For this we can leverage Apache Tika for encoding detection and language > detection. > Thoughts? > >> >> 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). > > Very interesting... > >> >> 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. > > That is crazy -- they should be looking at Apache Tika ;) Thanks for the > detailed report, my friend. > > Cheers, > Chris > >> >> Martin >> >> [1] >> http://www.geoapi.org/3.0/javadoc/org/opengis/referencing/doc-files/WKT.ht >> ml >> [2] >> http://www.geotoolkit.org/apidocs/org/geotoolkit/io/wkt/Convention.html >> >
