Hey Jody and everyone else,
On Mon, 2005-10-10 at 01:18 -0700, [EMAIL PROTECTED] wrote:
> If you are listed by name below you are part of this bigger picture I am
> trying to pull together.
What's the picture about? The future of geotools? The consequence of the
current feature model?
I'm sorry but I didn't get the overall intent of your email.
> Feature Versioning
> ==================
> Adrian and Dave Blasby, one of the things that occured last week (in an IRC
> session posted to the UDig site so you may have missed it) was that Adrian
> was
> sending us right back to the origional OGC Feature Model. That is before it
> was cleaned up a limited in scope for things like "Simple Feature Model", or
> GML2 (or GML3).
>
> James has given me a target of GML3 (at least the Level 0 Profile part), this
> is also the target of Gabriel.
>
> Adrian and Dave - you have a different problem in mind. I would like to
> confirm that we are not painting you into a corner. Dave I am under the
> impression that you would like to build Feature Versioning "on top" of a data
> store infrastructure as a separate concern. Is this still your plan ... it
> would be great if you could talk to Adrian who has similar concerns.
>
> Adriand you were worried about Feature extending Attribute. Part of the fun
> is
> that you have a slightly different impression of what Attributes are then
> that
> OGC document I pointed you towards. I am waiting to hear back from you on
> your
> revised understanding....
A feature is *not* an attribute. In English, an "attribute" is a
characteristic of (or attributed to) something. In GIS speak, an
attribute is a value related to a feature. In OGC speak, an attribute is
a set {name, type, value, and optionally a descriptor} related to a
feature. A feature can have "attributes" but it is not one. If a feature
were an attribute, what would it be an attribute of?
The 'Attribute.java' interface in Geotools defines a structure holding
references to both a value and a descriptor ("type") of that value. I
would call it a "TypedEntity" or a "TypedProperty", an element which
holds references to a type and to an entity. Certainly, both Features
and Attributes as well as Geometries and lots of other elements within
the Geotools world could implement this interface to state that they
fundamentally pair a value and a descriptor. "Attribute" is a poor word
for that pairing because it indicates singularity not duality and
because it suggests dependence on something external when none is
intended. I don't see anything in the OGC document that suggests that a
feature be an attribute. OGC Reference Model p.9 "Any feature may have a
number of attributes, some of which may be geometric and spatial" p11,
element5 "They [features] are comprised of one or more attributes..."
Where my use of "attribute" differs from the OGC's is that they consider
any TypedProperty of Features to be "attributes" whereas I have only
ever seen the word used for the specifically non-temporal, non-spatial
data associated to a feature. For the OGC a Feature contains an array of
Attributes, whereas for me it contains a temporal definition, a spatial
definition, and an array of Attributes which are non-temporal and
non-spatial. I'm quite willing to live with this OGC nomenclature since
apparently it's helpful to you all to parse all the attributes of
Features as one unit.
For me personally, I like to keep the temporal, the spatial, and the
'non-temporal,non-spatial' elements separate. I find it helps me think
about what is or is not really a 'spatial analysis' as against a
non-spatial analysis done in lots of different places. The distinction
also helps me identify what is a characteristic of the feature versus a
characteristic of the feature's 'non-temporal,non-spatial' attributes.
This is especially useful where you need to distinguish a temporal or a
spatial property of the "attribute" but *not* of the feature. For
example, a feature "London" can have an attribute "Population_size"
which does not define either the features temporality or its spatiality.
Nonetheless, the "Population_size" can have its own temporality, e.g.
pop in 1900, pop in 1930, pop in 1970. Note that in this case the
temporality of the attribute does constrain the temporality of the
feature, the feature must at least exist at those particular moments in
time, but does not encompass the temporality of the feature. I am not
yet sure that a 'non-spatial, non-temproal' attribute can have
spatiality. If we imagine a 'factory' feature we could consider it to
have a 'plume' attribute which would have a spatial presence completely
different from the factory itself. However, it appears to me that this
'plume' and indeed any 'attributes' with spatial presence, are actually
a features of their own.
So no, the "Attribute.java" interface name is not good---it's at the
very least confusing. Whether that's worth changing depends primarily on
how deeply you developers have incorporated that word into your
language.
> The word "properties" is also provided (of which
> "attribtues" is a specific kind of property holding data).
> I admit that our
> Feature Model is a *data model* and does not allow Object-oriented methods/
> opperations at this time. The OGC is struggling with associatations linking
> data to opperations as we speak as part of their Catalog Publish/Find/Bind
> infrastrure. I cannot consider this as leadership - or a strong movement
> towards object orientation.
Not sure I get that but it sounds interesting.
>
> Dave, Adrian is in a world where not only the attribute values change over
> time. The schema changes over time.
No, I wouldn't say that. The schema must, to make sense, encompass all
which is possible for the feature. However, I have run across users who
want features to change geometry over time, features which are dependent
on others in peculiar ways, and features which are anything but simple.
A feature is a "real world entity" but the way one describes such an
entity may change over time.
> While the origional OGC Feature Model can
> deal with this (for them a Feature is a bag of stuff with a fixed ID, the
> stuff is captured as attribtues wach with a unique timestamp/value/etc...
> different Application Schema are constructed (like views in a database)
> offering a perspective on the content.
>
> I can think of ways for you two to work together - serve up the "Feature"
> based on timestamp, complete with the Schema for the content at that point in
> time. Justin will call me out if I don't point out that "Extensible
> Interface"
> idea of allowing you to query for the content in the shape needed for the
> task
> at hand.
>
> If that idea makes sense (to both of you), or if you think something else may
> be better - perhaps you can take it up with Justin?
Thanks, this is over my head but I'll keep at it and see if I can grok
what's going on.
On the feature model:
It might help you all to create for yourselves a typology (exhaustive
list of the different types) of features. My approach to this is totally
*not* practical but pure theory. I admire you all for sticking to the
practical and getting the simple stuff done first. However, as you
re-invent the feature model, perhaps a typology of feature types could
be useful to keep in mind over the long term. Here's a start:
* Simple features: Feature with 1 temporal defn (instant or
duration), 1 geometric defn (vector or field, where the latter
is really a field,i.e. it exists everywhere), 1-D array of
values.
* Feature with compound temporality: A feature could exist,
disappear and reappear in time. Cities have been destroyed and,
after a while, rebuilt, Empires vary in extent.
* Feature with compound geometry: Features can be simple with
compound geometries, e.g. the land owned by ...
* Feature with compound value attributes: e.g. the non-flat schema
on which you are focusing now.
* Feature collections: can be collections of other features.
Presumably both the temporal and spatial presence of the
collection is a simple addition of the temporal and spatial
presence of the components. Not sure how one treats the 'value'
elements---presumably that depends on what they are. An
interesting aspect would be to allow collections to constrain
their contents e.g. geometries must span (cover entirely) the
extent of the collection and cannot overlap.
* Dependent Features: Features can depend for any of their
time/space/value attributes on those of others. e.g. A state
feature can be defined to end at the center of the mississippi
river feature
* Measured versus Defined features: One idea I've been pondering
is how to distinguish features which are defined from features
which are measured. The borders of a property, defined at
certain lat.s and long.s, illustrate the former. The extent of
an aquifer illustrate the latter. It may be known that certain
points are in the aquifer and certain are outside it without
actually knowing the boundary of the aquifer. In this case, a
measured feature would have limits defined as a polygon but
whose actual geometric makeup were dependent on drill point
metrics.
I'm sure there are others we could eventually consider but I'm too tired
to try to be authoritative right now
And with that, I plan to shut up for a while on the list and actually
read some code,
all the best,
adrian
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
