Thanks Gabriel,
Havent had a chance to test, but this is sounding good. Comments inline
Gabriel Roldán wrote:
Hi Rob,
this is an update on the ComplexDataStore stuff, you can download from
geotools svn complex-features branch for testing it. I didn't managed to get
it compiling with maven yet, but importing main as an eclipse prohect should
be enough.
I still need to put some architectural stuff on the wiki page. I haven't had
time since it required a lot of collateral development in order to make
sense.
Here is a brief explanation:
ComplexDataStore acts as a wrapper among another datastores. A
FeatureTypeMapping class was developed to hold the declaration of mappings
between a source FeatureSource and an output schema.
This mappings are tuples of XPath and org.geotools.filter.Expression objects.
The XPath expression locates an output schema attribute. The Expression gets
evaluated against Features of the source type to get the value of the target
attribute. This give us almost all the freedom we need for a flexible
mapping, so you can use derived attributes. For example, if an output schema
has an "areaOfInfluence" attribute of type Polygon, and your source schema
has a location att of type Point and a ratio attribute of type float, you can
map the output attribute as an expression that computes a buffer of "ratio"
around the source "location", and so on.
Cool.
Have you got any examples of how such an expression would map onto
features pulled from an underlying data store?
It is even possible to specify a list of attributes from the source type as
the grouping attributes, more or less like in a GROUP BY sql sentence. And
the attributes that does not belongs to the grouping ones are mapped to a
single, multiple valued, instance of the target type, from multiple instances
of the source type.
The difference between this and what you have accomplished in the complex_sco
branch is that all the functionality is implemented in a single place, rather
than tweaking here and there in geoserver to "simulate" this situation (sorry
if I'm not being so clear, its my english).
Yeah - we had to do a lot of hacking because there was no route to pass
the metadata we wanted from the config into the fitler and encoding -
the metadata was inferred from the result set.
The other notably thing, is that this kind of mapping allows filter unrolling.
That is, that filters that are constructed against the output schema, gets
translated back to the source schema, to the surrogate FeatureSource can
optimize as much as possible the incoming queries.
This is a huge step forward.
The same happens with IDs, you can specify the mapping of target attributes
ids through the target xpath expression and a source Expression.
An effect of having all this functionality on a single DataStore is that you
need to have an instance of your output schema (I mean a
org.opengis.feature.type.FeatureType, not the xml schema document) _before_
you can start delivering Features of that type.
yes. This will always be the case.
This arises the need of
configuration. That is, ComplexDataStore should be able of reading the target
type from some kind of persistent storage. I realized a XML configuration
file, with its xml schema, for storing a set of FeatureTypeMappings, which
constitutes the FeatureTypes a ComplexDataStore will serve. This means,
storing the surrogate datastores connection parameters, the attribute and fid
mappings, and, of course, the output schemas.
So does this mean the "surrogate datastores" are created on the fly by
complexDataStore and dont need to be manually configured (or exposed
uncessarily?). This sounds like a good thing, but i suppose you also
want to support many feature types being served from common tables,
without massive duplication of this info.
That's the tricky part. So I wanted to have something that doesn't existed in
geotools yet, a GML schema parser that produces geotools FeatureTypes.
I'm not sure a GML schema parser is that easy - I've written a recursive
one in the past and its a very non-trivial task. Substitution group
mappings make it even hairier, though its not sure this will turn out to
be a workable mechanism. Its worth noting that a parser is of no
practical use unless it can follow import directives. (Community schemas
will be heavily reliant on importing common modules). For this phase of
the project its fine to manually create the configuration IMHO
AFAIK, WFSDataStore could benefit from this too, since it actually is not
parsing GML schemas, but inferring them from a Feature instance, which is ok
for simple Features, but not for complex ones, since you can't determine
multiplicity and elements not present in an (xml) feature instance, you need
the actual FeatureType, which in that case should be aquired from the actual
GML schema in xml format.
I do not plan to implement schema import and include yet, but certainly would
be desirable in a next phase, so all you have to do to work to your full
community schema is to parse it and be rewarded with a type repository
holding geotools/opengis representations of your schema. It could be used
even to parse the full gml schema, so an application user could choose to use
a gml2 factory, a gml3 one, or a gml5 when the time comes, just by parsing
the desired schema, and having all its types ready to use.
So that is, I _almost_ finished that parser. It reads an (x)gml schema and
produces a geotools FeatureType. Finishing it should be the last step for
having the fisrt version of complex datastore released, which I hope to
happen betweern next week's tuesday and wednsday.
OK - we'd probably need to manually import into a flat intermediate
schema to make this work. We still want to advertise the correct output
schema in DescribeFeatureType though
In the while, Mauricio will start the GML encoding phase of the project, so
this 2 or 3 days delay does not affects our (already strange) schedule.
well, hope that counts as a brief explanation of current progress, after so
much days of mad coding and low communication.
Look forward to seeing some test cases (if these are in the code base
point me to them :-) )
Please feel free to send your comments/concerns.
Best regards,
Gabriel
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
