This reverts 4d619d71b1 (see #1527), going back to what we had after e13075f6ff (see #881).
To avoid the 404 in the hosted examples, the css is copied to the same relative path when hosted as during development.
This commit also removes the click listener, which was used for touch devices. The click listener will be added back when the lib will correctly handle clicks on touch devices.
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.
The original decision to avoid index.html was because it only works with a build step. Since we've all accepted a build step, the more sensible name is index.html. Without this change, every hosted example has a link to http://openlayers.github.com/ol3/master/examples/example-list.html which 404s.
It looks like this approach will work well for panning (as anticipated). For animated zooming, it is not going to work as is. It looks like the canvas tile generation is too much for this type of animation loop. Though there are clearly still areas for optimization:
* Don't create new tiles while animating between zoom levels. Using existing tiles only while animating should bring a significant performance gain.
* Simple spatial index for tiles - each tile coord in the matrix could have a feature lookup object (keyed by id). This needs to account for rendered dimension (as witnessed by the point being cut by a tile). Given that the current example uses only three features, adding the spatial index should only be a minor improvement.
* Reuse a fixed set of canvas tiles that are generated at construction (and increased/decreased with view size changes).
* If a fixed set of tiles is not used, at least new ones could be cloned from existing ones (minor).
* Do some profiling to look for more ideas.
In addition, world-wrapping needs addressed. I don't think this renderer is the right (or at least the only) place to address this. And the cache of tiles needs to be managed for real. But hey, at least we've got a working tiled vector renderer now.
There is a ton of room for optimization here. The vector layer renderer should only render dirty areas and could maintain a cache of rendered canvas tiles. The vector source could have a simple spatial index for features (by tile coord). Need to also discuss how to work with this animation framework (to avoid the excess work while waiting for tiles to load on every other layer).
