Instead, we create a new tile grid whenever renderFrame is
called, no animation is active, and the resolution is not in the
tile grid already. This gives better rendering results because
we get vector tiles at native resolutions.
In JavaScript, keys of object literals are always strings, and
internal type conversions are performed. Now if we tell the
compiler that keys are numbers, we get inconsistent types when
iterating through keys. So instead we set the key type to string
and do a type cast to make the compiler happy. Note that we
could also do toString() instead of a type cast, but it would
add a performance penalty (see
http://jsperf.com/internal-type-conversion-vs-tostring-for-object-keys).
The projection validity extent is used to generate a sensible
set of default resolutions and a sensible default tile grid.
By making it optional, we can still generate defaults - with
zoom levels that are similar to the default web mercator zoom
levels (based on fitting the world on a single tile, even if the
projection is not available for the whole world).
Setting the renderer of the ten-thousand-points example to
WebGL should remove the need for this stub. This is basically
the same approach we took for all vector examples in master,
where we set the renderer to Canvas.
To avoid surprises for application developers, this change
creates a new getFeatures method. So it is clear now beforehand
whether features or feature info markup is returned. The result
is now also grouped by layer, so application developers always
have a link between a layer and the feature info it returns.
To make getFeatureInfo return markup for vector layers, this
change also adds a featureInfoFunction property to the vector
layer, which gives developers full control over how features are
rendered to feature info markup.
This change reverts the RTree API back to the original one (i.e.
insert() instead of put(), search() instead of find()), and
creates a new searchReturningObject() method that returns an
object keyed by UIDs.
It also adds missing tests for type restricted search and
searchReturningObject().
Not using Math.max and Math.min increases performance, and by
using ol.extent functions instead of RTree's rectangle
structures and calculations we can get rid of several functions.
This new implementation is based on
http://github.com/imbcmdth/RTree/, with only a few modifications
to add the optional type and provide the API of the previous
implementation.
There is still room for optimization, but this is such an
improvement over the previous RTree already that it's worth
bringing it in now.
By doing the type check before the intersection check, we can
save he intersection check for cases where we don't care about
type or have the specified type in a node.
On servers that report an incorrect content type for XML
documents, responseXML will be empty. In these cases we need to
use responseText instead. This change also prevents readNode
calls with empty data.
The reason for this change is that symbolSizes and maxSymbolSize
on the instance will be wrong as soon as the resolution changes
and cached tiles are used. It turned out that the approach used
now has several advantages: smaller symbolSizes objects, no need
to merge symbolSizes objects, and cache management for free (no
risk of memory leaks). Note that the symbolSizes and
maxSymbolSize for each tile are not strictly tile specific -
they represent the rendering pass that created the tile. This
has no negative side effects, and it has the advantage that
there is not a single additional loop needed to create these
structures.
With this change, hit detection for lines and points gets very
accurate, because the vector renderer instance keeps track of
line widths and point symbol sizes. After doing a bbox query in
the RTree, returned lines and points are evaluated against the
thresholds of their line width or symbol size. The KML example
with its different symbolizers now has getFeatureInfo too to
show this in action.
As suggested by @tschaub in #674, geom.pointInPoly is not needed
if we have geom.LinearRing#containsCoordinate. This pull request
also adds tests and documentation on the limitations of the
containsCoordinate method.
I think for now it is ok to keep geometry/topology functions as
simple as possible in ol3. If we decide to not rely on third
party libraries like jsts for topology operations, we can always
refine what we have and e.g. port topology operations over from
ol2.
This method is an entry point for getting feature information.
Renderers can use a hit canvas or defer to a layer (source) to
get matching features for a pixel.
For now this is only implemented for vector layers, and it uses
a bbox query because we cannot refine the result because of
missing geometry intersection functions yet.
When auto-generating the website using grunt in the
openlayers.github.io repo, we do not need to publish new docs
every time grunt is run, just because the timestamp is updated.
ahocevar