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 [p.scad...@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.
_______________________________________________
Users mailing list
us...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-users
