NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi Kieran, As a result of presentations at earlier meetings and subsequent telecon discussions, I drafted an outline of key issues and ideas that have arisen: http://galeon-wcs.jot.com/WikiHome/GALEON%20Phase2%20Main%20Page/Unidata%20OGC%20Interoperability%20Day%3A%20Issuesand%20Ideas which includes your irregular grids among the primary high level dataset categories that need to be addressed: - Grids - Points - Station observations - Trajectories - Swaths - Radar volumetric scans - Irregular grids (as per coastal oceans modeling community) The draft also outlines the main steps of an action plan: 1. The CF-netCDF community comes to some agreement on the fundamental set of high-level dataset categories 2. Members of the CF-netCDF community define extensions to or profiles of the current CF conventions for each of the dataset categories. The result is that, over time, the community has well defined data models and clearly specified extensions for each of the categories. A central issue that must be addressed in each case is defining explicit semantics (and perhaps syntax) for specifying spatial location information. The CF community will have to address the difficult issues relating to CRS (Coordinate Reference System) definitions used in the formal georeferencing standards community. 3. Community members with expertise in ISO coverages, map the data model for each CF-netCDF extension into the ISO 19123 coverages model. The result of this effort is that each dataset category is mapped directly to an ISO standard coverage type. The standards community may have to extend some of their approaches to allow for what amounts to "parameterized" versions of the EPSG specs. 4. Determine whether and how each CF-netCDF extension and the corresponding ISO coverage type: - can be expressed as Scientific Feature Types in GML and - relates to the Sampling Feature Types of the OGC Observations and Measurements 5. Determine whether and how each coverage type can be delivered via standard service protocols, e.g.: - as features in GML (with binary encodings??) via WFS - as sampling features via SOS - as coverages via WCS In my view, this might be used as a first cut at the set of goals that George Percivall suggested is needed for GALEON. In the associated Action Plan outline, we actually have listed commitments from various groups to take on some of these tasks: http://galeon-wcs.jot.com/WikiHome/GALEON%20Phase2%20Main%20Page/Revised%20GALEON%202%20Action%20Plan It would be great to add your group to those working on the "irregular grids." As you note, those are some of the most challenging datasets for the CF conventions community as well as the coverages realm. -- Ben On Jan 4, 2008 3:58 PM, Peter Baumann <p.baumann@xxxxxxxxxxxxxxxxxxxx> wrote:
Dear Keiran, thanks for chiming in. Responses inline: Keiran Millard wrote: Dear Peter, Ben et al, I missed the teleconf today, but I really appreciated your classification document. I'd like to clarify something with the group on the scope of where we are going. Our key concern with WCS is not WCS *per se*, but the lack of standard serialisations for all the ISO coverages. Our main coverages (from numerical models) are 'irregular grids' and 'meshes' and our (corporate) lack of uptake of WCS as a technology is due to the fact that these aren't supported. I would like to support efforts to achieve some standardised encodings for other coverage types, but I'm not sure if this is the remit of this group. As far as I am aware OGC is planning support for irregular grids in GML, but there are no plans for meshes (?) I am aware that some groups are looking at NetCDF encodings for meshes, but this all seems to be below the radar. we do know about this requirement. The need for more general coverage types has been discussed, eg, at the last TC WCS meeting; the WCS group is aware of it and intends to address it. It's very much a matter of resources, hence your offer to participate is most welcome. On your last point (clients and servers) - I agree a key point; not just for visualisation clients but any processing client for the data from the server. I know this is something Andrew Woolf is also quite passionate about. Over many cups of coffee we have debated the concept of 'processing affordance' and how this can be implemented; our latest work looked at registries (Feature Type Catalogues - we were looking at Features) as a place to declare this relationship. Essentially "I am Feature X, these services exist that can deliver me and these services exist that can process me". This work was presented at the last OGC TC in the RWG by Kristin Stock. agreed, registries are a great place for additional semantics and some larger context. However, I believe that each service needs to be self-contained enough to be operated in a meaningful way on its particular semantic level. best regards, Peter Best regards Keiran
galeon archives: