Instead of incrementing and then doubling, calculate the child tile range by doubling and then incrementing.
With this change, tile coord [0, 0, 0] has the four following children:
[1, 0, 0] [1, 1, 0]
[1, 0, 1] [1, 1, 1]
Without this change, tile coord [0, 0, 0] had the nine following children:
[1, 0, 0] [1, 1, 0] [1, 2, 0]
[1, 0, 1] [1, 1, 1] [1, 2, 1]
[1, 0, 2] [1, 1, 2] [1, 2, 2]
This reworks the changes in #2442 so we always include the version info, regardless of whether the module is run as main or not. This also addresses a few lint related issues.
Most of our uses of source extent were cargo cult programming. The source extent was seldom and inconsistently used. Instead, layers can now be configured with an extent, and layer renderers limit rendering (and data requests) to the layer extent.
For vector sources, the `getExtent` method returns the extent of currently loaded features (this was the case before and after this change). For tile based sources, we will likely want to allow easy construction of tile grids based on an extent (this is not possible before or after this change, but could be added later).
This has two nice consequences that can be seen in the wms-image.js and mapbuide-untiled.js examples:
* no images are requested when you browse outside of the layer extent
* when the layer extent is within the viewport extent, cached images are used since the intersecting extent is the same for multiple viewport extents
The ol-all.json and ol.json build configurations differ only in their use of the manage_closure_dependencies Compiler option. I don't think there is value in running both (there are plenty of other compiler options that we don't exercise in this same way).
Instead of running everything through the Compiler just to remove whitespace, we provide a build that is a simple concatenation of all scripts in dependency order. This build (ol-debug.js) should never be used in production (the same applies to the old ol-whitespace.js build). Instead, the intention is that it be used to aid in debugging during development.
If a `src` config is not provided, by default, all of the library sources are included. There is some special handling in the build task to make sure all library sources are included regardless of the path to the build config. When someone includes a `src` config, path patterns are assumed to be relative to the current working directory (unless overriden with the `cwd` config). So, when you use the `src` config, your config is no longer portable.
This allows other packages to depend on the ol3 package and get the build tools (devDependencies are not installed when they are transitive dependencies). The justification here is that the ol3 package becomes useful to other packages when you are able to run the build.js task. For this task to run all of its dependencies must be available.
Because we don't know if a new or modified file includes changes to the class hierarchy, we regenerate info for all sources any time any one has changed. An alternative would be to generate info first for the new or modified file and then (potentially) regenerate info for more source files in the class hierarchy, but this makes the generate-info.js task far more complicated.
The test.js task starts the development server and runs the tests in PhantomJS. As mentioned in the readme, when running the tests continuously during development, it is more convenient to start the dev server and visit the root of the test directory in your browser.
Later we can bring in Karma to drive PhantomJS and other browsers, but this simple "run once" task is useful for the CI job.
By default, all paths in the build config (e.g. externs) are assumed to be relative to the ol3 repo root. To make it so relative paths are resolved from a different directory, use the cwd option.
In addition, this change makes it so the `build.js` task can be run from another directory.
The closure-util package works on Node 0.8, 0.10, and 0.11 (as of this writing), but it requires an updated version of npm to install on Node 0.8. For the build to pass on Travis, we update npm before installing other dependencies. For others who are installing the openlayers package, nothing special is required for Node 0.10 and above. For users on Node 0.8, the openlayers package will only install with an updated version of npm. This can be installed with npm itself.
npm install -g npm # only needed on Node 0.8
Tim Schaub