Steve,
In my experience, the fact has always been that OGC working groups were
dominated by the folks who had a particular interest in some aspect of
the topic thereof, championed it, and shepherded it along its way.
Even in some of our rather broad groups, now, (SensorML/SWE), although
there's broad agreement that there's benefit in ocean observations, the
key focus remains based on the satellite (imagery) origins of SensorML.
I view the new Meteorological working group as a healthy start,
however. I can see membership in that WG from both atmosphere and ocean
scientists seeking to gain interoperability. And with a cohesive base,
we can help drive other changes (CRS, datum agreement, acceptable units,
etc.), consistent with the needs of the Atmo/Ocean community specifically.
This isn't a slight on OGC, its makeup, nor its members. It's
recognition of reality, and that reality includes the fact that
discipline science is becoming more vocal in the need for
interoperability. Recall that essentially, the origins of OGC reside in
GIS. GIS interoperability took years to actually realize, and is still
mutating. AND, GIS is, in reality, 2D-based, although a lot of folk
have started realizing that 2D maps don't well serve a 3D world... and
things are changing.
I think David captured the essence of getting things moving.
Count my voice in, too.
gerry
Steve Hankin wrote:
Hi Ben,
Publicly adding my voice to the chorus of endorsements for this idea ...
or at least for some serious exploration of it.
Worth mentioning also the context: that David Arctur suggested this goal
might be accomplished by spinning up a new working group (say, "Fluid
Earth Systems"?). David's outlooked seemed radical to me in the sense
that he seemed to imply there was in fact not such a coordinated OGC
outlook on interoperability. The apparent outlook, he seemed to be
saying, was merely a reflection of who was strongly participating in the
process. I wonder if a part of the significance of creating a new OGC
working group might be to recruit additional membership from within our
own FES community and thereby to grow a more sizable OGC subcommunity
that shares our view that a 3D space-time, continuous coordinate system
framework needs to lie at the foundation of interoperability.
- Steve
Ben Domenico wrote:
Hi,
At the US IOOS (Intgrated Oceans Observing System) DMAC (Data
Management and Communications Subsystem) Steering Team meetings last
week, a topic with important GALEON implications came up. Please note
up front that this is all very tentative at the moment and very much
in the "investigation" stage. But, with the next OGC Technical
Committee meeting coming up in June, we should begin considering the
pros and cons and other implications.
David Arctur of the OGC suggested that we submit the CF-netCDF
directly as an OGC standard. As I understood his suggestion, the
general idea would be that CF and netCDF would be for binary data what
GML and XML is for text data. To me this was a very innovative (if
not radical) suggestion and questions arise whether this would involve
the file format, the API, ncML, ncML-GML, CSML and possibly other
facets related to CF-netCDF. In spite of the question marks, I think
this is really worth some careful thought. Since the concept was so
new to me, I asked David if there were any precedents that might serve
as a template for how we might proceed. In response, he sent a list
(appended below without any implied endorsement) which includes
specification examples for file formats and for the APIs.
Fascinating idea.
.
-- Ben
=============================================
Geographic Objects (GO-1) - this is a fine-grained API pushed by a
federal agency, very little uptake, but it's an API that became an OGC
standard.
http://www.opengeospatial.org/standards/go
KML 2.2 - see what they did.
http://www.opengeospatial.org/standards/kml
Simple Feature Access, Part 1: Common Architecture - this is an
interface with different platform-specific encodings (COM, CORBA) and
SQL access (see next two references for the most used platforms)
http://www.opengeospatial.org/standards/sfa
Simple Feature Access, Part 2: SQL Option
http://www.opengeospatial.org/standards/sfs
Simple Features for OLE/COM
http://www.opengeospatial.org/standards/sfo
OGC Reference Model (ORM) -- this is the roadmap for OGC standards
evolution and maturation; in your proposal for CF/netCDF describe how
it fits in the roadmap.
http://www.opengeospatial.org/standards/orm (pdf & doc downloads from
this page)
Best Practices - index page (includes next two references below)
http://www.opengeospatial.org/standards/bp
Binary XML (BXML) Encoding Specification, OGC 03-002r9 (Craig Bruce,
CubeWerx)
http://portal.opengeospatial.org/files/?artifact_id=13636
Specification Best Practices, OGC 06-135r1 (Carl Reed) - This document
describes a variety of Best Practices and Specification development
guidance that the Members have discussed and approved over the years.
These Best Practices have not been captured in other formal OGC
documents other than meeting notes.
http://portal.opengeospatial.org/files/?artifact_id=17566
------------------------------------------------------------------------
_______________________________________________
galeon mailing list
galeon@xxxxxxxxxxxxxxxx
For list information, to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
------------------------------------------------------------------------
_______________________________________________
galeon mailing list
galeon@xxxxxxxxxxxxxxxx
For list information, to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
