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).
Make sure the object structure returned is not mangled by Closure
Do not use closure XHR or JSON in the example
Use Jasmine's async support in the test cases
Get rid of some backwards compatibility now that we have a fresh start
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.
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).
Previously, the findInterimTiles method was returning undefined if the min x/y coord for a tile range was already in the lookup. The return says it indicates whether all tiles for the given z are loaded. This change corrects the return.
This change also reveals a misunderstanding of the tile range returned by `getTileRangeForExtentAndZ`. The previous findInterimTiles method was treating max values as inclusive. This is intuitive. It looks like the method returns a range where max values are exclusive.
This simple expression constructor will be used for symbolizer properties and the layer will generate symbolizer literals for rendering by evaluating any expressions with a feature as the this argument and feature attributes as the scope. This allows generating labels that concatenate multiple attribute values together or displaying point symbols that are sized according to a population attribute divided by an area attribute, for example.
This implementation will not work in environments where the content security policy disallows the use of the Function constructor. This is the case on browser extensions. A more content-security-policy-friendly implementation would be to come up with a restricted grammar and write a lex/parser. This is the road I started down, but this verison is far less code, and I think the security policy limitations are minor at this point. This version will always be faster/lighter than a parser, so one is written in the future, it should only be pulled in where content security policy mandates it.
