Hi all, Thanks all for the valuable input. Highly apreciated!
In our database we have a table for each object type containing all data for records of this object type (can be 200-300 attributes/fields and even more). For every possible layer we have a dedicated spatial table with just the needed attributes for geoserver to render each feature correctly. So these tables have uid, geometry (points and linestrings) and at most 3-4 additional attributes. The WMS layers do all the displaying of the features (color, symbol/shape, width,…). The WFS layers are only used to let users hover and show some attribute info (not included in the wfs, but a seperate rest request) , select some features (to use in another part of the application), double click the feature to manage its information) and so on. So because a layer is based on its dedicated spatial table, the returned WFS data is limited to a uid, geometry and a few attributes. Because a sewer system can be quite dense (certainly in a city), the number of visible features on a given zoom level can range from 5000 to 25000. In the current (production) version of the application all WFS data for these features is loaded and processed (but as mentioned before not for displaying purposes). After our performance testing (after the complaints/criticism) we also noticed that WFS has a huge impact on performance. And that’s also confirmed by some replies in this thread. So we are definitely on the right track :) We currently try to rethink and rework the application and avoid the use of WFS completely (or as much as possible). So the current (development) version of the application has only WMS being loaded. Together with some other little changes (e.g. layers based only on tables, not on views anymore) we managed to improve the performance drastically. So far so good! But most functionalities in the application depend on these WFS layer(s). But this data is now not available anymore. So our main and biggest challenge is to create the same (or similar) user experience without the WFS layers. For example, a user could double click on a feature and a page with its detailed information was opened. So we had a SelectFeature control which operated on the WFS layers and had a doubleclick callback to open this page. Now I have implemented a GetFeature control which displays all features on hover (or click),. But I wonder how you can create a similar user experinece for e.g. double click? So what’s considered the standard or most appropriate approach to achieve this kind of functionality? Do I need to have a SelectFeature control which wraps a GetFeature control? Or do better alternatives exist? Kind regards, Roel Van: Glenn Mullett [mailto:tcha...@gmail.com] Verzonden: woensdag 5 november 2014 5:02 Aan: Roel De Nijs CC: openlayers-users@lists.osgeo.org Onderwerp: Re: [OpenLayers-Users] Alternatives to get rid of WFS layers Hi Roel I agree with Phil. However, in times when you need to load many features through wfs, you can also try the following: - Use geojson as the output format, not gml - this will greatly reduce the response size. - Configure the webserver to gzip text content - this will also give quite a performance boost. - You could pipe all requests to your backend wfs server through a php proxy (using curl to send and retrieve the content from the wfs server). If you are going to then be making many of the same type of request through the proxy, you can enable a webserver side content cache such as mod_mem_cache (apache) to speed things up a little - wfs 2.0 protocol supports paging by providing a recordcount variable. You may be able to use this feature of wfs 2.0 together with an e.g. paged geoext featuregrid and only load x number of features at a time. Kind regards, Glenn On 5 Nov 2014 00:01, "Phil Scadden" <p.scad...@gns.cri.nz<mailto:p.scad...@gns.cri.nz>> wrote: I've posted here a number of times on WMS/WFS. My advice is never use WFS when you can do WMS instead. In particular, you use WMS for all display. I use WFS when I want attribute information and I get that on demand with getfeature queries, which can be onHover. If there isnt too much geometry, then I return WFS geometry and draw it to show selections etc. but for objects with dense geometry SldSelect works better. Rethink the application as WMS and you will get far better performance. Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents. _______________________________________________ Users mailing list us...@lists.osgeo.org<mailto:us...@lists.osgeo.org> http://lists.osgeo.org/mailman/listinfo/openlayers-users ________________________________ 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
