Roel, That sounds like a lot of data you are trying to pull into the interface, I'm curious about what scale you are trying to make this work at, how much Sewer network are you displaying at a time? In the field, we don't tend to need much more data than what could be seen while standing in a location, even at a busy (lots of features) intersection, you would only be looking at a hundred or so features at a time. Do you by chance have a lot of Attribute data per feature that you are trying to combine?
Bobb From: Roel De Nijs [mailto:roel.den...@aquafin.be] Sent: Tuesday, November 04, 2014 11:16 AM To: Basques, Bob (CI-StPaul); openlayers-users@lists.osgeo.org Subject: RE: Alternatives to get rid of WFS layers Hi Bob, For our WMS data we have created 1 layer which combines all required feature types to reduce the number of network requests. This works very well. Also one of the changes we already made to improve performance. Another one was replacing the database views with tables (which are rebuilt every night). Today I tried to do something similar for the WFS data: just 1 layer with all required (visible) feature types. But the request itself takes 6-7 seconds, 750KB of WFS data (gzipped) is returned. I saved such a response into a text file, it was almost 7MB. So it takes 10-15 seconds until the user can proceed (request is completely finished with all wfs being processed and wms tiles are loaded). This probably won't be fast enough. But maybe you are referring to something else which I'm not aware of. Kind regards, Roel Van: Basques, Bob (CI-StPaul) [mailto:bob.basq...@ci.stpaul.mn.us] Verzonden: dinsdag 4 november 2014 17:48 Aan: Roel De Nijs; openlayers-users@lists.osgeo.org<mailto:openlayers-users@lists.osgeo.org> Onderwerp: RE: Alternatives to get rid of WFS layers Have you thought about combining all the WFS services into a single call and then managing the filtering on the client side. This would also work for the hover control, in that you could pull multiples based on a hover action and still use some sort of buffer to handle things that are clustered as well as multiple selects. This could reduce the amount of data being pulled on demand to an acceptable level, performance wise. It also allows you to do global searches since all data is handled by a single service. bobb From: openlayers-users-boun...@lists.osgeo.org<mailto:openlayers-users-boun...@lists.osgeo.org> [mailto:openlayers-users-boun...@lists.osgeo.org] On Behalf Of Roel De Nijs Sent: Tuesday, November 04, 2014 10:32 AM To: openlayers-users@lists.osgeo.org<mailto:openlayers-users@lists.osgeo.org> Subject: [OpenLayers-Users] Alternatives to get rid of WFS layers Hi list, We have a web application displaying some geographical data (about the sewerage system) and using OpenLayers 2.13.1 as front-end library (geoserver as back-end). Currently we have +- 30 object (feature) types. Every object type has a WMS and WFS layer in the map. The visibility of each object type is dependent on a minimum/maximum zoom level and/or can be turned off by the user. The user can perform a set of standard functions on the map (zoom, pan,...) and each feature (hover, select, double click,...). Everything works fine, but the main criticism about this application is (very) poor performance, being (very) slow and making the browser freeze. Sometimes the only option is to close the browser and start again. Not the most user-friendly approach. We did some testing related to the performance. One of the things we noticed, WFS data has a huge impact on performance. From a certain zoom level, the WFS data (for all layers) retrieved the server is 750KB - 1MB (and that's the gzipped version). It takes some time to load all this data (certainly if the user is on the road) and also to process the data. If you zoom and pan a few times, you'll probably have to close your browser (mostly IE) and start over again. Users sometimes have to wait 15-20 seconds before a pan or zoom request has finished, which is inacceptable from a user's point of view. I can't imagine this application is the only one having to deal with so much WFS data, so I was wondering how other developers managed big amounts of WFS data and keeping their web application responsive while loding/processing the WFS data. Or maybe some alternative/work-around exists to get rid of the WFS layers/data, but still keep the feature functions (like hovering, (multiple) selection, box selection, double click,...)? Another path I have already experimented with is loading the WFS data on-demand, because the user is probably not interested in all features but only in some of them. Using the GetFeature control I'm able to get the features underneath the mouse cursor. But I'm wondering how I can incorporate all other feature functions. Because e.g. the Select control uses a wfs layer, but the layers doesn't contain features anymore. I'm really desperate, so I appreciate all insights, suggestions, pointers, hints, a lot! :) Kind regards, Roel De Nijs Senior Java Developer ________________________________ Volg Aquafin op Facebook<https://www.facebook.com/AquafinNV> | Twitter<https://twitter.com/aquafinnv> | YouTube<http://www.youtube.com/channel/UCk_4P5BJ-MtEEDCkCsR_KqQ?feature=mhee> | LinkedIN<http://www.linkedin.com/company/aquafin/products> Disclaimer: zie www.aquafin.be<http://www.aquafin.be> P Denk aan het milieu. Druk deze mail niet onnodig af.
_______________________________________________ Users mailing list us...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/openlayers-users
