The Hash control was attempting to use precision -Infinity for zoom level zero. Now it uses precision 0. The Queue's image method was not passing the loaded image to the callback function, unlike the other text, xml and json methods. Having the image available to the callback allows the implementation of post- processing with canvas, for example.
When these generated files were not part of the repository, it made sense to include the HEAD revision id, so that we knew how the files were built. These IDs are no longer needed as Semantic Versioning gives us the same information (and more!). Furthermore, now that the generated files are part of the repo, the HEAD revision would be the commit prior to the one that included the generated files, which is both confusing and causes spurious modifications if the files are rebuilt after pulling. Note: since this is a minor comment-only change, I'm not bumping the version.
That was a SemVer joke, because this isn't a major new release in the vernacular sense, but there are some necessarily backwards-incompatible (and hence major) changes. The "major" changes are: `layer.size` replaced by `map.tileSize`. `layer.size(null)` replaced by `layer.tile(false)`. `map.pointCoordinate` no longer takes a `tileSize` argument. `map.coordinatePoint` no longer takes a `tileSize` argument. The tile projection no longer has a `coordinateLocation` method. The reason I could not make these changes as a patch version is that there was a fundamental misinterpretation of tile size (at sizes other than 256x256). In v1, Polymaps only supported tile sizes that were powers of 2, and larger tiles would cover a greater location area; for example, a 512x512 tile would cover Earth at zoom level 1. In v2, the size of tiles does not affect the mapping between locations and coordinates. So, there is always one tile that covers Earth at zoom level 0, 4 at zoom level 1, and so on. Thus, Polymaps now supports arbitrary tile sizes. Furthermore, the tile size is defined on the map object, rather than the layer, because the tile size affects the mapping between coordinates and points and should ideally be consistent across layers. (However, if it's not, you can always scale the tiles up or down to fit.) Now that the tile size does not affect the conversion between locations and coordinates, the `coordinateLocation` and `locationCoordinate` methods no longer take a `tileSize` argument. The `map` class now also has "static" `coordinateLocation` and `locationCoordinate` methods. The `locationCoordinate` method returns a coordinate at zoom level 0 (unlike the instance method, which returns a coordinate at the map's zoom level). You can use these methods in lieu of the old `coordinateLocation` method that was part of the tile projection (the second argument to the layer's `load` function). The reinterpretation of tile sizes changes how "world-size tiles" are implemented for GeoJSON layers with hard-coded features. Now you can disable tiling on a layer by calling `tile(false)`, which is demonstrably more obvious than `size(null)`. Better yet, the new implementation of non-tiled layers fixes the buggy behavior of v1, which had a difficult time crossing zoom level 8 and dealing with zoom transforms on top of world-size tiles. Rejoice! A few additional goodies in this commit: The `geoJson` layer now supports an optional `fetch` function to the constructor. This function is called to load the GeoJSON data and takes two arguments: a string containing the URL to load, and a callback function to invoke once the GeoJSON data is available. This feature allows you to write a GeoJSON transcoder from other formats! As an example of GeoJSON transcoding, see the new "kml" example. It loads a KML file and converts it to GeoJSON, and then gets displayed as a layer. KML support is still experimental (and only very rudimentarily supported, at the moment), so for now KML support lives in the examples directory. Depending on demand we will probably implement more support for KML and make it part of the official release. The `queue` class now supports fetching XML (as needed to support KML). Lastly, there's a new "world" example which shows a nice choropleth world map using a non-tiled layer. It would certainly be nice to have multi-resolution GeoJSON tiles for world country boundaries, but this sufficies for a simple world map!