In core.js we currently wrap the functions in an immediately-called anonymous function. This allows having private functions, which are functions local to the anonymous function.

During today's hangout meeting we decided to remove the anonymous function and use the @private annotation for private functions instead. The main argument for that is to make it possible to unit-test private functions.

This causes build errors in 3 places:

• camera.js:320
• camera.js:374
• core.js:27

This integration is developed in an open source layer built ontop of ol3js as ol3js is not bound to a specific 3D globe. This layer should allow to provide a common and efficient way to have ol3js and cesium working closely together.

Technical issues

• How to keep both ol3js and cesium synchronized?

  • Apply vector transformations (diff from current state) each time a context change?
  • Compute from scratch a new state from the new context?

• Save computing resources

  • disable rendering of the underlying map or globe if it's hidden by the overlayed one
  • still preserve context synchronization

• Smooth transition needs to know the elevation of the destination point of the camera

  • cesium provides an asynchronous method, synchronous planned for August
  • cesium provides in a dev branch a specific method. TDB: WHERE?

• Cesium camera entering the terrain

  In regards to the camera falling through the terrain, you will want to upgrade to Cesium 1.0 in August, which will include Camera/terrain interaction (see CesiumGS/cesium#1817 and CesiumGS/cesium#1670).

Idea: If a user adds a WMS/TMS/WMTS layer to ol3.js map it should also be added to the cesium globe.

Known limitations: for now, ol3js and cesium don't support the same layer type:

• ol3js: WMTS, WMS, OSM, Bing
• cesiumjs:
  • WMS (this is not a single request, but multiple WMS tiled requests, but no WMS-C, can't specify the grid)
  • TMS,
  • OSM,
  • Bing,
  • ESRI

WMTS issue, see: CesiumGS/cesium#1890

Our client found something missing in the raster synchronizer:

The 2D map responds to the change event fired by the source in ol.source.TileWMS#updateParams, but the raster synchronizer does not. The raster synchronizer should update the layer on the globe in response to source change events (params, url, etc).

There are still some type checking errors:

[java] ol3-cesium/src/camera.js:104: ERROR - actual parameter 1 of ol.Observable.prototype.unByKey does not match formal parameter
[java] found   : *
[java] required: (goog.events.ListenableKey|null|number)
[java]     this.view_.unByKey(this.viewListenKey_);
[java]                        ^
[java] 
[java] ol3-cesium/src/camera.js:257: ERROR - inconsistent return type
[java] found   : (Array.<number>|null)
[java] required: (Array.<number>|undefined)
[java]   return this.fromLonLat_([goog.math.toDegrees(carto.longitude),
[java]          ^
[java] 
[java] ol3-cesium/src/camera.js:315: ERROR - actual parameter 1 of olcs.Camera.toLonLat_ does not match formal parameter
[java] found   : (Array.<number>|null|undefined)
[java] required: (Array.<number>|null)
[java]   var ll = this.toLonLat_(this.view_.getCenter());
[java]                           ^
[java] 
[java] ol3-cesium/src/camera.js:346: ERROR - actual parameter 1 of olcs.Camera.toLonLat_ does not match formal parameter
[java] found   : (Array.<number>|null|undefined)
[java] required: (Array.<number>|null)
[java]       goog.math.toRadians(this.toLonLat_(this.view_.getCenter())[1]));
[java]                                          ^
[java] 
[java] ol3-cesium/src/core.js:509: ERROR - Function ol.style.Image.prototype.getImage: called with 0 argument(s). Function requires at least 1 argument(s) and no more than 1 argument(s).
[java]     var image = imageStyle.getImage();
[java]                 ^
[java] 
[java] ol3-cesium/src/core.js:521: ERROR - actual parameter 1 of Cesium.BillboardCollection.prototype.add does not match formal parameter
[java] found   : {image: (HTMLCanvasElement|HTMLVideoElement|Image|null|string), position: Cesium.Cartesian3}
[java] required: {image: string, position: Cesium.Cartesian3}
[java]       billboards.add({
[java]                      ^
[java] 
[java] ol3-cesium/src/core.js:746: ERROR - "function (this:ol.Feature, number): (Array.<(null|ol.style.Style)>|null)" must be called with a "this" type
[java]       style = featureStyle(resolution);

Required is:

ol.interaction.DragZoom (while holding Shift)
ol.interaction.DragBox - correctly firing ‘dragend’ and passing ‘geometry’

(visual interaction to be running only on ellipsoid - it is impossible to draw polygons on terrain, see: #12)

Roll of the camera has been disabled in the initial implementation (#16) together with the free look user interaction which is setting the roll on camera internally. The user can't set the roll with the existing interaction on the globe.

Roll explained in illustration from #8:

(Update: the original image is in: http://data.webglearth.com/doc/webgl-earthch3.html#x4-240003.6 and embeded in #16)

The reason is that the alogorithm for synchronization of the 2d and 3d view will get more complicated, if roll is implemented, because roll is influencing also heading (=rotation in ol3) and this must be taken into account in the calculations. It is doable, just not yet done.

To introduce the roll and free look the olcs.Camera.prototype.updateView must be improved to ensure the 2D view and 3D view are properly synchronized.

The commit for disabling the roll and free look which should be reverted later: klokantech@f2b68b0
available also here: https://gist.github.com/klokan/99a3be6a193a71ac4157

The raster synchronizer tries to synchronize non-raster layers leading to an error:
TypeError: csLayer is null core.js:117

The type of layer may be checked in rastersynchronizer.js
this.olLayers_.forEach(function(el, i, arr) {
synchronizeLayer(el);
});

Idea: Bring vector data the user interacts with in 2d into 3d, without having to load the data twice. Allow same styling, labels and tooltip information.

Cesium supported formats:

• GeoJSON, OK!
• KML is an ongoing work: https://github.com/AnalyticalGraphicsInc/cesium/tree/kml & CesiumGS/cesium#873
  Cesium examples:
• Styling
  • Points/Billboards: http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=Billboards.html&label=Showcases
  • Polylines: http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=Polylines.html&label=Showcases
  • Polygons: http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=Polygons.html&label=Showcases
  • Geometries: http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=Geometry%20and%20Appearances.html&label=Showcases
• Labels: http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=Labels.html&label=Showcases
  *Tooltips?

Notes

• Cesium places the 2D GeoJSON on the terrain according following rules:
  • Vertexes are precisely placed on the terrain
  • Segments go straight (in 3D) between the 2 Vertexes

If the view is tiled substantially, then the center point of screen is not anymore an ideal center of synced 2D view.

This means we may see a completely different things in 2D then we see in 3D. A general perfect solution is not known (to me), but this ticket may try to find one good enough for now.

Related: because the resolution for 2d view is calculated from the center point of screen where interaction happens as well, there may be an (expected) issue with synchronization of the view and resolution calculation without moving the center. The worst case scenario is visible here:

Cesium does not support concept of layer groups.

Basic raster synchronization as described in #10 iterates on in the list of OL3 layers - unsupported layers are ignored (LayerGroup is now one of them).

If LayerGroup should be supported we must include listeners on the childern of each LayerGroup in hierarchy for opacity, change of saturation, etc. and calculate the final opacity value of whole hierarchy of LayerGroups in the OLCesium wrapper.

With openlayers/openlayers#2615 now closed we should be able to use checkTypes. But we get compile errors when setting that option to "on":

[wrk12 ol3-cesium (compile *)]$ make dist
mkdir -p dist/
node build/build.js build/ol3cesium.json dist/ol3cesium.js
info ol3-cesium Parsing dependencies
info ol3-cesium Compiling 40 sources
ERR! compile /home/elemoine/src/ol3-cesium/src/camera.js:165: WARNING - inconsistent return type
ERR! compile found   : (Array.<number>|null|undefined)
ERR! compile required: Array.<number>
ERR! compile   return this.view_.getCenter();
ERR! compile          ^
ERR! compile
ERR! compile /home/elemoine/src/ol3-cesium/src/core.js:23: WARNING - assignment
ERR! compile found   : Cesium.Cartesian3
ERR! compile required: Cesium.Cartographic
ERR! compile   target = ellipsoid.cartographicToCartesian(target);
ERR! compile   ^
ERR! compile
ERR! compile /home/elemoine/src/ol3-cesium/src/core/olimageryprovider.js:44: WARNING - actual parameter 1 of goog.events.listen does not match formal parameter
ERR! compile found   : ol.source.TileImage
ERR! compile required: (EventTarget|goog.events.Listenable|null)
ERR! compile   goog.events.listen(this.source_, goog.events.EventType.CHANGE, function(e) {
ERR! compile                      ^
ERR! compile
ERR! compile /home/elemoine/src/ol3-cesium/src/core/olimageryprovider.js:146: WARNING - actual parameter 1 of olcs.core.OLImageryProvider.createCreditForSource does not match formal parameter
ERR! compile found   : ol.source.TileImage
ERR! compile required: ol.source.Source
ERR! compile         olcs.core.OLImageryProvider.createCreditForSource(this.source_);
ERR! compile                                                           ^
ERR! compile
ERR! compile /home/elemoine/src/ol3-cesium/src/ol3cesium.js:98: WARNING - actual parameter 2 of olcs.Camera does not match formal parameter
ERR! compile found   : (null|ol.View|undefined)
ERR! compile required: ol.View
ERR! compile   this.camera_ = new olcs.Camera(this.scene_, this.map_.getView());
ERR! compile                                               ^
ERR! compile
ERR! compile /home/elemoine/src/ol3-cesium/src/ol3cesium.js:116: WARNING - actual parameter 1 of olcs.RasterSynchronizer does not match formal parameter
ERR! compile found   : (null|ol.View|undefined)
ERR! compile required: ol.View
ERR! compile       new olcs.RasterSynchronizer(this.map_.getView(), olLayers,
ERR! compile                                   ^
ERR! compile
ERR! compile /home/elemoine/src/ol3-cesium/src/rastersynchronizer.js:78: WARNING - actual parameter 2 of olcs.core.updateCesiumLayerProperties does not match formal parameter
ERR! compile found   : (Cesium.ImageryLayer|null)
ERR! compile required: Cesium.ImageryLayer
ERR! compile       olcs.core.updateCesiumLayerProperties(olLayer, cesiumLayer);
ERR! compile                                                      ^
ERR! compile
ERR! compile /home/elemoine/src/ol3-cesium/src/rastersynchronizer.js:84: WARNING - actual parameter 2 of olcs.core.updateCesiumLayerProperties does not match formal parameter
ERR! compile found   : (Cesium.ImageryLayer|null)
ERR! compile required: Cesium.ImageryLayer
ERR! compile               olcs.core.updateCesiumLayerProperties(olLayer, cesiumLayer);
ERR! compile                                                              ^
ERR! compile
ERR! compile
ERR! compile ol3/build/ol-externs.js:2815: WARNING - mismatch of the getSource property type and the type of the property it overrides from superclass ol.layer.Layer
ERR! compile original: function (this:ol.layer.Layer): (null|ol.source.Source)
ERR! compile override: function (this:ol.layer.Image): (null|ol.source.Image)
ERR! compile ol.layer.Image.prototype.getSource = function() {};
ERR! compile ^
ERR! compile
ERR! compile
ERR! compile ol3/build/ol-externs.js:2983: WARNING - mismatch of the getSource property type and the type of the property it overrides from superclass ol.layer.Layer
ERR! compile original: function (this:ol.layer.Layer): (null|ol.source.Source)
ERR! compile override: function (this:ol.layer.Tile): (null|ol.source.Tile)
ERR! compile ol.layer.Tile.prototype.getSource = function() {};
ERR! compile ^
ERR! compile
ERR! compile ol3/build/ol-externs.js:3015: WARNING - mismatch of the getSource property type and the type of the property it overrides from superclass ol.layer.Layer
ERR! compile original: function (this:ol.layer.Layer): (null|ol.source.Source)
ERR! compile override: function (this:ol.layer.Vector): (null|ol.source.Vector)
ERR! compile ol.layer.Vector.prototype.getSource = function() {};
ERR! compile ^
ERR! compile
ERR! compile /home/elemoine/src/ol3-cesium/src/camera.js:381: ERROR - Property fovy never defined on Cesium.PerspectiveFrustrum
ERR! compile   var fovy = this.cam_.frustum.fovy; // vertical field of view
ERR! compile              ^
ERR! compile
ERR! compile /home/elemoine/src/ol3-cesium/src/camera.js:421: ERROR - Property fovy never defined on Cesium.PerspectiveFrustrum
ERR! compile   var fovy = this.cam_.frustum.fovy;
ERR! compile              ^
ERR! compile
ERR! compile /home/elemoine/src/ol3-cesium/src/rastersynchronizer.js:116: ERROR - Property destroy never defined on Cesium.ImageryLayer
ERR! compile           layer.destroy();
ERR! compile           ^
ERR! compile
ERR! compile
ERR! compile 3 error(s), 11 warning(s), 96.6% typed
ERR! compile
ERR! Process exited with non-zero status, see log for more detail: 3
make: *** [dist/ol3cesium.js] Error 1

@klokan or @petrsloup will you be able to look at that?

Linter should check all our code. This includes:

• our sources (done);
• our examples (with --disable 0220, no doc for member);
• our Cesium.externs (maybe with --disable 0110, line to long).

Ol3 ol-externs generation should also be fixed or at least greatly improved.

We are using both Array.forEach and goog.array.forEarch functions.
For consistency we should choose one way and stick with it.

The standard is Array.forEach and is present in IE11, the first supported by Cesium.
Do you agree to choose Array.forEach?

As reported here by @tschaub we should not throw strings. Instead we should throw Error instances, or use goog assertions. The advantages of goog assertions is that they do not pollute the build with strings and debug code (if goog.DEBUG is false obviously).

As discussed during today's hangout we want to set goog.DEBUG to false in ol3cesium.json (the build configuration file for ol3cesium.js).

ol3cesium.js is indeed to meant to be used during development. During development we should run the examples in full debug mode (scripts loaded one by one).

We can also create an ol3cesium-debug.js build in the future. That build will include non-compiled code, and will have goog.DEBUG set true.

The "switching between 2D and 3D" use-case is the following: an application with a 2D/3D switch button that changes the view from 2D to 3D and vice-versa (toggle).

The olcs.OLCesium synchronizer proposed in #16 covers that use-case. But the problem is that the ol map is constantly re-rendered when in 3D and when the user interacts with the Cesium globe.

Really, for that use-case we do not need a synchronizer object. What we need is functions helping the application developer to convert ol view states to/from Cesium camera states. These functions will be called when the 2D/3D toggle button is pressed.

Also, we want to show a smooth transition when switching from 2D to/from 3D. And for this smooth transition what we want is to change both the position and the tilt of the camera. This is as described in https://gist.github.com/tonio/750dbc843ef95601c4be (which is referenced in #2).

We'd like that the library provide functions that allow implementing that use-case without having to use lots of math in the application code.

We plan to work on an example implementing that use-case, and, along the way, implement useful functions in the library to support that use-case.

Click events in 3D are passed to ol3 together with information about clicked geo coordinates and modifier keys to handle feature selection.

Details about how the event should be passed to ol3 to be specified.

The core.js file should be split into multiple files. Likewise, the olcs.core namespace should be split into multiple sub-namespaces.

From our client:

I started setting a Z component on geometries that had it available, and setting the geometry type to ol.GeometryType.XYZ but I found some issues with the geometry translation in core.js. The translation functions for both Point and Circle use the center point to create the Cesium position, which dumps any elevation component. For example...

https://github.com/boundlessgeo/ol3-cesium/blob/master/src/core.js#L519

  var center = ol.extent.getCenter(geometry.getExtent());
  var position = olcs.core.ol4326CoordinateToCesiumCartesian(center);

Wouldn't it make more sense to use geometry.getFlatCoordinates() and convert that instead of the center? Getting the coordinates by computing the center of the extent of a point seems like a circuitous route that also has the side effect of losing the Z component.

All geometries should support XYZ coordinates and convert appropriately to the globe.

When the size of the div is not fixed, resizing it flattens the Cesium globe to a rugby ball.

The behaviour is different from the Cesium demo http://cesiumjs.org/Cesium/Build/Apps/CesiumViewer/index.html . In the demo the ratio is automatically re-ajusted.

Cesium has limited support for 3D geometries.

• they can not be draped on the terrain;
• most are always drawn on the ellipsoid, not in 3D.

Related issues are: #4, #11, #12.

Contrary to what was stated in #12, 3D primitive support in Cesium is limited.
From my tests, only the polyline geometry works as expected: given an array
of 3D positions, only the polyline geometries are displayed in 3D by Cesium.
The other geometries (circle, polygon) are displayed on the ellipsoid even
when the positions have an elevation.

A workaround for the case where all the elevations of a geometry are the same,
may be to use a primitive model with a translation value set to the geometry
common elevation. This would however not work with MultiPoint, MultiPolygon
and the GeometryCollection, unless they all share the same common elevation.

• core.js: Missing requires for ol.layer.Tile, ol.source.WMTS, and ol.source.TileImage.
• rastersynchronizer.js: Missing a require for ol.layer.Group.
• core/olimageryprovider.js: Missing a require for ol.tilegrid.XYZ.

The ol3-cesium code includes things like this:

if (geom.getType() == 'Point') {
  // …
}

The compiler doesn't choke on this because in the ol externs file ol.geom.Geometry#getType's return type is ol.geom.GeometryType and ol.geom.GeometryType is @typedef {string}.

But, if we compile the application, ol3 and ol3-cesium together (which we said we want to support) then the compiler will return an error, because ol.geom.GeometryType is not an @enum and not a @typedef {string} in the ol3 source code.

This inconsistency between the ol3 source code and the ol-externs.js file is a problem.

This is another aspect of the vector synchronization requirement from our client: They need to be able to draw features just for a single rendering/animation frame. Something like the renderFeature method in the immediate api / vector context that is available in the postcompose hook.

The resolution now jumps in side-by-side if view is tilted and center points to valley and then suddenly a mountain.

See an example:

This has been described in the original view sync ticket #9 as a known issue - which we don't think is critical.

We want to pass the in memory ol3 existing feature collections to cesium - it means all ol3 supported formats should be possible to display in 3D.

Styling of the features should be read from ol3 structures and set via Cesium API: (http://cesiumjs.org/Cesium/Build/Documentation/Material.html) - PolylineOutline, etc.

Only styling already available in Cesium API is to be implemented:

• colors for borders + polygons
• feature stroke (outline / border) in pixels
• labels with custom fonts
• icon markers (ol.style.Icon) as billboards?

There is no:

• label rotation
• line cap, line dash, line join, miter limit

This tickets implements features displayed without terrain!
Implementation on top of terrain is tracked under #12

From our client:

The layers now update when params change, but we're not confident re-adding every layer on the map when one layer fires a change event is a good solution. If a layer fires a change event, only that layer should be synchronized again. Further, the associated Cesium layer should be updated instead of removing and recreating the layers.

For example, if a parameter changes in a WMS tile layer, the layer should refresh all tiles with the new params. Currently the layer is removed, and a new layer added to the globe.

In this moment ol.View and Cesium camera are constantly synchronized (as if both are visible) and both libraries render the map with all layers, features, etc. This happens also in the moment where one of 2D or 3D is not visible on screen or when in a "stacked mode" (3D overlaying 2D in the same DOM container element).

Performance may be improved if we disable rendering or stop synchronization of the carmera/view between the two projects whenever possible. But this may bring some implications on how the wrapper may or may not be used by programmers.

A simple solution not breaking anything may be just stop unwanted rendering, but keep view+camera constantly synchronized.

It means:

• do not call this.scene_.render(); if Cesium is not enabled
• stop rendering on ol3 side (how? via setting a copy of existing ol.view and keeping synchronized the original ol.view object which may be set back to ol3 when sync should be restored?)

An advanced implementation could be even more clever. We could detect stacked mode and delay or completly stop synchronization on view, and enforce it only if required from the wrapper code via a helper function updateView(): definitelly when switching back to 2D, but possibly also before feature picking or elsewhere in the wrapper code, if required.

This may bring possible issues for implementation of interaction with ol3 sources, layers, feature picking, etc.

To be discussed here in comments - and on the Monday meeting.

Correct implementation of synchronization of ol.View and Cesium.Camera:

• map center is the target of view
• resolution is calculated from the distance between the target and camera (resolution of the tile displayed in the center of screen)

Problems:

• camera has to be always directed towards the planet - what center should be set if this does not happen?
• Warning: on all the interactions once the terrain is turned on we depend on implementation and merge of this pull request: CesiumGS/cesium#1817
  It is expected that camera never flies under the terrain.

Performance issues:
It is expensive to calculate the target and resolution too often (picking). We may need throttling and additional optimisations.

Note: When camera is tilted and resolution is calculated on target, the resolution can “jump” in ol.View - looking at a mountain, shift aside, looking far in a valley.

Note: With terrain turned on, the “resolution” of the view may differ substantially from altitude (different tiles with zoom level 16 on Everest and in Sahara at the same altitude).

When working on #2 (animated switch between 2D and 3D) the elevation value may be required to the fly from/to a perpendicular view on the target (original map center).

Warning: If somebody changes center in ol.View we will set perpendicular (reset) view at that position in Cesium in this first implementation. To preserve tilt, roll, etc. the ol3cesium method .setTarget() should be used instead.

Only sources with existing implementations on both ol3 and cesium: Bing, OSM, XYZ, WMS with geodetic+mercator TMS profile to be implemented.

Other raster layers or non-suported projections/grids may be ignored for now.

In first implementation the existing cesium tile queue separate from ol3 is going to be used.

For the compilation of the ol3-cesium in advanced mode independetly of ol3 we must have externs.

It seems there is no way how to generate externs for ol3 API right now. (It is not to be mixed with exports).

Closure compiler wrapped in node.js does not support it - it is not parameter of the compiler on the command line either).
Plovr can do that, but it seems jsdoc types are not passed trough.

Ideal way how to generate Closure exports for public OL3 API would be probably via a custom JSDOC template.

Required is:

• new jsdoc template to automatically generate ol3 api externs for everything with @api
• modification of the npm/node powered compilation system to support "generate-externs" task producing the externs

Because we don't have externs for OL3 API we compile now in WHITESPACE :-(.

Alternative would be to compile ol3-cesium together with ol3 itself - to get a single ADVANCED minimised js, which we plan to support anyway, but it does not follow the preffered external ol3 approach we specified before.

The distance to target is computed based on the camera fov and the canvas width in
Camera.calcDistanceForResolution.

We are expecting to use the horizontal fov but Cesium documentation states that:
The angle of the field of view (FOV), in radians. This angle will be used as the horizontal FOV if the width is greater than the height, otherwise it will be the vertical FOV.

We also use latitude to correct the metersPerUnit factor but what happens when the view is twisted? In this case the horizontal segment containing the target point may actually be spanning over several latitudes.

The visible meters are computed on the sphere, but the Cesium view is rendered on a terrain / ellipsoid. May it introduce a gap?

I think we should fix the first issue.
For the last two issues, if approximation is acceptable, we should put a comment.

When moving near the poles in Cesium view, the ol3 map becomes really small and the application is no more responsive. The browser then propose to kill the script.

Wrapper around Cesium which takes care of the following synchronizations:

From ol3 to cesium (one way) will be synchronized:

• all features and their styles (details in #4)
• supported raster layers (details in #3)

Additionally, the cesium interactions (modifying camera position and properties) will also automatically modify the ol.View properties (center, resolution, rotation) -- details in #9.

The constructed object (returned by the ol3cesium factory) will provide additional methods specific for the 3D environment:
.set/getRoll() - in radians as in ol3 - or possibly in degrees?
.set/getTilt() - in radians?
.set/getHeading() - in radians?, this is in fact shortcut for rotation on ol.View
.set/getDistance() - meters - from target of view
.set/getAltitude() - absolute height of camera above ellipsoid in meters

.set/getCenter() - this is in fact shortcut for center on ol.View (but without change of angles) (Update: originally named set/getTarget).
.set/getPosition() - position of camera
.lookAt() - camera stays on same position and is rotated to point at the specified target
all accepting/returning ol.Coordinate

Access to the underlying Cesium.Scene instance for native calls via Cesium API: .getCesiumScene()
Calls on Cesium API are possible but can desynchronize state of ol3 and cesium.

Synchronization from Cesium view set otherwise back to OL3 is implemented only for Camera->View - and is done automatically or by calling .updateView() in #9 (update: originally syncView)

No major modifications of the ol3 are required.
ol3cesium is compiled with Closure Advanced.
Cesium API is called via externs.
In the initial implementation we try to use only exported functions of ol3 api (via externs for complete separation).

User should be by loading 3 js files: ol3, cesium, ol3cesium.

The advanced compilation of ol3 together with the ol3cesium wrapper may be used, if unexterned ol3 methods must be called.
Theoretically an application can be build together with ol3+ol3cesium in advanced mode to produce a single minimized .js file.

Update: the ilustration of Camera interaction:

SVG for printed documentation or presentations:
https://gist.github.com/klokan/d703a2cd40ec65a9a3e7
https://rawgit.com/klokan/d703a2cd40ec65a9a3e7/raw/9f2326d1677931b2b4bafa1aa8bfb47aa7222cb8/ol3cesium_camera.svg

Idea: A la google map, share the bottom line and tilt. Forward and Backward.

Some thoughts about the camera movement: https://gist.github.com/tonio/750dbc843ef95601c4be (might be outdated with the experience of the following POCs)

Ongoing work:

• 1. POC: http://bl.ocks.org/tonio/raw/9759909/
• To be developed further: http://bl.ocks.org/gberaudo/raw/51f050326d91d4e9c09a/1b55ad64a1f3de2dcba5673ecb52f976104a4592/#

Remarks:

• all directions must be handled (not just NS and EW);
• all tilted situations must be handled (starting from an arbitrary tilted angle);
• always keep center of bottom line fixed in general, whole line for NS and EW.

Idea: use cesium picking information to get the coordinates in 3D, make them available to OpenLayers and send them back to the traditionnal transactional webservice http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=Picking.html&label=Showcases.

Question: Make coordinates available to vector feature geometries or editing interactions in ol3? One requirement is to also be able to drive the dragbox interaction from Cesium.

When constructing the raster synchronizer, we directly pass the view and the layerGroup.
It is not correct because these objects may be replaced by others later, breaking the synchronization mechanism. The vector synchronizer suffers the same underlying issue.

A nice solution would be to have the view and the layer group references fixed in the ol.Map constructor.
That way, subsequent calls like map.getView() will be guaranteed to return the same reference.
Please see openlayers/openlayers#2649.

Other solutions may exist.

@petrsloup , @klokanp , we must commit a fix for this issue.

Cesium is not yet ready for features clamped on top of terrain out of the box.

“Clamp to ground” is not yet implemented - see: CesiumGS/cesium#526
and point “Render polygons / polylines” on terrain.

Features in 3D can be rendered on absolute altitude available as part of the individual feature nodes only (provided from server).

Polygons on terrain are impossible right now.

This work with polygons on terrain is to be postponed until Cesium supports clamped to terrain functionality.

When I remove a vector layer, I get a 'typeError: layer is null' from line 116 of rastersynchronizer.js.
Reproduce opening vectors.html example.

Following diff fixes the error:

diff --git a/src/rastersynchronizer.js b/src/rastersynchronizer.js
index 2db06bc..8877245 100644
--- a/src/rastersynchronizer.js
+++ b/src/rastersynchronizer.js
@@ -67,6 +67,8 @@ olcs.RasterSynchronizer.prototype.synchronize = function() {
         });
       }
       return;
+    } else if (!(olLayer instanceof ol.layer.Tile)) {
+      return;
     }

     var olLayerId = goog.getUid(olLayer);

Following assert is failing with z smaller than minZoom.

ol.tilegrid.TileGrid.prototype.getResolution = function(z) {
  goog.asserts.assert(this.minZoom <= z && z <= this.maxZoom);
  return this.resolutions_[z];
};

Adjusting of the build process to support all three build approaches:

1. ol3cesium.js independent of ol3 (WE HAVE IT NOW)
2. ol3cesium.js compiled together with ol3
3. ol3cesium.js compiled together with ol3 and the application

From our client:

If I have a polygon on the 2D map with a stroke but no fill, the corresponding polygon on the Cesium globe has an opaque black fill. It should instead also have no fill (or a transparent fill so the end result is the same).

Colors are also not being translated appropriately. I have a box drawn on my 2D map with a style defined as such:

  style = new ol.style.Style({ 
    stroke: new ol.style.Stroke({ 
      color: [0xff, 0xff, 0, 1.0], 
      width: 2 
    }) 
  });

Even if I add transparent fill to solve the previous issue, my end result is a black outline instead of a yellow one. Point geometries are being colored appropriately however.

Currently we synchronize the whole layer change event.

It should be possible to implement a more complex mechanism in order to synchronize at the feature level. See #69.

Idea: same keyboard and pointer interactions in both ol3 and Cesium.

E.g. shortcut to rotate a map in ol3 as to rotate the globe in cesium. For now, we have:

• rotation:
  • ol3js: shift - drag
  • cesiumjs: control - drag

Idea: A vector on the 2D map displays the view point and the view direction:

• When moving the 3D view, it adjusts the 2D vector.
• When moving the 2D vector, the 3D view is adjusted.

See example with OpenLayers 2 and Google Earth plugin: http://plan.epfl.ch/?lang=en, click in the right menu on 3d. 2D and 3D are snychronized.

Question: How to get the same control feeling when manipulating the Ol3 view / the Cesium view? Uses cases are: stacked views or separated views like for EPFL.

Cesium supports several raster formats, notably:

• WMTS;
• WMS.

In ol3cesium, we are currently restricted to a custom ol3 tile image provider.
This imagery provider gets the tiles from an ol.source.TileImage in either 4326 or
3857 projection.

Other or different projections in ol3 and Cesium are not possible.
WMS or WMTS are not handled.

#42 introduced lint errors. They should be fixed. And a check target should be added to the Makefile.

Today the distributed examples are hardcoded to use ol-debug and minified cesium.

By adding two menus in all examples we would be able to switch from ol-debug to ol and from Cesium to CesiumUnminified. Many issues are only triggered or debuggable in only one mode, so it is very important to have this feature.

It is the same mechanism used by ol3: http://openlayers.org/en/v3.0.0/examples/animation.html