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. 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). 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. 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. 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. 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. 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. 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. 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
