We are using OpenLayers 2.13.1 with the Dutch PDOK map implementation and were experiencing severe performance problems with WFS sources. I found a simple way to speed IE up by about a factor 2. It is still slow, but at least there is a significant improvement. Also it seems to use less CPU than before.
When profiling, I noticed that the most time is spent in the XMLHttpRequest.responseText property. Looking at the OpenLayers code, I saw that a version of https://code.google.com/p/xmlhttprequest/ is used. That class was intended to emulate XMLHttpRequest for Internet Explorer versions lacking a built-in XMLHttpRequest object. However, this should not be required in IE9 and newer, and Open Layers 2.x does not work properly in older IE versions. IE < 9 has become very uncommon anyway, even for the most convervative of our customers.
To make a long story short, here is how to speed up Open Layers 2 in IE:
- Start with OpenLayers.debug.js (unminified code)
- Look for the XMLHttpRequest.js code block
Replace the browser sniffing code at the start of the class by:
var bGecko = !!window.controllers, bIE = false, bIE7 = false;
Look for occurences of the text "ActiveXObject". Ensurte that all code depending on this is not executed. E.g.,
if (false /* window.ActiveXObject */) {
Finally, a fix is needed for a namespace problem in IE. Look for this function inside OpenLayers.Format.XML:
write: function (node) {
Add this code just before the closing bracket of the function:
if ("ActiveXObject" in window) // If IE is detected
data = data.replace(new RegExp('xmlns:NS\d+="" NS\d+:', 'g'), '');
After testing the fix, re-minify the code for release, e.g., by using Microsoft's Ajax minifier.
The replace statement was always needed to get WFS to work in IE11 and Edge. After disabling the XMLHttpRequest emulation, the same applies to older IE versions as well.
[edit]In addition to the above, we should fully avoid accessing request.responseText in IE. With the built-in XMLHttpRequst object, responseXML should always be available and valid. In my test, the original code spent about 8000 ms in responseText and 600 ms in responseXML. Actually, we do not need responseText at all in WFS.
Additional changes:
- In
function fGetDocument(oRequest) remove all code related to sResponse, leave only oDocument
- In
function fSynchronizeValues(oRequest) set oRequest.responseText = '';
- Replace
var response = arcxml.parseResponse(request.responseText); by var response = arcxml.parseResponse(request);
With these changes, no more time is spent in responseText, while the time spent in responseXML does not increase. I have also tested WMS and WMTS layers, they still work as before. I've repeated all tests in firefox and chrome, dit not find side effects.
[/edit]
Hope this helps,
Berend
In order to get the list of possible values using WFS the only way is to make a GetFeature request that asks for only the name in the propertyName parameter (it's a comma separated list of values).
This should work fine as long as all the features have unique values anyways, if you are looking to extract the list of unique values out of a dataset that has duplicates WFS is not the answer, it cannot perform aggregations, you should look in WPS instead, it has a gs:Aggregate process that can perform the aggregations for you.
Best Answer
This is how I would solve this problem.
Firstly publish the Satellite Image as a WMS service
Tile the service, either using the inbuilt GeoWebCache or something else.
Use the tiles in my OpenLayers Application