Discussion:
[OpenLayers-Users] Alternatives to get rid of WFS layers
Roel De Nijs
2014-11-04 16:32:27 UTC
Permalink
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.
Roel De Nijs
2014-11-04 17:16:04 UTC
Permalink
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:***@ci.stpaul.mn.us]
Verzonden: dinsdag 4 november 2014 17:48
Aan: Roel De Nijs; openlayers-***@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-***@lists.osgeo.org<mailto:openlayers-users-***@lists.osgeo.org> [mailto:openlayers-users-***@lists.osgeo.org] On Behalf Of Roel De Nijs
Sent: Tuesday, November 04, 2014 10:32 AM
To: openlayers-***@lists.osgeo.org<mailto:openlayers-***@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.
Basques, Bob (CI-StPaul)
2014-11-04 17:23:50 UTC
Permalink
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:***@aquafin.be]
Sent: Tuesday, November 04, 2014 11:16 AM
To: Basques, Bob (CI-StPaul); openlayers-***@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:***@ci.stpaul.mn.us]
Verzonden: dinsdag 4 november 2014 17:48
Aan: Roel De Nijs; openlayers-***@lists.osgeo.org<mailto:openlayers-***@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-***@lists.osgeo.org<mailto:openlayers-users-***@lists.osgeo.org> [mailto:openlayers-users-***@lists.osgeo.org] On Behalf Of Roel De Nijs
Sent: Tuesday, November 04, 2014 10:32 AM
To: openlayers-***@lists.osgeo.org<mailto:openlayers-***@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.
Phil Scadden
2014-11-05 00:21:29 UTC
Permalink
> 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 how much of this data to you want? Request only the attribute fields
you want and dont bring down the shape. Do anything you want to do with
the shape via WMS.


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.
Phil Scadden
2014-11-04 22:01:25 UTC
Permalink
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.
Roel De Nijs
2014-11-05 12:58:04 UTC
Permalink
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:***@gmail.com]
Verzonden: woensdag 5 november 2014 5:02
Aan: Roel De Nijs
CC: openlayers-***@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" <***@gns.cri.nz<mailto:***@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
***@lists.osgeo.org<mailto:***@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.
Phil Scadden
2014-11-05 20:30:14 UTC
Permalink
I use GetFeature Control for hover functionality, but sometimes
WMSGetFeatureInfo with hover with an Html template backend is good
enough. (When your application only needs to display the attributes, not
do any other processing of them). I use selectfeature for "info" and
"polygon" tool which usually have the assumption that multiple features
will be returned - display list of features in a popup and the user
doing further processing from there.

Depending on database size, you could try some pre-load tricks. onmove
you issue WFS GetFeature for the area covered by the map but ONLY for
attributes, not shape (that should reduce your download size). Then you
need only featureid returned from hover and look up the other attributes
in the preloaded table.

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.
Roel De Nijs
2014-12-12 18:00:22 UTC
Permalink
Sorry for the very late reply, but I was on holiday and temporarily moved to another project. But now I am back again!

I created a GetFeature control (with custom protocol) which works similar with your selectfeature: a list of features (at the mouse position) is displayed in a popup. When the user clicks on an item in the list, some data is shown (no wfs data, just a REST call).

One of the scenario's I am struggling with is selecting multiple features. In our current application we have a SelectFeature control using the WFS layers. So a user could select some features (using mouse clicks and/or box selection). Then these selected features could be used to execute another function in the application. But now these WFS layers don't exist anymore, so wondering what's the best approach to simulate this behavior.

-----Oorspronkelijk bericht-----
Van: openlayers-users-***@lists.osgeo.org [mailto:openlayers-users-***@lists.osgeo.org] Namens Phil Scadden
Verzonden: woensdag 5 november 2014 21:30
Aan: openlayers-***@lists.osgeo.org
Onderwerp: Re: [OpenLayers-Users] Alternatives to get rid of WFS layers

I use GetFeature Control for hover functionality, but sometimes WMSGetFeatureInfo with hover with an Html template backend is good enough. (When your application only needs to display the attributes, not do any other processing of them). I use selectfeature for "info" and "polygon" tool which usually have the assumption that multiple features will be returned - display list of features in a popup and the user doing further processing from there.

Depending on database size, you could try some pre-load tricks. onmove you issue WFS GetFeature for the area covered by the map but ONLY for attributes, not shape (that should reduce your download size). Then you need only featureid returned from hover and look up the other attributes in the preloaded table.

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
***@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.
Phil Scadden
2014-12-12 20:47:39 UTC
Permalink
On 13/12/2014 7:00 a.m., Roel De Nijs wrote:
> One of the scenario's I am struggling with is selecting multiple features. In our current application we have a SelectFeature control using the WFS layers. So a user could select some features (using mouse clicks and/or box selection). Then these selected features could be used to execute another function in the application. But now these WFS layers don't exist anymore, so wondering what's the best approach to simulate this behavior.

Why not use WFS as well? I use WFS for selecting, WMS for drawing. If
you are using Geoserver backend, you have WMS and WFS available for
every layer.

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.
Roel De Nijs
2014-12-15 10:37:30 UTC
Permalink
Because our layers represent a sewerage system, which can be quite dense. The number of visible features on a given zoom level can range from 5000 to 25000. We currently use WFS for selecting (and WMS for drawing), but with these kind of numbers the performance of our web application is poor, very poor. That's why we are on the lookout for any alternatives/workarounds.

-----Oorspronkelijk bericht-----
Van: openlayers-users-***@lists.osgeo.org [mailto:openlayers-users-***@lists.osgeo.org] Namens Phil Scadden
Verzonden: vrijdag 12 december 2014 21:48
Aan: openlayers-***@lists.osgeo.org
Onderwerp: Re: [OpenLayers-Users] Alternatives to get rid of WFS layers

On 13/12/2014 7:00 a.m., Roel De Nijs wrote:
> One of the scenario's I am struggling with is selecting multiple features. In our current application we have a SelectFeature control using the WFS layers. So a user could select some features (using mouse clicks and/or box selection). Then these selected features could be used to execute another function in the application. But now these WFS layers don't exist anymore, so wondering what's the best approach to simulate this behavior.

Why not use WFS as well? I use WFS for selecting, WMS for drawing. If you are using Geoserver backend, you have WMS and WFS available for every layer.

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
***@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.
Phil Scadden
2014-12-15 20:04:59 UTC
Permalink
On 15/12/2014 11:37 p.m., Roel De Nijs wrote:
> Because our layers represent a sewerage system, which can be quite dense. The number of visible features on a given zoom level can range from 5000 to 25000. We currently use WFS for selecting (and WMS for drawing), but with these kind of numbers the performance of our web application is poor, very poor. That's why we are on the lookout for any alternatives/workarounds.
Where are the performance issues. Using GWC for caching should be key to
improving drawing performance (make sure tiled=true in WMS request) The
pain can be selecting. Consider using SLDSelect to show selected
feature, while simultaneous issuing identical WFS query requesting ONLY
attribute and not any geometry (list the attributes you want, excluding
shape). This can still be a very big payload to download. You have a
couple of options. The best is probably Paged WFS if you server supports
it. If it doesnt, you would have to write your own. Issue your WFS to a
servlet (I tend to build these into the proxy). The servlet requests
does the actual WFS request and then creates HTML to pass back to your
client.

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.
Roel De Nijs
2015-01-08 00:13:12 UTC
Permalink
Back from the festive season break.

Thanks for the clear and detailed explanation about how you can reduce the amount of WFS data being used in your webapplication. And I can already see some use cases in our application where using SLDSelect will definitely improve performance.

But about one use case I'm still pondering about is the selection of single features. The approach you described - using a (paged, if needed) table with only few attributes, and when the user selects a feature from this table request the shape of the feature to visualize (and select) can't be used in our application, because our (current) user experience is completely different. We don't have such a table and ifor some areas this table would contain 25000 features. And then it could be very hardand time-consuming to select just the 4-5 features you are interested in. It is much easier to select them on the map itself.
But probably the only option is to probably use SLDSelect as well here. When the user hovers on a given location, a list is shown (wfs request without shape) with only the feature ids. When a user "selects" this feature (e.g. selecting a checkbox in front of feature id), this feature is added to the "selected features" table. When an item is added/removed to this table, an SLDSelect request is executed to visualize the selected features on the map.
I think this is probably the best approach to allow users to select features and avoid the use of WFS data at all. I don't see any other viable alternative.
Hopefully it's not too much work, we are on a very strict deadline... So fingers crossed! :-)

Kind regards,
Roel

________________________________________
Van: Phil Scadden [***@gns.cri.nz]
Verzonden: dinsdag 16 december 2014 21:35
Aan: Roel De Nijs
Onderwerp: Re: [OpenLayers-Users] Alternatives to get rid of WFS layers

On 17/12/2014 6:13 a.m., Roel De Nijs wrote:
> For completeness: our WFS requests return only 2 attributes and the geometry of a feature, so no shape.
The geometry of feature IS what I mean by shape - what I mean is that
for line work, geometry can make the download quite large.
>
> The performance issues are at the client/browser. The browser is useless (hangs) for several minutes until all data is loaded and parsed. When loads of data are loaded the browser and the webapp becomes very slow. At a given point the browser freezes and the only thing you can do, is restart the browser.
Right. You have two performance killers - big load of data to download
and the fact that js is very slow (especially compared to server-side
java). As with all client/server apps, your design needs to focus on
making the server to as much work as possible and reserve client-side
for UI interactions.
>
> I remember from a previous thread on this list that WFS layers are true browser performance killers. And someone mentioned 500 vertices as a limit.
That would probably be me. I work in Geoserver mindset. Every layer can
be accessed by both WMS and WFS. I never use a "WFS layer" in OL - I
create a WFS protocol object for the WMS layer and use it for querying.
lay.wfsProtocol = new OpenLayers.Protocol.WFS.v1_1_0({
url: spatialQueryNode.url,
featurePrefix: spatialQueryNode.featurePrefix,
featureType: spatialQueryNode.featureType,
srsName: projstr
});
or lay.wfsProtocol = new
OpenLayers.Protocol.WFS.fromWMSLayer(WMSLayer,options)

I furthermore never let WFS return geometry if it could exceed the 500
vertex limit.

> We have 5000 to 25000 features at certain zoom levels. I wonder if creating a paged WFS will solve this issue. I guess it won't due to the huge number of features. And the resources a browser uses to load and parse the WFS data. The next version of our web application is also supposed to work on mobile devices (e.g. tablets). So adding wfs data seems not to be the way to go.
So long as you make sure that server is doing all the drawing (eg
SLDSelect which uses WMS for the drawing) and you are not dealing with
geometry client side, then paged WFS should help. It means when user
does a query (spatial or text) that returns a large no. of objects, then
they only see the attributes of say 10 at a time. If they are looking at
these attributes in a table, then can add a functions so when you click
on a row, it does another WFS query WITH geometry, and you draw the
object for that row. All the of selected objects should show on display
(handled server side). I doubt it is that useful for a user to see a
large no. of object at a time and chances are they will zoom in and
requery.

I am well aware that I am describing a lot of work without a lot of
direct support in OL.

--
Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St,
Private Bag 1930, Dunedin, New Zealand Ph +64 3 4799663, fax +64 3 477 5232

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.

[Congres publieke ruimte]<http://www.congrespubliekeruimte.be>
________________________________

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.
Phil Scadden
2015-01-12 00:24:13 UTC
Permalink
>And then it could be very hardand time-consuming to select just the
4-5 features you are interested in. It is much easier to select them >on
the map itself.

What I dont follow is why, if it would be easy to select them on the
map, could you not select them with WFS? The powerful feature of WFS is
that you can do spatial and feature-based queries on the server. If you
click on the map to select a feature you can see there (drawn with WMS),
then you do a spatial select in WFS to fetch only features that
intersect the click point. You only run into major problem if a single
click on the map could have a very large no. of features (or very big
geometries). In this case, then yes, WFS to return the FeatureID (and
enough other info for users to decide which were the ones they wanted),
into checkbox list would work. However, if you are selecting only
features intersecting the point where user clicks, then it should be a
small no. of features. If it returned an excessive count, you could
detect that. Then issue message say "too many features, please zoom in
and try again".



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.
Roel De Nijs
2015-01-16 01:33:25 UTC
Permalink
> What I dont follow is why, if it would be easy to select them on the
> map, could you not select them with WFS? The powerful feature of WFS is
> that you can do spatial and feature-based queries on the server.

You are absolutely correct! My interpretation of "easy" is based on our current user experience. In the current version all WFS data is loaded, so the user can select features very easily by just selecting them using a SelectFeature control (and can select multiple features by pressing the shift-button). So that's what I considered to be "easy", because to select 5 features the user has to click 5 times (holding down the shift button).
The scenario you describe is exactly what we will implement in the new version of our application: getting rid of all our WFS layers and do a WFS request to know which features are located on a given click point. And if the user wants to select the same 5 features, it will require (in the worst scenario) 10 clicks: 1 to execute the spatial select in WFS and a 2nd one to select the feature of his choice, as the WFS request could return more than 1 feature at that location). But this approach is definitely an improvement if you need to select 2-3 features which are located at the same point for example. With the WFS layer you could only select the feature of the top layer.

When a user wants to select a feature, he has to click on the map to fetch the features on the click point. Then he gets a popup showing some details about these features and he can select 1 or more of them. Currently I use a GetFeature control with a custom defined protocol to execute the WFS request and process the results. Is this the best control for this scenario? Or would a SelectFeature control (or another one) be more suitable for this job?

Kind regards,
Roel

