Quoting Matthias Blech <[EMAIL PROTECTED]>: > Dear Chris Holmes, > > my name is Matthias Blech (23), I'm a student computing science > engeneering. I'm doing my practical at Con Terra GmbH > (Muenster/Germany) to prepare my diploma thesis. My Topic is to > develop a "RelationshipDataStore", what's nearly the same to your > "ComplexDataStore"! > > As I read your Documentation yesterday and found out that we're doing > almost the same, that's the reason I write you. Maybe there is a way > to > benefit for us? Great! Yeah, it sounds like you're thinking directly along the same lines that we are. It would be great if we could work together, we love collaborations, and it sounds like you could definitely help lead the bleeding edge of what we're trying to do. Indeed this sounds like a great thesis topic - one of the more excited problems we've come across, and it'd be great if we could benefit from your work. I'm ccing the geotools devel list, since others have been more involved in the code than I have, and I'm transitioning to coding less. And most all this stuff is at the geotools level, when we get into a nice gui in geoserver we'll discuss there.
I was going to forward all your great diagrams, but it's a bit big to dump all that into a couple hundred people's inboxes. They can be found at http://docs.codehaus.org/display/GEOS/Improving+Complex+DataStore Matthias, it'd be great if you could throw up your thoughts on that page, perhaps after feedback from the list. Indeed organizing all the thoughts on complex datastore stuff, where we are and where we want to go would be great. A few other initial thoughts that you may have missed are here: http://docs.codehaus.org/display/GEOS/DerivedFeatureType and http://docs.codehaus.org/display/GEOS/Advanced+GML Many of these have actually been accomplished by Gabriel, so yeah, basically it'd be great to get an overview of what we have done and where we want to go. > > As I told, I have read the complex datastore documentation and there > many thing equal to the relationship datastore: > - the relationship datastore also: > - provides complex features out of existing simple > features > - is almost a deligating and assambling datastore > - functions as a wrappr over existing datastores > - is a kind of object-relational mapping aimed on > spacial data > > - further the relationship datastore: > - does support cross-datastore-joints > - is based on a binary tree structure biuld up by > its > factory > - supports reading, writing and persistent locking > for > complex features indepentend from its basis > datastores > - will be able to read/write features in lazy or > eager > mode > - causes no changes in geotools! These are _exactly_ the direction we've been talking about taking Complex DataStore. Cross DataStore joins are the biggest priority, many users are very excited by this possibility. I'd be interested to hear more about your binary tree structure. Basically we'd like the API to be able to support a variety of different backend implementations, which hopefully the work Gabriel just completed should do - getting the Feature model good enough to handle all the complex stuff. The way we were initially thinking to handle cross datastore joins would be to just use a spatialized java db, like derby or hsql (see: http://docs.codehaus.org/display/GEOS/SpatialDBBox). Just dump everything in, and rely on the capabilities of java relational dbs + jts. But like I said, a good api would mean that we could easily swap in and out the backend implementation of the cross datastore join. Writing and persistant locking would be _great_, and beyond the scope of what we've been thinking, since it's a non-trivial task. But indeed a perfect thing for a thesis, tackling the hard stuff. If you were to come up with a good solution for this we'd be _very_ interested in incorporating into GeoServer/GeoTools. And don't hesitate to kick your ideas on it out to us, you'll often get a nice review of potential problems. > > Attached to this mail you'll find some illustrations describing the > structure of my relationship datastore, which I'm going to explain > now. (http://docs.codehaus.org/display/GEOS/Improving+Complex+DataStore has all the diagrams, for geotools developers) > > At first, if you want to combine simple features to a complex one, > you > need to biuld up relations very similar to relations in a relational > database (primary key, foreign key). An relation is an assambly of > two > attribute. This is the way I implemented a relation. All relation > once > defined by the user are grouped in a so called relationtable. > The second is the structure of a single relationship datastore. One > relationship datastore aggregates two datastores like mysql, acrsde, > xml > ... or relationship datastore! A relationship datastore knows > relations > of its containing feature types. So that every data store has its own > relation table created by the relationship datastore factory out of > the > global user defined relation table. It that way you are able to build > up > an binary tree structure based on relationship datastores. The leafs > are > the basis datastores and the root is the top relationship datastore > Every relationship datastore understands its child datastores as a > datastore defined in the geotools datastore interface. Reading is > mostly > a bottom-up-operation. From leaf to root the feature "grows" from > many > simple features to a complex one depending on the relation. Therefore > writing is an top-down-operation. From root the the leafs the complex > features will be split step by step until it is a simple feature > which > is ready to write back. What's the performance like for this? I'm not sure I understand the binary tree - are you actually sucking the features out of the dbs? Or just marking the relationship? How are Filters done against relationship datastores that are across datastores? Like are they turned into native db queries as much as possible? This is a nice feature of the current complex datastore implementation, turning the filter queries into native sql, but it gets a good bit more complicated when you're going across datastores. With our users we definitely quickly hit scalability issues - I'm very interested in how fast your current implementation will work. What about transactional integrity of cross datastore commits? Do you think the current geotools infrastructure is sufficient? I guess theoretically it should be, since we do go cross datastores with GeoServer transactions. But yeah, I've not thought much about the problems. How far along are you in writing this stuff? Do you have working implementations yet? The ideas seem sound. And yes, it'd be great if you could join up with the current effort, and we'd have a series of unified datastores. The implementations, like binary tree vs. spatial db, could be different, but I think it'd be essential to have a common configuration format, of how a user specifies the mapping relationship. > > It would be very nice to hear/read from you. We're working an the > same > things and maybe there's a way to come together. Definitely, thanks for getting in touch, it'd be great to be able to work together on this stuff, it's one of our most desired features. best regards, Chris > > Best regards, > > Matthias > > *** Chris Holmes The Open Planning Project thoughts at: http://cholmes.wordpress.com ---------------------------------------------------------- This mail sent through IMP: https://webmail.limegroup.com/ ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
