This moves the feature cache from ol.layer.Vector to ol.source.Vector. These are the minimum changes required to maintain the existing functionality and make tests pass. More refactoring to come.
With symbolizer literals now being geometry type specific, we no
longer need the overhead to query the RTree separately for each
geometry type and render symbolizer groups by geometry type.
The geometry type index of the FeatureCache is no longer needed.
The filtering functionality of the FeatureCache's
getFeaturesObject method can be removed because it is no longer
used.
With this change, getFeaturesObjectForExtent may return null if
the source does not have data loaded for the provided extent.
A callback can be passed to getFeaturesObjectForExtent to get
notified when the requested data is available.
The canvas vector layer still has the (API candidate) `getFeatures` method that accepts an arbitrary expression (was filter). This, and the `getFeaturesObject` method under it are only used in the tests. The rendering code that was using filters is now calling `layer.getFeaturesObjectForExtent` with an explicit extent and optional geometry type.
The color names are more intuitive. And if we want to support pattern strokes or fills, we'll need additional proerties to represent other pattern properties.
With this commit test files provide namespaces (using goog.provide). This fixes the issue reported by @bartvde where goog objects cannot be used in Jasmine "describe" functions. It also frees us from having to add script tags for the test files in test/ol.html.
This commit is a cherry-pick of 19f7778.
The current draft of the [filter spec](https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html)
describes brightness, contrast, hue-rotate, and saturate functions that
roughly match our layer's setBrightness, setContrast, setHue, and
setSaturation methods. These changes make the range of our methods match
the corresponding functions in the spec. The one exception is the
brightness function. The spec says it has a range of 0 to positive infinity.
The WebKit implementation accepts a range of -1 to 1 (as of
https://github.com/WebKit/webkit/commit/8f4765e569). There's an open
(ticket)[https://www.w3.org/Bugs/Public/show_bug.cgi?id=15647] recommending
that the spec be changed to match.
I'm not stuck on having our methods match those of the filter spec, but the
parity would be nice.
These changes leave the WebGL map renderer "broken" (whacky colors). It would
be straightforward to update the current fragment shader to handle the new
range of hue, but the brightness, contrast, and saturation handling will
need to be reworked.
For inspiration, here are the color transformation
matrix calculations the WebKit filters:
8f4765e569/Source/WebCore/platform/graphics/chromium/cc/CCRenderSurfaceFilters.cpp (L64-80)
Conflicts:
src/ol/renderer/dom/domlayerrenderer.js
