Add `ol.ObjectEvent` for changes to `ol.Object` properties. Previously, `ol.Object` dispatched instances of `goog.events.Event` with type `change`. Now `ol.ObjectEvent` instances will be dispatched on property changes. The events include a `getKey` method to get the name of the property being changed. The `beforepropertychange` type event is fired before a property value changes, and the `propertychange` type event fires after the property value changes.
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.
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).
The wmts-from-capabilities example should focus on creating a
WMTS source from capabilities, so it should not distract by
configuring a projection that does not need to be configured.
The WMTS capabilities document of the Vienna map has changed. It
no longer defines a tileset for EPSG:31256, so it can be parsed
without having Proj4js and a projection definition for
EPSG:31256.
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 only feature on the temporary layer is now the
vertexFeature, and the temporary layer's style is dynamically
changed to the style of the layer whose segment is being edited
(the topmost layer if more than one segment are being edited).
With this simplification, we can also put all segments on a
single RTree. Finally, we no longer rely on structures set on
layers - all we need is now on the instance itself.
This refactoring also changes the way we define layers to
participate in modification - by using an array or a filter
function, or assuming all layers if no layers property is set.
This is a first draft. The way geometry changes are handled for
now is a bit clumsy. Both updating the feature cache RTree and
making the layer aware of feature and geometry changes could be
handled in a smarter way if these changes would be made through
the layer instead of directly on the geometry or feature.
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.
This adds a new ol.source.MapGuide class that is initialized with an options object that can contain the following values:
- projection: The projection of the Map Definition in EPSG format
- url: The mapagent URL
- useOverlay: Determines whether the GETMAPIMAGE (false) or GETDYNAMICMAPOVERLAYIMAGE (true) will be used for requesting the map image. When using GETMAPIMAGE, you must include a valid MAPDEFINITION parameter in the 'params' option property. When using GETDYNAMICMAPOVERLAYIMAGE, you must include a valid SESSION and MAPNAME parameters in the 'params' option property.
- metersPerUnit: A required value used for calculating the map scale needed by the image request. This value can be calculated using the MapGuide Web API or obtained through the new CREATERUNTIMEMAP operation in MapGuide Open Source 2.6
- params: A set of key-value pairs to append to the mapagent request
- extent: The bounds of the layer
An example is included to demonstrate this new layer source. Like ol2, this example uses the MapGuide Server on data.mapguide.com
