Re: [Geoserver-users] multi datastore request

[Chris H. <ch...@op...>]

On Sat, 18 Jun 2005, Gerald Estadieu wrote:

> 
> I am wondering if it is possible in a request (if I understand through 
> an OGC filter...I still have to learn!) I can have in one RDBMS (let's 
> say PostGIS) a table with geometry information and some attributes and 
> in another RDBMS (Oracle) I have others attributes (and of course a 
> unique key to match both side). I know it is not the best way but some 
> time you do not want to merge everything such as you want to keep some 
> customer information within the CIS and still be able to use some data 
> within a spatial contest.
> Do I make myself clear enough?
Yes.  With a WFS request there is no way to do this.  The Filter spec is 
limited to a single datastore - so the short answer is no.  

We've actually thought a good bit about this problem in the past, though 
only at the geotools level, not at the web services geoserver level.  So 
the first solution you would likely see for this is being able to define a 
'virtual' datastore in GeoServer (geotools), and then you could issue the 
normal requests against as if it was any other datastore.  There have been 
a few attempts to do this, none successful, to some extent due to no good 
use cases.  I think the leading candidate right now for doing something 
like this would be to use Derby or HSQL - an embedded java database, where 
we would just dump both datastores, and do queries against it.  For 
transactions things get tricky, but I imagine that most people would just 
need it read only.

Having that composed on the fly from a web request would be another whole 
can of worms, and like I said the ogc specs don't cover it.  But perhaps 
eventually we could have a soap interface or some such to form such a 
virtual datastore...

Another option, if you really do need this done, is to write a customized 
datastore, hard coded to the two tables that you need.  This wouldn't be 
too difficult for an un-optimized version, since you'd just need to read 
the rows in - java code would handle all the filtering (both spatial and 
non-spatial).  If you wanted to get fancy you could do filtering in the 
database, do something like modify our FilterUnpacker (basically each 
datastore reports the filters it can handle natively with a 
FilterCapabilities, and the unpacker figures out which filter to pass to 
the native encoder and which to handle in java code), so that it works on 
attributes, knows where each comes from and filters appropriately.  Would 
be quite tricky to get right, but good fun for sure.  But I'd imagine it'd 
be more practical to just dump in an embedded spatial db (we're close to 
getting both hsql and derby spatialized, both need a few little 
improvements and we can use David Blasby spatial db in a box).  It would 
avoid a lot of annoying bug fixes that I'm sure would pop up all over the 
place.

Best regards,

Chris

> To take an example that every geoserver has: the USA states and 
> population information shapefile. Let's say I have state geometry and 
> attributes (name, surface...) in PostGIS and in Oracle I have a database 
> with a lot of population information (which are not considered as direct 
> attributes but more associated external data that can be used for 
> thematic map generation) with a key to link with the corresponding 
> state. Of course both datastores will be within the same namespace.
> Regards
> Gerald
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Geoserver-users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
> 

--