The addFeatures method on layer is going to go away temporarily (so all feature adding will take advantage of shared vertices structures). Later we can accept feature arrays in parseFeatures and rename the method back to addFeatures.
The color names are more intuitive. And if we want to support pattern strokes or fills, we'll need additional proerties to represent other pattern properties.
We need a more flexible event system. We could have a VectorLayerEvent type and dispatch 'featuresadded' here. But listeners want features typically and perhaps extent. This won't be true for all vector layer events (suggesting a more specific VectorFeatureEvent type or something).
Previously, a lookup object containing start indexes was also used. This allowed us to remove arrays of vertices and properly update the start indexes for remaining coordinate values. In order to provide callers with stable identifiers and to work with arrays of integers alone, we cannot support a remove method. I think this is worth revisiting. Even if the array length cannot be changed in WebGL, we don't need to also impose the restriction outside. Instead, the WebGL renderer could be notified when array sizes change and update itself accordingly. I think there is more value in providing geometries with stable identifiers.
This common structure is used to store vertices for all geometry types. A slight optimization could be made by creating yet another structure to store point vertices - since these don't need to have a counts array (always 1). Creating a new structure would mean saving memory at the expense of more lib code to transport. The coordinate value lookups are not negatively impacted by using the same structure for points and higher order geometries. Since the first change above goes against my instincts, I'm not making this second change (to add another structure for shared point vertices).
Parsers that read features from strings, objects, or dom elements should implement the right interface. Among the read options is a callback that gets called after feature construction and before geometry construction. This callback is called with the feature and the geometry type and returns a shared vertices structure. The geometry is then constructed with this shared vertices structure before being added to the feature.
Instead of working with ol.Coordinate instances, transform functions work with arrays. This is in anticipation of using transform functions to transform large arrays of vertex coordinate values. The ol.projection.transform and ol.projection.transformWithCodes are slightly more convenient functions for dealing with ol.Coordinate instances. Whether we make this more consistent with the use of functions returned by ol.projection.getTransform is up for discussion.
Its not clear that we will be able to leverage the Float64Array. It may also be that the overhead of constructing these small arrays negates any benefit of faster access. And for all coordinate arrays, we'll need arrays that grow/shrink.
The first set geometry is considered the default. As an added bonus, we're back to a single argument constructor. Later, we could allow a schema to be set. This would be done before setting values (calling constructor with no args).
Without this, we are limited in the key names that we can accept from users. And because of compiler renaming, we don't know ahead of time what the limitations are (e.g. the key 'a' may clobber the 'set' method).
Tile ranges are inclusive. When getting the tile range for an extent, the top-right corner of the extent should be considered with a different intersection policy than the bottom-left corner.
If we have a gridded vector source, the grid should have something to do with the source data (e.g. the vector data is available in a regular grid). The vector layer renderer's internal grid is for rendering canvas tiles and doesn't have anything to do with the source.
When the dom renderer included logic to stretch tiles so that gaps were properly filled for fractional zoom levels, we needed to take this into account when getting a tile coordinate for a given coordinate and resolution. This was never the proper logic for a renderer that wasn't stretching occassional tiles (e.g. the WebGL renderer, the Canvas renderer, or the new DOM renderer).
Tim Schaub