-----
Original Message -----
Sent: Thursday,
May 10, 2007 5:56 AM
Subject: RE:
OGC Ottawa TC meeting highlights
Notwithstanding the current
interest in fully unifying the feature and coverage views
(through the
CRS generalization activity, for which the logical outcome is
CRS=FeatureType),
I believe
that feature, coverage, observation, catalogue can already be seen as merely
different views onto,
projections
of, or sections through, the underlying data soup.
There now
appears to be some agreement that a "feature" may have a property whose
value varies in some way "across" the feature,
for example
in time or space (see sub-clause 6.5.3 and Figure 4 of Observations and
Measurements
– OGC
05-087r4 http://portal.opengeospatial.org/files/?artifact_id=17038)
and that this value is a "Coverage" whose domain extent is the feature.
In the
proposed update to the SamplingFeatures clause (see OGC 07-002r1 http://portal.opengeospatial.org/files/?artifact_id=20934&version=1
)
this is
generalized further to allow variation with respect to non-spatial axes
inherent to the "feature" (see sub-clause 7.1 and Figure 2).
I've also
been thinking about the implications of this model in terms of service
composition:
For example,
if a feature type has a property with a coverage value, then a WFS
"GetFeature" request for such a feature
might use a
GetCoverage request to a WCS "cascaded" behind the WFS in order to
fully compose the response.
There are
some other similar interactions potentially implied by other SOS and
specialised WFS operations.
I had
presented this in the form of what George Percivall calls "your
horrible powerpoint picture"
a couple of
times in OGC forums mid last year (e.g. in the SWE WG at the Edinburgh
TC).
I think
George's main problem was that my "SOS" pattern put a WFS and WCS
behind the SOS,
instead of
vice-versa, which would match the idea of "observations" as being in
some sense "more primitive" that features.
However, I
still stand by that analysis, and I have now added a couple of other
variants,
based on the
"Sampling Feature Service" viewpoint, the "Domain Feature Service"
viewpoint, and the "just the data" viewpoint.
They are
still in horrible PPT-ML, pending Bryan helping me figure out how to
show it in UML,
and
definitely could use some refinement, but maybe time to share the ideas
… see attached.
Simon
Hi Ron & all,
conceptually I find myself comfortable with the idea of a coverage
being just a special case of a feature, while I also see the arguments
for the opposite view. Anyway, mathematicians like Ron can teach us how
unified concepts can be defined.
Practically I see that feature and coverage operations are
substantially different, and it makes sense to have different services
on features and coverages. WFS and WCS form two underpinning services,
catalog services a third one, somehow reflecting the long-standing
triad vector/raster/meta data.
Recently SWE has joined the arena, and I find it important and
interesting to make sure that SWE concepts are in sync with both
feature and coverage definitions (my superficial knowledge of the SWE
world makes me believe that sensor data see themselves sometimes to
features and sometimes to coverages, depending on data, purpose, and
daylight savings time).
_Ideally_ operations on similar data structures are compatible, at
least coherent (eg, sensor and coverage data subsetting). On the other
hand I consider it _essential_ that the structures are in sync across
specs (ie, coherent with whatever we put in OWS Common), otherwise I
don't see how we can achieve cross-standard interoperability: what if
two standards define and use "feature" differently, use "coverage"
differently...
cheers,
Peter
Ron Lake wrote:
Hi Ben:
I think this
is also an argument that SOS, WFS and WCS be thought of as variations
of one another – I think of a coverage server as a kind of WFS (even
more so for SOS).
Ron
From: Ben Domenico [mailto:bendomenico@xxxxxxxxx]
Sent: May 8,
2007 9:54 AM
To: Ron Lake
Cc: Roy
Mendelssohn; Unidata GALEON
Subject: Re: OGC
Ottawa TC meeting highlights
Roy and Ron,
Much of the earlier discussion was spawned by AGU talks by Andrew Woolf
(on CSML "scientific feature types") and Simon Cox (on sampling
feature classes -- among many other things). These bear a strong
resemblance to John Caron's Common Data Model "scientific data types."
For me, the use case that really makes this interesting is the
collections of point/station observations over time that are common in
atmospheric science (weather stations), oceanography (buoys, etc.), and
hydrology (river gaging stations).
It should be noted that work is currently underway to provide netCDF
conventions for such observations. See:
http://www.unidata.ucar.edu/software/netcdf-java/formats/UnidataObsConvention.html
Assuming the simplest case of a fixed set of observing stations taking
measurements over time, one can argue that those are classic examples
of "traditional" point FEATURES. On the other hand, if you view the
collection as a whole as a "dataset," it has many similarities to the
gridded datasets we normally think of as COVERAGES. It's just that,
for the station observation collections, the locations of the points
are completely irregular and are specified in a table of some sort
rather than via a geometric algorithm or an indexed vector.
Given such an observation convention for netCDF, this becomes an
important issue in GALEON. Should such collections of station
observations be delivered as coverages? Or should they be delivered
via WFS or SOS? My answer to those questions is an emphatic "yes!"
In other words, I don't see it as an either/or question. If the
datasets are available via all three protocols, then the clients for
all those protocols have access to the data. Moreover, from the server
side, if we at Unidata use the THREDDS Data Server to provide the data
as netCDF-encoded coverages via WCS, the experts in WFS and SOS can
provide services that transform those datasets into the appropriate
form for their client community. Using web services and standards in
this manner, it means we can all focus on the components where we have
the expertise. Isn't that the idea behind web services
interoperability?
-- Ben
On 5/8/07, Ron Lake <rlake@xxxxxxxxxxxxx>
wrote:
HI Roy:
I would say you are both "right"
You are thinking of feature as a vector object - this is not the
definition in the OGC nor in the ISO. I think we need a word for this
vector feature or conventional feature - but we currently don't have
one. Feature in OGC and ISO means the object of interest in the domain.
It is in this sense that a coverage is a feature. Now in the sense of
features as vector objects (the more restricted meaning you are using)
one might have properties which are coverage valued or which varying
over some geometry of the feature.
Cheers
Ron
-----Original Message-----
From: owner-galeon@xxxxxxxxxxxxxxxx
[mailto:owner-galeon@xxxxxxxxxxxxxxxx]
On Behalf Of Roy Mendelssohn
Sent: May 8, 2007 8:39 AM
To: Ben@xxxxxxxxxxxxxxxx
Cc: Unidata GALEON
Subject: Re: OGC Ottawa TC meeting highlights
On Apr 30, 2007, at 8:41 AM, Ben Domenico wrote:
> The underlying unifying concept is that a "coverage" is in fact a
> special case of a "feature" and ncML-GML and CSML dialects of GML
> can provide the needed "wrapper."
>
I think this is backward. I like the approach Simon Cox takes in the
talk he gave at AGU last December, where a coverage is a feature that
varies over one of its coordinate axes. Thus a feature is a
"collapsed" coverage, not the other way around. If feature gets to
be defined that broadly it loses all meaning.
-Roy
**********************
"The contents of this message do not reflect any position of the U.S.
Government or NOAA."
**********************
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
1352 Lighthouse Avenue
Pacific Grove, CA 93950-2097
e-mail: Roy.Mendelssohn@xxxxxxxx
(Note new e-mail address)
voice: (831)-648-9029
fax: (831)-648-8440
www: http://www.pfeg.noaa.gov/
"Old age and treachery will overcome youth and skill."
========================================================================
=======
To unsubscribe galeon, visit:
http://www.unidata.ucar.edu/mailing-list-delete-form.html
========================================================================
=======
--
Dr. Peter Baumann
- Professor of Computer Science, Jacobs University Bremen*
*formerly: International University Bremen
www.faculty.jacobs-university.de/pbaumann
, mail: p.baumann@xxxxxxxxxxxxxxxxxxxx
tel: +49-421-200-3178, fax: +49-421-200-493178
- Executive Director, rasdaman GmbH Muenchen (HRB 147737)
www.rasdaman.com, mail: baumann@xxxxxxxxxxxx
tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"A brilliant idea is a job halfdone."
