RE: OGC Ottawa TC meeting highlights

["Mike Botts" <mike.botts@xxxxxxxxxxxxx>]

Ben et al.

 

If you want to look at encoding large coverages in GML, I strongly suggest that you look at the SWE Common approach for defining the data structure and encoding and then packaging the data values into ascii, base64, or true binary blocks. This is available in the SWE Observation schema, but could be used for any Feature. Efficient packing and rapid parsing of large blocks of data are the resons we developed this approach.

 

You can find some examples within the SWE Common encoding and examples section of the SensorML document (OGC 07-000).

 

Thanks.

Mike Botts

 

------------------------------------------------------------------------------------

Mike Botts, Ph.D.                           mike.botts@xxxxxxx

Principal Research Scientist            http://vast.uah.edu

NSSTC                                         

University of Alabama in Huntsville   (256) 961-7760

Huntsville, AL 35899 USA               (256) 652-0165 (cell)

------------------------------------------------------------------------------------

 

 

---

From: owner-galeon@xxxxxxxxxxxxxxxx [mailto:owner-galeon@xxxxxxxxxxxxxxxx] On Behalf Of Ben Domenico
Sent: Friday, May 11, 2007 8:02 AM
To: Simon.Cox@xxxxxxxx
Cc: rlake@xxxxxxxxxxxxx; creed@xxxxxxxxxxxxxxxxxx; p.baumann@xxxxxxxxxxxx; Roy.Mendelssohn@xxxxxxxx; galeon@xxxxxxxxxxxxxxxx; gpercivall@xxxxxxxxxxxxxxxxxx; rsingh@xxxxxxxxxxxxxxxxxx
Subject: Re: OGC Ottawa TC meeting highlights

Hi all,

From my point of view, this has been an excellent and 
productive discussion in a topic area that I've found difficult to fathom since 
I became involved in the OGC.  But, it's been very far reaching and I'd 
like to propose that we break it up into sub-topics that might fit better into 
different email lists and discussion groups. 

1. GALEON I.E.: Since the 
discussion started in the GALEON context, I'll start with my idea for the GALEON 
topics that fit in as part of an interoperability experiment: 

-- 
Starting with the kinds of CF-netCDF coverages we worked with in GALEON 1, does 
it make sense to represent those coverages in GML encodings such as ncML-GML, 
CSML?  Given that approach, is it practical to represent all the data in 
the GML or should the payload still be binary encoded in CF-netCDF or perhaps 
GML-JP2K?  And given that approach, should the data be served via WFS as 
well as WCS? 

-- For collections of stations observation data taken over 
time (time series of data taken at a large number of fixed points in space, such 
as weather stations or river gaging stations), does it make sense to represent 
those as discrete grid point coverages?  If so, how should they be encoded 
and served? 

To me these are important areas of practical experimentation 
for GALEON 2 and I plan to put them onto the agenda for our next GALEON 
telecon.

2. OCEANS I.E.: The issue of the relationship between the 
coverages of GALEON  1 and SWE/SOS could be addressed as part of the Oceans 
interoperability experiment.  Certainly the output of weather forecast 
models is of interest to the ocean sciences.  Can the CF-netCDF encoded 
coverages of such datasets be served via SOS to that community of clients?  
My respectful suggestion is that the Oceans I.E. consider this as a part of the 
experiment.  Since I'm part of the Oceans IE, I'll see if there's time to 
broach the subject at that telecon later this morning.

3. 
ARCHITECTURE?:  Much of the theoretical, abstract level discussion of what 
are the fundamental data objects we are dealing with and how the data and 
metadata access protocols relate to one another seems to me to be a question of 
overarchihng architecture and should be taken up there.  But, since I'm not 
part of that group, I leave it to others to decide how to move forward on those 
issues.  Of course, these abstract discussions will be grounded by the 
practical experiences gained in the interoperability experiments. 

4. 
OTHER: Aspects of the interaction have touchs on topics that relate to coverages 
in general, catalogs, etc. and one hopes those facets of the discussion will be 
carried to the appropriate working groups so that we can all continue our 
focussed efforts while remaining aware of the bigger picture issues of how our 
work fits with that of others. 

Many thanks to all for a wonderful 
discussion.  I hope it continues to flourish as a set of lively 
interactiions on the sub-topics as well as a set of practical implementations 
and experiments for each of the key components. 

I should add that I have 
no real objection to continuing the interactions here, but I'd like to make sure 
that some of these specific topics be taken up in the appropriate 
groups.

-- Ben

On 5/10/07, Simon.Cox@xxxxxxxx <Simon.Cox@xxxxxxxx> wrote:

Oh – I probably should also have noted

(a)     we could characterize the GIS community as "the domain of discourse that cares about TGFs"; i.e. TGF is the set of feature-types defined within the traditional GIS community

(b)     the "different names" for different services could be "WCS", "SOS" etc or  "Coverage profile of Generic Feature Service" and "Observation Profile of Generic Feature Service", etc, with the understanding that "profile" allows for query-model optimisations as well as response-model forms.

Simon

______
Simon.Cox@xxxxxxxx  CSIRO Exploration & Mining
26 Dick Perry Avenue, Kensington WA 6151 PO Box 1130, Bentley WA 6102  AUSTRALIA
T: +61(8) 6436 8639  F: +61(8) 6436 8555 Cell: +61(4) 0330 2672
<http://www.csiro.au>
< http://maps.google.com/maps/ms?msa=b&z=18&ll=-31.994,115.886&spn=0.0065,0.01&t=k>

(UK Cell: +44 78 161 67135)

ABN: 41 687 119 230

