This separates the action of requesting an extent to be loaded from the action of requesting cached features. The renderer (or any other consumer of a vector source) calls load to request a data extent. A `featureload` event fires when new features are loaded. The renderer (or any other consumer) separately asks for cached features given an extent. This vector source only loads features once, but this separation will also work with sources that make multiple requests for data in different extents.
This also removes the `data` option from the vector source in favor of a `features` option. Since we no longer have shared data structures for geometries, people can manually create features and pass them to a vector source. The `addFeatures` method is exported as well. This is used to add features to a source that don't have a representation on the "remote" (or server).
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.
In b8a9aeb14e a return was added to `ol.renderer.Layer.prototype.getFeatureInfoForPixel`. The `ol.renderer.canvas.VectorLayer.prototype.getFeatureInfoForPixel` method needs the same.
Previously, if a layer didn't have a `getFeature*ForPixel` type method, the loop count would be decremented. This means that all layers would not be considered. Instead, the callback count should be incremented before requests are made and decremented in the callback.
The tests revealed that polygons can be drawn with counter-clockwise exterior ring order. In the polygon constructor, we enforce clockwise winding for exterior rings. So after drawing, we pass polygon coordinates back to the constructor before adding feature to the target layer.
This allows us to cast single-part geometries to multi-part types before adding features to the target layer. This doesn't yet allow for drawing multi-part geometries with multiple parts. That can be handled separately.
The other "up" type listeners (for touch and pointer) do not set this to null. This event can be of use to a click listener that might want to compare the down position to the click event's position.
The relayEvent_ method wraps goog's browser events in our MapBrowserEvent. This allows interactions to deal with real browser events in addition to our emulated events.
Note that with and without this change, the pixel provided to the ol.source.wms.getFeatureInfo function will be wrong if the view has non-zero rotation.
This key is registered for "Not-for-Profit" use by OpenLayers as a project of OSGeo - a 501(c)(4) organization.
See the complete [Terms of Use](http://www.microsoft.com/maps/product/terms.html) under the Eduction or Non-Profit Organization Use section.
The floor before setting the transform ensures that we translate by integer pixels for odd and even dimenstions. The round before drawing the image ensures pixels are aligned.
Rendering performance degrades as the context lineWidth increases when calling lineTo many times for the same pixel coordinate. This appears to be a widespread performance issue and is very clearly improved by only calling lineTo when in a new pixel coordinate.
Previously, the tests were using eql to make assertions about matching geometries. This is inappropriate for structures with circular references (as with goog.events.EventTarget);
Vector events include features and extents. In the case of feature change events, the extents array will include old and new extents for features with modified geometries.w
The goog.events.EventType.CHANGE type is already dispatched because layers are ol.Object instances. To allow people to register for vector layer specific events without also having listeners get called with more general ol.Object change events, we need to give the types unique values.
In the typical sequence of parse-transform-render the most efficient place to transform coordinate values is deep within the parser immediately after values have been read (this would avoid a second pass over whatever structure is used to back geometries). To accomplish this transform during parsing, we could add back parser read options to pass the transform function around.
Until then, a transform method on geometries is straightforward to implement. This means we do a second pass through coordinate structures to transform, but this is typically done only once immediately after parsing.
Tim Schaub