Re: [galeon] Fwd: CDM feature and point types docs

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

My point was that for most of marine and atmospheric science the
"meaningful entities in the domain" ARE points, profiles, trajectories,
sections, grids etc. No more, no less.

Of course they can be cast in an Observations framework - after all
there is an instrument (XBT, CTD, radiosonde, wind profiling radar)
measuring a property (temperature, salinity, wind) of the feature (with
a coverage result) - but the feature is a 'Profile'.

(This is exactly what we do in CSML.)


-----Original Message-----
From: galeon-bounces@xxxxxxxxxxxxxxxx [mailto:galeon-
bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ron Lake
Sent: 14 March 2008 16:25
To: Luis Bermudez; Simon.Cox@xxxxxxxx
Cc: galeon@xxxxxxxxxxxxxxxx
Subject: Re: [galeon] Fwd: CDM feature and point types docs

Hi Gerry et al:

I think part of the problem is a misunderstanding of the OGC as taking
geospatial concepts and applying them elsewhere.  Nothing could be
further from the truth.  OGC has been much more about deriving and
applying appropriate abstractions that are intended to be common to many
domains.  It began by looking at traditional geographic information as
in mapping but quickly was extended to other "real" domains, because
there is really no such thing as a geospatial domain.  The whole
approach to observations for example has its roots in measurement theory
from people like Luce and Fowler who had nothing to do with anything
geospatial.

The notion of feature (read application object) is key point in all of
this. In the early days of computing, the word data referred to the
available abstractions - the numeric or text etc values that could be
stored and moved about.  What these values really meant was not captured
in the computing system.  This was true in all areas of
science/engineering (I spent more than a decade in research automation
for wind tunnels), mapping, surveying, computer aided drawing/design,
etc etc.
As people began to share information between machines it was of course
initially very bottom up since that was the available representation and
the machine resources could not cope with anything else.

In the early 80's it began to become clear that a deeper representation
of things was needed - not only to share information across domains but
even to make it more generally possible to share information between
programmers/users in one domain or even in one enterprise. This rise of
the object oriented viewpoint, changed the meaning of the word "data"
from simple primitive types to objects - things that model as closely as
possible what we are doing and talking about.  This modeling approach
had of course actually started earlier in the world of databases, but
until the 1980's the idea of transporting these models about was not in
the cards.

Today we see the world in terms of objects, entities or features - and
much of the OGC is concerned with what are the appropriate such things
for a given domain or class of domains.  This is not a geospatial
viewpoint.  It is more that of knowledge engineering.

It is worth noting that the world of building/structure design (computer
aided design) has been going through a similar transformation to the one
being discussed.  CAD started as noted above with a focus on geometric
primitives - points, lines etc. Soon, however, it became clear that to
exchange this information with others in a design team - one needed to
know what these things meant - that this line was the edge of a door,
that the door was made of wood etc.  Gradually (and I would say the
transformation is not at all complete) this meant switching the
representation so that we start with meaningful entities in the domain
(like door, wall etc) and then describe these things in terms of
geometric and other characteristics.  This is the point of the Building
Information Model (BIM) which has been making a lot of noise these days
and is of course leading to the possibility of CAD/GIS integration in a
meaningful way.

I think this same thinking is behind the modeling of observations and
was the origin of my comment that triggered this discussion.

In very crude terms it is something like:

<Point>
        <temperature>30</temperature>
        <coordinates>50,20</coordinates>
</Point>

vs

<Observation>
        <location>
                <Point>
                        <coordinates>50,20</coordinates>
                </Point>
        </location>
        <result>
                <temperature>30</temperature>
        </result>
</Observation>

Cheers

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