---

From: Cox, Simon (E&M, Kensington)
Sent: Friday, 11 May 2007 10:37 AM
To: Ron Lake; Carl Reed OGC Account; p.baumann@xxxxxxxxxxxx
Cc: Ben@xxxxxxxxxxxxxxxx; Roy.Mendelssohn@xxxxxxxx; galeon@xxxxxxxxxxxxxxxx; gpercivall@xxxxxxxxxxxxxxxxxx; Singh, Raj
Subject: Re: OGC Ottawa TC meeting highlights

 

Ron - Actually I don't "see it the other way around" - please take a look at my slides and you will see that I show examples of WFS fronting SOS, and of SOS fronting WFS, and also various interactions with Registers and WCS. It all depends which viewpoint you need. They all have their time and place. And many configurations are possible in a SOA - that is kinda the point. I like George's recent architecture diagrams where he has dispensed with arrows between components altogether, in favour of a background that contains pervasive arrows!

 

John - yes, you caught me - in this thread I slid back to the "traditional geospatial feature" usage of the term "feature". In other contexts I have been one of the first to emphasize that "feature" is not restricted to this. My current formulation is "identifiable thing whose type is defined in some community or domain of discourse". Yes, that certainly includes all the concepts that you mentioned (licenses, schemas, etc).

 

Nevertheless, the notion of "traditional geospatial feature" (lets call it TGF) (I won't even attempt to define it here) appears to have some utility, and least as a viewpoint, which resonates with a lot of folks. Maybe we need another word for it. In the slides, in the slides attached to the mail I sent yesterday, the "WFS" components refer to a TGF-service.

 

I fully agree that a true "Feature-service" would be the parent of all more specialized services, including coverage services, TGF-services, etc, which could be understood as profiles that provide access to some viewpoint related to convenience packaging. Like the simplified packaging-oriented info models, the service profiles are still useful - different communities with different focusses understandably find one more convenient than another, at least at different stages in their workflow. So it is probably useful to give these services different names.  

 

Simon

----- Original Message -----

From: Ron Lake

To: Carl Reed OGC Account ; Simon.Cox@xxxxxxxx ; p.baumann@xxxxxxxxxxxx

Cc: Ben@xxxxxxxxxxxxxxxx ; Roy.Mendelssohn@xxxxxxxx ; galeon@xxxxxxxxxxxxxxxx ; gpercivall@xxxxxxxxxxxxxxxxxx ; Singh, Raj

Sent: Friday, May 11, 2007 12:52 AM

Subject: RE: OGC Ottawa TC meeting highlights

 

HI,

 

I think if we see the request for a feature which has a coverage-valued property as a need for service composition with one fronting the other – but without a clear semantic difference in their roles – then we are saying really that the WCS is a specialization of WFS (I would argue this is true also for SOS – I know Simon sees it the other way around) – the proposed service chaining is then more a migration strategy than things as they should be.

Ron

 

---

From: Carl Reed OGC Account [mailto: creed@xxxxxxxxxxxxxxxxxx]
Sent: May 10, 2007 9:41 AM
To: Simon.Cox@xxxxxxxx; p.baumann@xxxxxxxxxxxx; Ron Lake
Cc: Ben@xxxxxxxxxxxxxxxx; Roy.Mendelssohn@xxxxxxxx; galeon@xxxxxxxxxxxxxxxx; gpercivall@xxxxxxxxxxxxxxxxxx; Singh, Raj
Subject: Re: OGC Ottawa TC meeting highlights

 

Simon -

 

Now you really got me thinking. The core-extension spec pattern dialogue has bothered me in some sense in that there is a more fundamental issue in the standards work of the OGC - there is no foundation model or architecture that describes how the various OGC specs fit together in a consistent and logical manner. This includes not having a consistent information model.

 

I believe that you have put your finger on exactly the same issue except that you have also gone one step farther and provided an initial reference model for discussion.

 

I believe until we can agree on such a model (architecture?), we will continue to be plagued with a variety of semantic issues, inconsistencies in our specs, confusion in the market as to how they all fit together, and so forth.

 

Let's definitely keep this discussion going!

 

Regards

Carl

 

----- Original Message -----

From: Simon.Cox@xxxxxxxx

To: p.baumann@xxxxxxxxxxxx ; rlake@xxxxxxxxxxxxx

Cc: Ben@xxxxxxxxxxxxxxxx ; Roy.Mendelssohn@xxxxxxxx ; galeon@xxxxxxxxxxxxxxxx ; gpercivall@xxxxxxxxxxxxxxxxxx ; creed@xxxxxxxxxxxxxxxxxx

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

______
Simon.Cox@xxxxxxxx  CSIRO Exploration & Mining
26 Dick Perry Avenue, Kensington WA 6151 PO Box 1130, Bentley WA 6102  AUSTRALIA
T: +61(8) 6436 8639  F: +61(8) 6436 8555 Cell: +61(4) 0330 2672
<http://www.csiro.au>
< http://maps.google.com/maps/ms?msa=b&z=18&ll=-31.994,115.886&spn=0.0065,0.01&t=k>

(UK Cell: +44 78 161 67135)

ABN: 41 687 119 230

---

From: owner-galeon@xxxxxxxxxxxxxxxx [mailto:owner-galeon@xxxxxxxxxxxxxxxx] On Behalf Of Peter Baumann
Sent: Wednesday, 9 May 2007 1:48 AM
To: Ron Lake
Cc: Ben@xxxxxxxxxxxxxxxx; Roy Mendelssohn; Unidata GALEON
Subject: Re: OGC Ottawa TC meeting highlights

 

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."