Architecture about ol-cesium HOT 6 OPEN

Based on experiences from http://www.webglearth.com/ available at https://github.com/webglearth/webglearth2 and based on what has been done before at https://github.com/openlayers/ol3/tree/cesium we are reviewing the possibilities for ideal integration of Cesium with OL3. @petrsloup will comment soon.

from ol-cesium.

In order to keep the integration easy to maintain, it is indeed a good idea to keep the integration code separate from the ol3 itself.

Although it makes sense to consider cesium to be just another renderer, it would require a lot of new code inside ol3 itself (namely ol.View3D), plus the ol3 is not ready to change renderer on-the-fly.

I think the best approach is to create "ol3 cesium plugin" and (if possible) completely avoid any ol3 or cesium modifications:

• All the operations would be performed on the standard ol3 objects using standard ol3 methods.
• If cesium 3D globe is needed, it can be "enabled" via the additional "plugin" interface.
  • This takes care of properly setting up the cesium
  • and also registers various event listeners (layer collections, controls, view properties, ...) to keep it synchronized (both ways).
• In 3D mode, the cesium interactions would be used (with settings as similar as possible -- hotkeys, sensitivity, ...).
• Both single-canvas (2D/3D switching) and double-canvas (side-by-side) scenarios can be supported.

This way, any 2D ol3 application could be switched to 3D by creating the additional 3D interface object:

  var map = new ol.Map(..);
  // setup...

  var ol3d = new ol.CesiumIntegration({map: map, ...});
  ol3d.setEnable(true);

But there are still some new methods needed to be able to utilize the 3D features (setting tilt, roll, altitude in meters, animations, ...) -- these could all be part of the integration object (.setAltitude(..), .setTilt(..), ...).

I think, however, some minor changes might be required to the ol3 itself in order to ensure optimal integration without any "hacks" -- particular requirements will become more clear after initial implementation.

from ol-cesium.

Thanks @petrsloup!

+1 on implementing this as a plugin. This is also in line with my initial thinking and with what we had discussed in past ol3 dev meetings.

I think, however, that we should avoid using the ol namespace for the plugin. What namespace to use is a matter of taste. Personally, I would like something like this (i.e. factory instead of constructor):

  var map = new ol.Map(..);
  // setup...

  var ol3d = ol3cesium({map: map, ...});
  ol3d.setEnabled(true);

Minimal changes to ol3 are fine - also something we have a general agreement on.

from ol-cesium.

I agree this direction sounds good. My only suggestion is in line with @ahocevar's I think.

In my opinion, nobody should ever use the ol namespace unless they are working on code in the ol3 repository. I know jQuery has made hugely popular the idea of "plugging" everything into the same namespace (and Leaflet "plugins" do the same). But there is no benefit in using the same namespace and good reasons not to (the ol3 repo reserves the right to add new names to the ol namespace in the future, "plugins" of this nature don't lend themselves to naturally to module loaders, it only makes it harder for people to determine code origin when reading application code, etc.).

So +1 on an adapter.

from ol-cesium.

Hello,

I will not comment on the renderer vs plugin design choice, but I'd like to stress that we would probably be interested in the future to have a ol3js / Three.js integration too.

Keeping this in mind would be great, just in order not to make technical decisions hindering that.

from ol-cesium.

Suggested ol3cesium factory design is at: #8

from ol-cesium.