NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
HI, See comments inline. Ron
From: galeon-bounces@xxxxxxxxxxxxxxxx [mailto:galeon-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John Graybeal Sent: October 7, 2008 12:03 PM To: Ben Domenico Cc: Unidata GALEON Subject: Re: [galeon] Features and Coverages Ben's clarification from O&M also helps minimize or avoid a possibly approaching train wreck. The initial definition was feature: just a geographic thing the next definition was feature: abstraction of real-world phenomena (so it is no longer the physical thing, just the abstraction), and the discussion after that suggested to me feature: a digital artifact, possibly with associated digital services and attributes.
I would say a feature can be quite abstract like a political boundary, congressional district as well as being some physical thing. I think it can also be a phenomenon or process. I think the idea of having identifiers for real world things is ESSENTIAL and a key missing bit in most of our discussions of information infrastructures. Gazetteers are starting points, but are usually very restrictive. We often have no way to say that two computer representations are about the same real world entity. Only a published registry of identifiers can make that possible. The distinction between a data structure and a feature seems pretty slippery. I would say any data structure that has application meaning is a feature. Coverages describe the variation in space/time (or other domain) of some property or quality. I personally think the Space/time aspect of this is paramount - since even in cases where we have other domains (say pressure) we usually want to know that two measurements were or were not taken at the same time/place EVEN if we do not know what that time/place is. This seems pretty intrinsic to physical phenomena.
Since in many standards the term 'feature' or similar is (arguably) referring to the thing being observed, and is referenced by a URI that names that physical entity, it will be helpful to keep the following concepts distinct: a) the real-world entity (this would be something wet, for example) b) a URI-style or other computationally usable reference to that real-world entity (this is just an identifier), and c) an abstraction of this (or any) real-world entity that lives in a model or computer program and describes the entity
I think the fact that an observation may be targeted to the obtaining one or more properties of a feature is more a mission objective. I don't think it is an intrinsic part of the observation itself. It may even be more important to connect the features back to the observations on which they are based. Sometimes such a feature of interest is known at observation time (and their may be MANY such features of interest), but sometime it is not known until much later on, even long after the observation.
Things like points, lines, areas, and volumes seem to be solidly in the third category.
I tend not to think of geometry (or time) as features since they have in themselves no application meaning - they describe properties of features. Features of interest seem solidly in the first category, until you have to refer to them with a 'name', then the name itself is in the second category. (There is a long list of possible definitions of the term in the Oceans IE report submitted to OGC, 08-124 if you have access; list is appended below). Coverages and sampling features also are of the third class, though possibly containing reference to an actual entity by location or name.
I apologize if I didn't get those divisions exactly right, but I'm sure at least these 3 concepts usefully co-exist.
galeon archives: