Luca Sigfrido Percich wrote:
Hi all,
following the last IRC breakout meeting on complex types/ metadata,
I've written a wiki on the topic, it can be found at:
http://docs.codehaus.org/display/GEOTOOLS/ApplicationMetadataAndComple
xTypes
THe idea is carrying on the development of our application metadata
infrastructure, porting it to the new Feature Model, and adding the
ability to map simple FeatureTypes to complex ones and vice versa.
Thanks - your wiki page are getting better and clearer. For some of
your SQL concerns you should view the Filter 1.1 specification (it
includes sorting). Corey is workin on aggregates right now, we did look
into the issues of joining, and calculating attributes last year with
limited success.
You can still view some of the ideas here:
-<http://svn.geotools.org/geotools/trunk/spike/dzwiers/src/org/geotools/data/>
-<http://svn.geotools.org/geotools/trunk/gt/ext/experimental/src/org/geotools/>
The document (and the project) is still ongoing, any suggestion, note
or proposal will be more than welcome.
Concerning:
If I well understood, in Feature Model Proposal
<http://docs.codehaus.org/display/GEOTOOLS/Feature+Model+Proposal> the
simple schema is seen as a simplified view over a complex one, i.e.
the SimpleFeature API is an alternative way to access a complex content.
SimpleFeatureType describes just that; a normal FeatureType with the
restriction that the only contents are AttributeTypes with multiplicity
1:1, complex content is not supported.
Your AMD approach seems to have the goal of describing comple types
using simple ones, the nice part of the new FM is that you have real
Java classes representing each kind of content.
Please note that currently in AMD there's no separation between schema
and type. This separation could be the key to achieve Schema mapping.
Could we think of applying different Schema Descriptors to the same
ComplexType in order to "reshape" it?
A you point out the real trick to to map Complex content to Flat content
- for storage in a RDMS. I am glad you and gabriel are talking.
You suggestion about changing the FeatureType on the fly could be done,
simply make a new FeatureType for each feature in your collection. But
I cannot see the advantages over just using AttributeType multiplicity.
The resulting Features would not be SimpleFeatures, but they would not
have to contain complex content either.
Would it help if we set up FlatFeature in a manner simplar to SimpleFeature?
As mentioned above the Descriptors represent the range of "valid"
content. You can make use of ChocieDescriptor and so on to provide a
wide range of allowable content. So both the Type and the Descriptor,
description of allowable content, are know up front. The shape of an
actual feature is free to change within these bounds, or even outside of
these bounds - allowing you to work with invalid content.
Jody
-------------------------------------------------------
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
