NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
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
-----Original Message----- From: galeon-bounces@xxxxxxxxxxxxxxxx [mailto:galeon-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Luis Bermudez Sent: March 14, 2008 3:10 AM To: <Simon.Cox@xxxxxxxx> Cc: galeon@xxxxxxxxxxxxxxxx Subject: Re: [galeon] Fwd: CDM feature and point types docs Hi Simon,So my sense is that we need best practice documents regarding how interpret in different ways an observation, and how the realization of these observations could allow communities to interoperate. I don't think what you said is very clear from the public specification. But it is getting clear everyday :)One more comment: Isn't the sampling strategy part of the observing procedure ? - Luis
galeon archives: