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 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.