________________________________________
Van: openlayers-users-***@lists.osgeo.org [openlayers-users-***@lists.osgeo.org] namens Phil Scadden [***@gns.cri.nz]
Verzonden: maandag 12 januari 2015 1:24
Aan: openlayers-***@lists.osgeo.org
Onderwerp: Re: [OpenLayers-Users] Alternatives to get rid of WFS layers

>And then it could be very hardand time-consuming to select just the
4-5 features you are interested in. It is much easier to select them >on
the map itself.

What I dont follow is why, if it would be easy to select them on the
map, could you not select them with WFS? The powerful feature of WFS is
that you can do spatial and feature-based queries on the server. If you
click on the map to select a feature you can see there (drawn with WMS),
then you do a spatial select in WFS to fetch only features that
intersect the click point. You only run into major problem if a single
click on the map could have a very large no. of features (or very big
geometries). In this case, then yes, WFS to return the FeatureID (and
enough other info for users to decide which were the ones they wanted),
into checkbox list would work. However, if you are selecting only
features intersecting the point where user clicks, then it should be a
small no. of features. If it returned an excessive count, you could
detect that. Then issue message say "too many features, please zoom in
and try again".



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
***@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-users
[Congres publieke ruimte]<http://www.congrespubliekeruimte.be>
________________________________

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.
Phil Scadden
2015-01-18 20:11:25 UTC
Permalink
>Currently I use a GetFeature control with a custom defined protocol to
execute the WFS request and process the results. Is this the best
>control for this scenario? Or would a SelectFeature control (or
another one) be more suitable for this job?

My code for doing this is quite old and definitely work in the "if ain't
broke, dont fix it" mode. I use a custom wfs protocol tied to
"featureadded" of a point Drawfeature control. I think at the time, it
was a way to give more control over the radius of selection. Since I
used near identifical code for "select by polygon" (use a polygon
handler instead of point handler in the draw control) it may simply have
been economy of effort. I have only used selectFeature control with
vector layers (kml) but I struggle to remember the decision-making
process around that.

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.
Roel De Nijs
2015-02-08 18:27:32 UTC
Permalink
After some experimenting I'm convinced the GetFeature control is definitely the best choice for the (our) job. Thanks for all the suggestions, they have put us definitely on the right track!

Now I just have 1 small question left. The layers the GetFeature control must query can be different with each and every request (because of zoom level & user can select/unselect layers as well), so I had to define my own protocol. What I have implemented really works great, but I was wondering if this is really how you are supposed to use the OpenLayers API. Would be great to get some feedback about my custom control.

var control = new OpenLayers.Control.GetFeature({
click : true,
clickTolerance : 10,
protocol : new OpenLayers.Protocol.HTTP({
format : new OpenLayers.Format.GeoJSON(),
url : URL,
read : function(options) {
options = options || {};
options.callback = function(result) {
if (result.success()) {
// process features
}
// reset the cursor
OpenLayers.Element.removeClass(this.map.viewPortDiv, "olCursorWait");
};
options.params = OpenLayers.Util.applyDefaults(options.params, {
layers : getDataLayerNames(),
request : "GetFeature"
});
OpenLayers.Protocol.HTTP.prototype.read.apply(this, arguments);
}
})
})

Kind regards,
Roel

________________________________________
Van: openlayers-users-***@lists.osgeo.org [openlayers-users-***@lists.osgeo.org] namens Phil Scadden [***@gns.cri.nz]
Verzonden: zondag 18 januari 2015 21:11
Aan: openlayers-***@lists.osgeo.org
Onderwerp: Re: [OpenLayers-Users] Alternatives to get rid of WFS layers

>Currently I use a GetFeature control with a custom defined protocol to
execute the WFS request and process the results. Is this the best
>control for this scenario? Or would a SelectFeature control (or
another one) be more suitable for this job?

My code for doing this is quite old and definitely work in the "if ain't
broke, dont fix it" mode. I use a custom wfs protocol tied to
"featureadded" of a point Drawfeature control. I think at the time, it
was a way to give more control over the radius of selection. Since I
used near identifical code for "select by polygon" (use a polygon
handler instead of point handler in the draw control) it may simply have
been economy of effort. I have only used selectFeature control with
vector layers (kml) but I struggle to remember the decision-making
process around that.

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
***@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-users
[Congres publieke ruimte]<http://www.congrespubliekeruimte.be>
________________________________

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.
Phil Scadden
2015-02-08 20:46:20 UTC
Permalink
Doesnt look that different to my code. I have equivalent to

your getDataLayerNames() as well do determine layer, but my app has concept of "search layer" to limit what layers are actually searched (since you could have hundreds in the map).


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.
Continue reading on narkive:
Loading...