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.
This reverts 4d619d71b1 (see #1527), going back to what we had after e13075f6ff (see #881).
To avoid the 404 in the hosted examples, the css is copied to the same relative path when hosted as during development.
As with vector layers and feature overlays, feature style can be set by calling
setStyle. Calling getStyle returns what was passed to setStyle. Internally, we call getStyleFunction.
The setStyle method accepts a single style, an array of styles, or a style function. The getStyle method returns what was set. Internally, we use the getStyleFunction method which always returns a function. When calling setStyle, a change event is dispatched (fixes#1671).
It would be nice to also test the following:
it('does not return user set property with the same name', function() {
var feature = new ol.Feature({
whatever: 'some value',
styleFunction: 'another value'
});
expect(feature.getStyleFunction()).to.be(undefined);
});
Unfortunately, in uncompiled code (or if we export `setStyleFunction`) this does not work. Same goes for user set `id` properties (this will set our internal `id_` property). See #1672.
Features are records with any number of user set values. Separate from this, we rely on feature properties like the feature identifier and feature style. The two (user properties and our internal properties) should not be mixed.
The feature with undefined id is a multi-polygon representing all countries. Instead of rendering all multi-polygons with a lower z-index, we just avoid rendering this single feature.
The projection option for vector file sources currently has no good meaning. The reprojectTo option is used to set the projection for cached features. This change makes it so the projection option is used for this purpose. The getProjection method (not currently exported) can then be used to get the cached feature projection.
This also removes the default of 'EPSG:3857' for vector file sources. If a projection is not configured, features will not be transformed.
This removes geometry specific change events. Since geometries are mere observables, we only get generic change events. To minimize changes in other places, as a workaround, we cache geometry bounds on features. This is not the way things should be long term, but the objective is to remove the geometry specific event.
Where an enum value is used as an event type, it should be alllowercase (to follow DOM events). Property names should be ALLUPPERCASE in this case (just as camelCase and PascalCase are converted to CONSTANT_CASE).
Any event target can be used to dispatch generic goog.events.Event instances with an arbitrary type. In cases where we dispatch custom events, we should not use type values that collide with those used for generic events (at least internally). This allows listeners a better chance of knowing what kind of argument they will receive.
As subsequent change will clean up the enumeration and add a bit more consistency.
If you know ahead of time that you only want to listen for changes for a specific property, the foo:change type events can be useful. If you want to listen for changes on all properties, the change event becomes more useful if it provides information on what changed. And the beforechange event allows listeners to access values before they change.
This adds a bit more inconsistency to the library, but we didn't have complete consistency before. Almost all existing string enum values are lowercase (a couple are camelCase and one is dash-separated). The closure library isn't consistent either (with case for enum properties or values). I imagine this could be justified in saying someone could blindly use GeoJSON type values in places, but in the end, you'll need to read the docs before guessing right.
Tim Schaub