As with vector layers and feature overlays, feature style can be set by calling
setStyle. Calling getStyle returns what was passed to setStyle. Internally, we call getStyleFunction.
The setStyle method accepts a single style, an array of styles, or a style function. The getStyle method returns what was set. Internally, we use the getStyleFunction method which always returns a function. When calling setStyle, a change event is dispatched (fixes#1671).
It would be nice to also test the following:
it('does not return user set property with the same name', function() {
var feature = new ol.Feature({
whatever: 'some value',
styleFunction: 'another value'
});
expect(feature.getStyleFunction()).to.be(undefined);
});
Unfortunately, in uncompiled code (or if we export `setStyleFunction`) this does not work. Same goes for user set `id` properties (this will set our internal `id_` property). See #1672.
Features are records with any number of user set values. Separate from this, we rely on feature properties like the feature identifier and feature style. The two (user properties and our internal properties) should not be mixed.
The feature with undefined id is a multi-polygon representing all countries. Instead of rendering all multi-polygons with a lower z-index, we just avoid rendering this single feature.
The projection option for vector file sources currently has no good meaning. The reprojectTo option is used to set the projection for cached features. This change makes it so the projection option is used for this purpose. The getProjection method (not currently exported) can then be used to get the cached feature projection.
This also removes the default of 'EPSG:3857' for vector file sources. If a projection is not configured, features will not be transformed.
This removes geometry specific change events. Since geometries are mere observables, we only get generic change events. To minimize changes in other places, as a workaround, we cache geometry bounds on features. This is not the way things should be long term, but the objective is to remove the geometry specific event.
Where an enum value is used as an event type, it should be alllowercase (to follow DOM events). Property names should be ALLUPPERCASE in this case (just as camelCase and PascalCase are converted to CONSTANT_CASE).
Any event target can be used to dispatch generic goog.events.Event instances with an arbitrary type. In cases where we dispatch custom events, we should not use type values that collide with those used for generic events (at least internally). This allows listeners a better chance of knowing what kind of argument they will receive.
As subsequent change will clean up the enumeration and add a bit more consistency.
If you know ahead of time that you only want to listen for changes for a specific property, the foo:change type events can be useful. If you want to listen for changes on all properties, the change event becomes more useful if it provides information on what changed. And the beforechange event allows listeners to access values before they change.
This adds a bit more inconsistency to the library, but we didn't have complete consistency before. Almost all existing string enum values are lowercase (a couple are camelCase and one is dash-separated). The closure library isn't consistent either (with case for enum properties or values). I imagine this could be justified in saying someone could blindly use GeoJSON type values in places, but in the end, you'll need to read the docs before guessing right.
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.
Tim Schaub