[ http://jira.codehaus.org/browse/GEOS-4?page=all ]
Chris Holmes reopened GEOS-4:
-----------------------------
Assignee: Andrea Aime (was: Justin Deoliveira)
there are some issues with this, most reported on http://docs.codehaus.org/display/GEOSDOC/WFS+DataStore
Am re-opening this so I can link to them all.
Cascading WFS
-------------
Key: GEOS-4
URL: http://jira.codehaus.org/browse/GEOS-4
Project: GeoServer
Issue Type: Wish
Components: WFS
Reporter: Chris Holmes
Assigned To: Andrea Aime
Fix For: 1.3.0 PR1
Original Estimate: 3 weeks
Remaining Estimate: 3 weeks
GeoServer should support Cascading WFS, that is using another WFS as a datasource, able to return its features to a client. The way to do this is probably in GeoTools, with a WFS DataStore. There are a few ways to approach this - we could have GeoServer read the gml passed by another datasource, which would obviously slow things down, but it would allow us to do a lot more with the data. For example if the cascaded WFS only supported BBOX filters, turning its gml into geoserver data would allow us to leverage all of GeoTools's native filtering capabilities. Of course this might actually be required by the spec, because we can not advertise for only specific capabilities in our FeatureTypes, the filters must apply to all. Another option is to just forward the responses to clients, without checking them. This is obviously a lot faster, but still would require a lot of tweaking to get it working right. Could be cool if we got a Caching WfsDataStore, that could hold the cascaded WFS's features in memory, or even in a pickle (memory persistant on disk) dataSource. A super cascading server with a bunch of disk space could slowly gather its cascaded server's feature information in fast datasources. Data could spread between geoservers in a peer to peer fashion. Of course then you get into all sorts of issues like updates and versioning and whatnot. There's lots of ideas on this front, and I need to get back to work, but it'd be nice to get some good comments on this issue. It's probably a ways off, but is definitely something a lot of people desire.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
In conjunstion with the schema-mapping capabilities of complexDS this cascading WFS would also allow non-data-product-specification-compliant WFS implementations look like sensible data - and people could wrap their crippled WFS technologies with geoserver while they make up their minds about what technoogy platforms to support in the longer term.
The cache idea becomes even more fun if we postulate a forward-cache: with geoserver automatically garnering updates for regions of interest (which may simply be the bits previously cached) - but could be used to replicate data to offline devices too!
Rob A
Chris Holmes (JIRA) wrote:
[ http://jira.codehaus.org/browse/GEOS-4?page=all ]
Chris Holmes reopened GEOS-4:
-----------------------------
Assignee: Andrea Aime (was: Justin Deoliveira)
there are some issues with this, most reported on http://docs.codehaus.org/display/GEOSDOC/WFS+DataStore
Am re-opening this so I can link to them all.
Cascading WFS
-------------
Key: GEOS-4
URL: http://jira.codehaus.org/browse/GEOS-4
Project: GeoServer
Issue Type: Wish
Components: WFS
Reporter: Chris Holmes
Assigned To: Andrea Aime
Fix For: 1.3.0 PR1
Original Estimate: 3 weeks
Remaining Estimate: 3 weeks
GeoServer should support Cascading WFS, that is using another WFS as a datasource, able to return its features to a client. The way to do this is probably in GeoTools, with a WFS DataStore. There are a few ways to approach this - we could have GeoServer read the gml passed by another datasource, which would obviously slow things down, but it would allow us to do a lot more with the data. For example if the cascaded WFS only supported BBOX filters, turning its gml into geoserver data would allow us to leverage all of GeoTools's native filtering capabilities. Of course this might actually be required by the spec, because we can not advertise for only specific capabilities in our FeatureTypes, the filters must apply to all. Another option is to just forward the responses to clients, without checking them. This is obviously a lot faster, but still would require a lot of tweaking to get it working right. Could be cool if we got a Caching WfsDataStore, that could hold the
cascaded WFS's features in memory, or even in a pickle (memory persistant on disk) dataSource. A super cascading server with a bunch of disk space could slowly gather its cascaded server's feature information in fast datasources. Data could spread between geoservers in a peer to peer fashion. Of course then you get into all sorts of issues like updates and versioning and whatnot. There's lots of ideas on this front, and I need to get back to work, but it'd be nice to get some good comments on this issue. It's probably a ways off, but is definitely something a lot of people desire.