NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Roy,
The "everything is a feature" is just a variation of "every data
entity is an object" from object-oriented programming. When we first wrote
about this, about 1994, the idea was to get to the central paradigm of
geographic information and try to "build interoperability on common
conceptions." At some point this turned into a formal definition in ISO as
"a feature is an abstraction of a real world phenomena" which actually
caused more problems than it solved, since some phenomena are abstractions
not real world, and some features are abstractions of things that do not
exist yet.
Bottom line, for us, a feature is any object (in the software sense)
of interest to an application. We associate to it meaning by associating its
class to a class of concrete things (roads, rivers, sensors, acts of
observations), and by further describing it by giving it named properties
(or attributes if you're a little old school about it). The values of the
properties are generally represented by objects again, with their own
properties, operations, and semantics. In essence they are features also.
One of the most useful paradigms for property values is "function" as in
mathematical function. A function is a mechanism that associates to domain
elements of one type of value, range elements of another type of value. If
the domain is an interval of the real line, and the range is a spatial
coordinate system, then the function is a representation of a curve. If the
domain is piece of real estate described by a geometry (possibly with its
own representation in a coordinate system) to a set of spectral values, then
the function represents an image (whose type probably categorized by its
sensor's ability to collect spectral values). Functions from space or
space-time into values of any type are dubbed coverage-functions, and the
features which have at least one coverage-function property are dubbed
coverage.
Why did we do this? We could have used object - entity - thing or
any of a bunch of other words equally as well. We chose "feature" because it
did not have much of a technical meaning yet, and was already in wide use in
various types of GIS. We also needed a word that denoted "thing of interest"
which was not cumbersome. But most of all, we wanted a unifying concept
because we wanted to avoid the "narcissism of small differences" which leads
to a "class explosion" in object terms. Yes, different applications will use
features with different semantics, that is to be expected. But if they are
to use common mechanism for non-application semantics, they need a common
target concept to obtain interoperability.
We define (like we did in GML) a mechanism for expressing features
in a pretty general way, a way consistent with UML models, with OOPL models,
with SQL schemas, and with all XML schemas (in content not in format). Now
someone creates an application with his own feature schema (expressed in any
of these models or their equivalents), and we can easily map it to a GML
application schema and use any functionality based on GML to do
non-application specific things (store, marshal, unmarshal, transport,
etc.). Similarly with SQL (either Simple Features or the related ISO SQL/MM
Spatial with SQL 3), we define rules for moving from application specific
schemas of a very general type (everybody should know how to marshal in and
out of an SQL3 object-relational database), and we get loads of
interoperable functionality for free.
The "tools/data mismatch" you speak of it the old "semantic gap"
versus "application independence" discussions we had going first from
CODYSYL to SQL and then when we merged SQL with OODB to get SQL 3. Yes, some
things get stored differently from what is optimal for a particular
application, but what you buy with that suboptimality is the ability to
share data and then to share functions with other applications - the roots
of interoperability. If we have a perfect tool-to-data match, we have
tool-stovepipes and zero chance of reuse or interoperability between
applications or between disciplines. And, with today's machines and
software, the suboptimality is at worse only marginal with well understood
and optimized solutions (views in SQL, stylesheets in XML, etc.).
On the specific examples you cite, we could go deeper and note that
there is a lot of common mathematics in the time-series, temporal, and 3D
geometry, especially with you use differential geometry, worlds which would
benefit from common approaches, but that would require more than an early
morning email. John Evans is right, in that it is all tied up with
interpolation techniques. The new version of ISO 19107 will address some of
these issues, but it is still barely in draft yet.
Regards, John
-----Original Message----- From: wcs.rwg-bounces+john.herring=oracle.com@xxxxxxxxxxxxxxxxxx [mailto:wcs.rwg-bounces+john.herring=oracle.com@xxxxxxxxxxxxxxxxxx] On Behalf Of Roy Mendelssohn Sent: Thursday, May 10, 2007 6:57 PM To: p.baumann@xxxxxxxxxxxxxxxxxxxx Cc: wcs.rwg@xxxxxxxxxxxxxxxxxx; galeon@xxxxxxxxxxxxxxxx; rlake@xxxxxxxxxxxxx; John Evans; simon.cox@xxxxxxxx Subject: Re: [WCS.RWG] Coverage/Feature/Observation "concept minimization" (was Re: OGC Ottawa TC meeting highlights) Everything is a feature..... Hi Ben:So I actually got a little time to think, and I never was very fast and as an old fogey my brain is getting even slower, but....In an abstract sense, it may make sense that everything is a feature, but in a practical sense it will lead to a tools/data mismatch that is not efficient, and therefore I do not feel is a useful model.For example, in statistics the tools that you use if the data are iid are different than the tool you use if the data are a time series, and are different than the tools you use if the data is purely spatial, and these differ than from the tools for space- time, and multivariate time series, and multivariate space-time data. There is no one method works best under all situations. If all I know is that I am getting back is a feature, I know very little, and matching the feature to the tool will be difficult.Same with visualization tools - some are best for certain types of data, and no one is best for all types (GIS systems are crummy with dealing with time, or time/depth). Having data models that reflect the types of data that we have (or the types of data that will be returned) allows for the proper match.
-Roy
galeon archives: