The change in #2098 made it so a feature's geometry could be undefined. This is consistent with the return type for the getGeometry method. Where calling code needs to ensure that it has a geometry instance, it can use instanceof, goog.isDefAndNotNull(), or test for a truthy value.
A feature can have a geometry whose value is an ol.geom.Geometry instance or null. A feature can also have no geometry property. By default, a feature has no geometry property. To set a geometry, one can be passed to the constructor (including null) or passed to setGeometry().
Any of minResolution, maxResolution, minZoom, or maxZoom can be used to constrain the view resolutions. Resolution options are given precedence over zoom options.
Whitespace builds are still painful to debug. Skipping the compiler altogether and simply concatenating sources is a better option for development and debugging. By ommitting the `compile` option in a build config, the output is "uncompiled" - a straight concatenation of all sources in dependency order.
This task generates build related metadata for the library based on doc annotations. Since it is about more than writing out exportable symbols, it makes sense to have a more general name.
Previously, ol.geom.Polygon was a transitive dependency of ol.proj (since ol.proj requires ol.sphere.NORMAL, and all spheres were capable of generating circular polygons). Instead, ol.proj should be lower-level. Since it deals only with coordinate arrays, it shouldn't depend on all of the geometry code.
By adding a static `circular` function to `ol.geom.Polygon`, the dependency tree makes more sense. If you want to create a polygon that approximates a circle on a sphere, you require `ol.geom.Polygon` and `ol.Sphere` (or one of the constants).
This makes room for geometries to have a `transform` method that takes projection-like arguments (meaning that `ol.geom.Geometry` will require `ol.proj`).
This gives more consistency with ol.proj.applyTransform, allowing us to add a more convenient ol.extent.transform method that takes projection-like arguments.
Since async and htmlparser2 are used by the postinstall task, they need to be listed as dependencies. These will get installed when ol3 is a dependency of another project.
With this change, the only two remaining generated scripts are build/exports.js and build/test/requireall.js. Both are only required by Plovr. With the Node based build task, a temporary exports.js file is created. The Node based server can be used to run the tests without build/test/requireall.js.
Because ol.proj.EPSG4326 et al. extend ol.proj.Projection which has exportable methods, these constructors need to be exportable as well (e.g. so ol.proj.EPSG4326.prototype is defined in exports.js when calling goog.exportProperty on getCode etc.). If we really don't want these to be exportable, they should be removed or made private (and named like ol.proj.EPSG4326_) for internal use only.
The generate-symbols.js task runs JSDoc on source files. Because this takes a long time (13s) to run on the whole library, the resulting symbols file includes additional metadata to make it possible to do incremental symbol generation on subsequent runs. The 'path' and 'extends' metadata for a symbol are used to determine what needs to be regenerated.
There are cases where a private class may inherit an exportable member (e.g. ol.DebugTile_#getTileCoord comes from ol.Tile#getTileCoord). We want to avoid making these exportable.
This runs JSDoc with the "symbols" config, providing a list of source files that have been changed since the previous run. The output is used to generate a symbols.json metadata file containing all exportable symbols info. A separate task will be run to generate the exports.js file. These same metadata files will be used by a build tool.
This generates info for all symbols annotated with "@todo api" (when Plovr is replaced, this will become "@api"). Generated metadata is written to stdout. A separate process will handle the output.
The externs/olx.js script includes @typedef annotations for objects that are used in the library. When compiling the examples together with the library, we need these @typedef annotations. In this same case, we don't need the object property names to be treated as externs (they can be safely renamed).
The single externs/olx.js file describes all of the "options" objects we accept in our constructors. The @typedef annotations are used by the compiler for type checking. The @type annotations include documentation for individual options and serve as externs when compiling a profile of the library. When compiling an application together with the library, the externs/olx.js file is included as one of the sources to provide the @typedef's without generating externs.
If we want to maintain multiple src/*.externs.js files instead of one large externs/olx.js file, we can. But while we are still using Plovr, it makes for easier build configurations to have one file.
This removes the build tasks that generated the build/src/external/src/externs/types.js and build/src/internal/src/types.js files as those are both replaced by the single externs/olx.js file.
This strips markup from elements with id attributes that we care about: title, shortdesc, tags. This will only work for people who use `npm install && npm start` to browse examples. The other example parser doesn't strip this markup, so it should still not be used in these elements.
* closure-util - Driving the compiler, not watching spurious files
* async - Bugfixes not related to our use, but this may sidestep the Travis errors we're seeing
When we have only a single point, we want to make sure it gets added (fixes#1821).
Because this code doesn't differentiate coordinates that are part of a linestring or linearring from those that are independent points, we always add the first segment (or pair of points). In addition, coordinates for segments are appended whenever they represent a change in relationship with respect to the extent. This keeps the code simpler for handling fills and properly capturing intersection points for linestrings. This could be modified to save a few extra coordinates, but it provides for simpler code at a very minimal cost.
Segments that intersect the replay group's extent are drawn. Any segment that represents a change in coordinate-extent relationship is drawn. This maintains the left/right relationship (or cross product) between points in the rendered extent and every rendered segment.
Still left undone: clip the replay group's rendering to the max extent.
This works at resolutions where simplification is significantly reducing the number of points in the line. At high resolutions, navigation becomes unresponsive. Limiting draw instructions to a replay group's extent will fix this.
Chris Veness' discussion of using the spherical law of cosines (http://www.movable-type.co.uk/scripts/latlong.html) suggests it gives well-conditioned results "around 1 metre" in JavaScript (this assumes a sphere with 6,371km radius).
In Chrome 33, Math.pow(Math.cos(Math.PI / 4), 2) yields 0.4999999999999999. When we take the arccosine of twice this, we get something significantly different than zero. Multiplying by 6371 means we can't assert that this is within 1e-9 of zero.
The Vincenty formula can fail to converge for antipodal points (see http://en.wikipedia.org/wiki/Vincenty's_formulae#Nearly_antipodal_points), so those test cases are removed. These tests fail with the latest V8 due to optimization of trig functions with lookup tables. For example, Math.cos(Math.PI / 2) is no longer calculated based on the value of Math.PI / 2 (which is different than the actual value of π / 2). Instead, values close to multiples of π / 2 are determined to be 0 (which is arguably what you want). Previously the tests were relying on very small numbers being returned in this case.
Tim Schaub