RE: GALEON OGCnetwork

NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.

See comments in-line.


Ron

From: Simon.Cox@xxxxxxxx [mailto:Simon.Cox@xxxxxxxx]
Sent: April 9, 2006 7:42 PM
To: Ron Lake; Ben@xxxxxxxxxxxxxxxx; galeon@xxxxxxxxxxxxxxxx
Cc: mbuehler@xxxxxxxxxxxxxxxxxx
Subject: RE: GALEON OGCnetwork

Comments on two aspects of this:

1. Metadata

The GML 3.1 and earlier treatment of metadata - using the
gml:metaDataProperty element - turned out to be rather too
onerous/tricky for the developers of application schemata where they
wanted to use an existing metadata schema, which is not derived from
GML.

The GML pattern required a GML "wrapper" for eveything, in addition to
the metaDataProperty element.

After going around the issue a few times, the GML 3.2/ISO 19136 approach
was to instead add a "flag" that may be shown on any property element to
indicate that it is metadata.

So I would not recomment designing anything now on the basis of the GML
3.1 patterns since they will be superseded in GML 3.2.



Since the usage in coverages is metadatalink - i.e. is a URI reference -
this comments does not apply since the metadataproperty with a reference
can refer to anything and the wrapper issue does not arise.

2. coverage "domain".

I have discussed the matter of generalizing the coverage domain with the
ISO 19123 editors and others.

The story I got was that the ISO Coverage model is specifically *not* a
general purpose map.

It is specifically a map with a spatio-temporal domain, because the
intention is to target spatio-temporal processes and processing.

Of course everyone recognises that Coverages defined in this way are
simply special cases of general maps.

So the questions I thinka re raised by this discussion are

(i) is the GML implementation of Coverage canonical?

(ii) should WCS be modelled as a special case of a "map" or "function"
service?

It is really NOT a question of generalizing the domain at all.  Physical phenomenon are 
fundamentally described by functions from space-time to what is typically some multi-dimensional 
vector space (or multi-"dimensional" product set).  In many cases one can ignore or 
factor out the spatial/temporal dependence but the coverage model remains useful nonetheless.  
Consider for example the case of Temperature, Pressure, Altitude, Density as obtained from a 
weather balloon. The data samples can be seen as a coverage with Temperature, Pressure, Density in 
the range and Altitude or Altitude, Time in the domain.  Now it may be that I don't want to 
consider the altitude at all - so I provide you a set of (Temperature, Pressure, Density) values 
which were obtained at the same location (Altitude) and time (or which for the purposes of our 
model were so.  The "grid" of values (three values per grid point) is now just an array - 
no spatial location associated to it - and can be transported as a GML GridCoverage.  The fact that 
one might want to look at this data as Temperature and Air Density as functions of Air Pressure is 
up to the consumer and does not need to be in the encoding UNLESS we want to provide some sort of 
interpolation formula.

Cheers
Ron



  • 2006 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the galeon archives: