By maintaining separate R-Trees for each geometry type, we cover
the most critical query from the canvas renderer at higher
speeds. Using the filter's own evaluate method, we can now also
serve arbitrary queries, but they won't be fast.
Still needs unit tests.
Also trying to reference features directly here instead of
storing feature ids in the index. We'll see if this is good when
we have an index for tile coords as well and want to filter
with multiple filters, accessing multiple indices.
* Tiles are now cut out of the sketch renderer in a separate
pass. This ensures that point features at tile borders appear
at both sides of the border. However, if such features get
added in a later tileRange rendering pass, tiles from a
previous rendering pass will still not have that feature.
* The tile canvas is only created once, and cloneNode(false) is
used to get a canvas for a new tile.
What we want in the end is vector tiles repeated just as raster
tiles. This change only avoids repeated tiles with the same
content being rendered and stored in the cache.
This needs more work still - see inline TODOs. It also has a
major bug - rendered vector features do not scale and do not
change their offset during panning. So only the initial view is
correct.
This source has features and provides tiles with the feature
geometries rendered, using the feature symbolizers. Needs more
work because it is still very unefficient, because it renders
all feature geometries to all tiles, and uses a collection of
features, which we do not have yet.
Previously, the TiledWMS source generated a resolutions array
derived from the world extent in meters, to match the default
Web Mercator resolutions of the map. This wouldn't work for
projections with distance units different than meters. It is
better to commit to a default resolutions array where zoom level
0 is the validity extent of the projection (not the Web Mercator
world extent!) at a 256 pixel tile size.
* The Map's private createProjection_ method is now a public
method of the Projection. It is also used by TiledWMSSource
to calculate the appropriate projection from the user
configuration.
* ol.Projection.addProjection now adds the transformation for
the source == target case. This makes it easy for the user
to create custom projection maps without including proj4js and
without adding a custom transformation, as long as the
userProjection equals the projection.
* The TiledWMSSource now uses the same default resolutions as
the map (i.e. the OSM resolutions)
* The modulo calculation for wrapping extents now works for all
grid configurations, by not calculating the number of columns
based on an assumption about the way the zoom levels relate to
resolutions.
* The wms-custom-proj example now shows how to properly
configure a custom resolution, i.e. by using the validity
extent of the projection as its extent.
The server does not send CORS headers, so we cannot use the
WebGL renderer. Since the layers use the projection's extent,
it is not necessary to specify the extent.
Setting the extent on a tile source now only means that tiles
won't be drawn outside that extent. Now the only way to specify
the origin of the tile grid is to provide a custom tileGrid. By
default, the grid origin is the top left corner of the
projection's extent.
The WMS used in the example does not send CORS headers (I think
not many WMS services do). It seems that the WebGL renderer
needs script access to the image data, so the example only works
with the DOM renderer in Firefox.
This ensures that maps with WMS layers with different extents
do not scale the tiles differently for each layer when the
default tileGrid is used. Note that it is always possible to
configure WMS sources with a custom tileGrid.
Now we use the browser's native dblclick event on pointer
devices, and we fire dragstart and dragend only if we're really
dragging, and not on mousedown/touchstart and mouseup/touchend.
We don't register two listeners for mouseup and touchend any
more. And instead of using the native click event on touch
devices, we react on touchend, to make clicking more responsive.
On pointer devices, the underlying native event of a dblclick
event is now a click event.
ol.overlay.Overlay can be used to bind DOM elements to a
coordinate on the map. It has positioning options to support
e.g. popups or image markers that have an anchor at the bottom
and an unknown size.
The overlayContainer stops propagation on mousedown and
touchstart events, so clicks and gestures on overlays don't
trigger any MapBrowserEvent. To make this work reliably, we now
only fire dblclick in mapbrowserevent.js when there was a
previous mousedown or touchstart. The default container for
controls is now the overlayContainer.
By doing so, application event handlers can preventDefault on the event, and interactions won't get the event any more. This means that interactions are default behavior that can be prevented by application event handlers.
Adding a new DragBox control and using it in the shiftdragzoom interaction to provide visual feedback of the zoom box. The control is nicely separated from the interaction - it only draws the box and does not perform any action.
This makes it possible to run examples hosted on hosts other than localhost. To get that version by default, debug.html has been renamed to index.html.
By handling click, dblckick and drag sequences in MapBrowserEvent, we can overcome closure issues with touch events. In particular, these issues were double drag events (from mousemove and touchmove) and a missing dblclick event on touch devices.
The default behavior of dragging and wheel zooming feels specific to 2D maps. So I think it makes sense to introduce a special type of controls (ol.control.DefaultControl) that implement default behaviors. This change also re-introduces the Navigatin control, which is a container for the default behaviors that were previously defined in the map handlers. Maybe this control needs to be renamed to Navigatin2D in the future, and there could be a different Navigation control for 3D maps.
If MapHandler subclasses could live without a map, it would make sense to have a constructor with a target and an element. But because the target is always the map, and the handler need to know about the map for performing default behavior, we always assume the map's viewport as element.
Not registering browser events as priority events makes it easy for controls to preventDefault or stopPropagation when events are registered on children of the map viewport element.
ahocevar