Luca Sigfrido Percich wrote:
Hi again Jody,
On 29 Sep 2005 at 20:51, Jody Garnett wrote:
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.
Don't you think that it would be great having GeoServer/WFS support
the query capabilities of an SQL server - I mean join, sort, group &
aggregate, expression support... is there any plan in GT/GS to get an
unified view and design of these query capabilities?
It is more that they are trapped behind the WFS standards w/ respect to
this. Refractions is now a member of the OGC, and it is something you
can consider if you are interested in persuing this sort of thing.
I am happy to make the functionality in geotools, and "out" the
functionality as a vendor specific extention to geoserver if needed.
You can also look at the Catalog 2 spec, it also makes use of Filter 1.1
and has an implicit join - basically when more then one Filter is listed
the results are to be joined.
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.
Yes, sorry for having you explain this twice! :o)
Np, I need to keep it all straight myself.
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.
Keeping simple types and building complex on top would make Paolo and
me happier... simply because there's a lot of ongoing work on the
simple model. But I'm sure that we'll find the best solution which
best fits the new FM!
Our Meta_* descriptors are Java classes which are made persistant on
DB tables (but could be streamed on file or XML). The concept is that
we can create FeatureTypes from our Meta_Types. If FeatureType
contained all the "extra info" we need (like PKs & relations), we
could work directly with it.
I agree that FM has to be completely independent from storage... so
metadata are needed for example to "configure" a RDBMSDataStore to
create tables from FeatureTyopes appropriately. Also, the handling of
complex types could be very different if we use a XML-based data
source or a RDBMS... even if the resulting FeatureType would be the
same.
It would be nice extending the new FM with concepts like
associations... well nested Feature are associations... I've talked
about this in the wiki. The important thing is having a good metadata
model which works in memory (FM), a good metadata model for handling
data at the storage level (transaction, validation, datastore)... and
clear relationships between them! ;o)
Yeah I was going to say that GML uses "Features with out Geometry" to
capture associations. Lets get the first cut out the door - and then we
can think about building on. I have actually been asking the opposite
question - is there anything in there that can be removed?
Ok, we'll go on working, keep in touch with Gabriel and Dave and go
on updating the wiki.
Cool, and thanks for the IRC chat.
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
