This is based on the assumptions that
* our examples always goog.require something ol.* (otherwise why have the example)
* our examples only goog.require exportable symbols or "namespaces" for exportable symbols (e.g. ol.control for the defaults function)
* we have an API doc page for each exportable symbol and each "namespace" that has exportable symbols (e.g. ol.Map.html and ol.control.html)
It may be that this assumption proves to be wrong, but it would be nice to avoid the extra network traffic and layout shifting when examples load.
When we create the examples, we know exactly which specific `ol.…` symbols
we `goog.require(…)`. We can create links to the API documentation of these
symbols automatically.
Please write blog posts, create tutorials, or develop workshops that show off cool ways to develop applications that use OL3. The examples should be kept very simple. This download functionality is neat, but it's really a gratuitous use of non-map related functionality. While it does demonstrate the use of `format.writeFeatures()`, this is buried in too much additional code that is not accessible (buried in resources/common.js) and not really related to mapping things. If we want to have examples that demonstrate how formats can be used to serialize features, a simple textarea would suffice as the target.
The `check-examples` target fails on Travis without this option. We get "SSL handshake failed" when loading resources via HTTPS with whatever the default SSL protocol is.
In addition, as a precaution, the --ignore-ssl-errors option is set to true in case anybody adds a resource with an invalid certificate. This option does not get around SSL handshake errors.
Method ol.proj.equivalent used only reference equality check ===
That doesn't work for basic checks of two strongly equal projections
For example, `EPSG:4326` and `EPSG:4326`
In this case method searches similar proj in ol.proj.transforms_ mapping
And it finds it if proj is default and not custom
But in case of custom proj `EPSG:3413` it doesn't find it