By simply defining the ol3 map as control on a GMaps map, we can
have a Google base map with arbitrary ol3 content on top. This
works with all ol3 renderers.
Reusing the iterator in a nested loop is not a good idea. And in
this case it is better to not have nested loops at all, because
we only have to create one array.
This is another attempt to bring master closer to the
vector-api branch. In anticipation of the ability to keep track
of modifications on ol.Object through a beforechange event
(d7e4be0), we will be able to manage originals on the
application level or in a separate component outside of
ol.Feature.
This reduces the API footprint of versioned parsers, because
only the base parser needs to be exported as symbol, and
versioned parsers can be accessed using the getParser() method.
This change also adds some type annotations for better type
checking, introduces different write options for writing
transactions and queries, and provides new writeGetFeature and
writeTransaction methods.
Instead of setting a dummy namespace, we can have setter methods
for the featureNS property to propagate them to sub-parsers. The
srsName is also a property which needs to be propagated to
sub-parsers.
This is one more step to bring the master and vector-api
branches closer together. I am well aware that the current
Modify interaction will probably be rewritten as part of the
vector-api effort, but with changes like this we will eventually
be able to remove ol.structs.RTree from master.
By providing a segment even for points, we have less distinction
points between points and other geometry types, and are able to
do the segment distance calculation also for points.
Now that the ol.renderer.Layer base class has a
getFeatureInfoForPixel method, we have to check whether the
source supports GetFeatureInfo, not the layer renderer.
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.
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.
The RTree cannot work with NaN coordinates. So instead of
preparing a vertexFeature before we know a coordinate, we now
lazily create the vertexFeature.
In combination with the additional squaredDistanceToSegment
check we can ensure that a future vertex is only created on one
segment per feature, and only on the segment that it appears on.
This change also renames the misleading dragVertices_ member to
dragSegments_.
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.
Our geometries are mutable, so they can be modified without
creating garbage by changing coordinates in place and calling
setGeometry afterwards. But this also means that we need to
create a deep clone of the coordinates.
Since we do not use the 'along' property anywhere, and the
resulting array returned by closestOnSegment could cause trouble
when working with 3d coodinates, now only the closest point is
returned, and the squared distance to the segment is calculated
by squaredDistanceToSegment instead.
When we start dragging, we first handle dragstart and then set
the INTERACTING view hint and the dragging flag. To end dragging
in a symmetric manner, we have to first reset the INTERACTING
hint and dragging flag, and then handle dragend.
This flaw becomes obvious when using an interaction where no
animation is performed after the interaction. This can be seen
in the style-rules example when using the dragzoom interaction
(i.e. zoom using a drag box): the vector renderer will not
render the new resolution, because the INTERACTING view hint is
still set when the zoom box dragend is handled.
ahocevar