With this commit we register a change listener at a time when we are guaranteed that the listener will be called. In this was we don't need to remove listeners when the tile is dropped from the tile queue. And to avoid busy-polling between IDLE and LOADING we rely on the map to call requestRenderFrame when new tiles change to LOADING from IDLE.
We need a more flexible event system. We could have a VectorLayerEvent type and dispatch 'featuresadded' here. But listeners want features typically and perhaps extent. This won't be true for all vector layer events (suggesting a more specific VectorFeatureEvent type or something).
This change adds a lot of flexibility to working with tile
layers: Sources where the server projection or tile grid do not
matter can now be constructed without specifying a projection or
tile grid.
The tileUrlFunction/imageUrlFunction now also creates updated
URLs when the params of the layer change, so things like
mergeNewParams in ol2 will be possible.
A nice side effect of this whole change is that there is no more
duplicated code between tiled and single image WMS layers.
While I was at it, I also fixed a WMS 1.1.1 axis order issue
and incorrect STYLES params (STYLES=& instead of STYLES&).
Now vector layers can have a style. ol.Style instances have an
apply method to get the symbolizer literals for a feature. If the
layer does not have a style defined, there is also a static
applyDefaultStyle function on ol.Style to get the default
symbolizer literals for a feature. The vector layer also got a
groupFeaturesBySymbolizerLiteral method, which returns an array
with features grouped by symbolizer, as needed by the canvas
renderer.
If we have a gridded vector source, the grid should have something to do with the source data (e.g. the vector data is available in a regular grid). The vector layer renderer's internal grid is for rendering canvas tiles and doesn't have anything to do with the source.
We should discuss whether post render functions must be run after each render frame or not. If these can be run after multiple render frames, it would make sense to increase the timeout. As it is, it looks like post render functions are run for every render. Hard to see what the benefit is in this case.
