cesium package development

[tim-salabim]

At OpenGeoHub summer school 2019 there was a brainstorming session on how to go forward with the newly RConsortium funded global project/package. global is an effort to make it easier and more convenient to deal with unprojected (geographic) global longitude/latitude data by providing standard spatial functionality that does not assume 2d cartesian coordinate reference systems but does calculations on the sphere. This saves users the pain of having to find suitable projections for the analysed data, among other common problems (e.g. data crossing the antimeridian). It will mainly rely on the google S2 library.

To be able to visualise geographic data accordingly, we have made a POC package wrapping cesium. The package can be found at https://github.com/r-spatial/cesium and is currently very limited in functionality. We can for example do:

library(sf)
library(mapview)
library(cesium)
library(geojsonsf)

fran = geojsonsf::sf_geojson(mapview::franconia)
cesium(data = fran)

to get a geojson polygons object plotted on a globe (points and lines also supported).

Cesium is a very powerful, but complex JS library that has a lot of functionality. See the demos and the sandcastle to get an idea of the possibilities. For standard geo-spatial work only a few basic features are needed though. Cesium uses webgl so should be suited for rather large data sets and has native support for space-time data. I envision support for rendering

• points, lines, polygons (& markers)
• bitmap images (raster data)
• space-time data

so that we have a base cesium package that provides access to the complete Cesiumjs library but only provides a minimal set of functionality necessary for most common spatial tasks (e.g. layermanager, legends etc - in addition to the above mentioned support for feature layers). Everything else could then be added by other users who have a need for certain functionality.

This feels like a natural companion for global as it allows to work directly on longlat data wothout the need to re-project to e.g. web-mercator for the rendering (as leaflet and mapdeckdo for example).

There are a couple of packages already available to render data on a globe:

• @r-barnes has webglobe
• @JohnCoene has globe4r

I am not sure how feature complete and extendible these packages are, but maybe their authors can share some of this information here.

My hope is that we can develop a fully functional package along the lines of RStudio's leaflet package.

My question here is whether there is interest in this effort? And if so, how can we realise this project? (my personal JS skills basically end with the above POC package)

Pinging
@edzer (global dev)
@jcheng5 (leaflet et al.)
@alandipert (leaflet et al.)
@timelyportfolio (mapedit etc.)
@mdsumner (webgl fame)
@SymbolixAU (mapdeck et al.)
...
Please add relevant people to this discussion!!

One possible pathway for this is a RConsortium grant - deadline for current call is 14 October 2019

Thanks for any feedback on this!
Tim

[dcooley]

My question here is whether there is interest in this effort?

definitely interested, and more than happy to contribute.
( also as @SymbolixAU )

[am2222]

Hi, this a great idea also there is ol3-cesium package which enables the cesium and openlayer integration but it is in early stages of the works. I wish scesium would add vector tiles support to make it a perfect rendering engine. I'd also be happy to contribute.

[dcooley]

Do you have thoughts on how you would like the library built up? I'm not familiar with the cesium library so can't help on that front at the moment. But I can get the R / Rcpp code working if you want to go down that route?

[tim-salabim]

@dcooley it'll be a similar effort to leaflet & mapdeck, so lots of JS bindings needed (but you know better than me what that actually means).

[JohnCoene]

Hi There @tim-salabim,

First, well done on the work so far with the cesium integration. Despite the fact that I have built numerous htmlwidgets I am no expert in JavaScript but would be happy to help working on cesium's integration. I did create globe4r but it is not a fair comparison to cesium, the latter allows much more detailed visualisations than globe4r ever will: after all globe4r is just a globe with an image layered on top (things like zooming in on a location don't really "work").

Note, for you r-spatial experts, there is also harp.gl out there. I'm not sure which is best or most suited to R developers.

Personally, I think there is room for such a project, particularly one that integrates well with other r-spatial packages.

[tim-salabim]

There's also https://worldwind.arc.nasa.gov/web/ ehich seems to have built in support for e.g. reading geotiffs...

[am2222]

both worldwind and cesium support wms, wmts, but worldwind does not support gltf objects which ceisum supports

[tim-salabim]

@am2222 you seem to know a bit about these different rendering platforms, any favourite?

[am2222]

@tim-salabim yeah I have worked with some of them already. I think based on the current state of each of them the best option is cesium, however it lacks on vector tile rendering but it supports wms, wfs and most of the web standards. It also has a good performance when it comes to rendering webgl objects. For the 3d elevation mapping it is also related to the it's owners company products. but there are some open source extensions for it to use geoserver as a backend for the 3d elevation map. for vector rendering it can render vectors from different sources but if you want to feed it from web services (like vector tiles) it lacks.

there is an integration between cesium and openlayers here https://openlayers.org/ol-cesium/ but it has some limitations, but as it is aimed to render the ol maps on cesium

world wind also has good features but again it lacks on vector tiles, it supports wms /wmts and also wkt, but I did not check its performance over large amount of data.

tangram library also supports 3d but does not support globe (https://github.com/tangrams/tangram)

webgl-earth is another library which I have seen around https://github.com/webglearth/webglearth2 and they use cesium as backend.

[tim-salabim]

@am2222 thanks for the input! I had looked at webgl-earth in the past, but forgot about it. Thanks for reminding me! This may well prove the easiest to implement if their claim about the leaflet compatible API is true...

@jcheng5 @alandipert would you mind having a look at webgl-earth and assess whether the current leaflet infrastructure could be ported with manageable effort? If their claim is correct, a simple find (L.) & replace (WE.) should be all it takes... I doubt it will, but it might be a rather low hanging fruit...

[tim-salabim]

@am2222 I have just realised that webgl-earth doen't seem under active development anymore...

[r-barnes]

I built webglobe to emulate some of the functionality of ggplot.

For instance, the following draws the United States in blue polygons with random heights.

library(webglobe)                 #Load the library
m  <- ggplot2::map_data("state")  #Get data
m$extrude_height <- 1000000*runif(nrow(m),min=0,max=1)
wg <- webglobe(immediate=FALSE)    #Make a webglobe (should open a net browser)
wg <- wg + wgpolygondf(m,fill="blue",alpha=1,stroke=NA)
wg

There's a lot to be improved on here. Maybe actually binding to ggplot. Maybe incorporating a time dimension, as Cesium supports this. I primarily built the package to support my work with discrete global grids (hexagonal binning of the Earth's surface).

[SymbolixAU]

From the upcoming 7.3 deck.gl release notes

deck.gl has partnered with Cesium to implement support for the OGC 3D Tiles specification. This makes it possible to to render city-scale (billions of points/features) and country-scale (trillions of features) datasets in the browser.

In this initial release, the layer has full support for point clouds and experimental support for glTF tiles

So we might start seeing more overlaps with deck.gl and cesium.

[mdsumner]

gITF sounds promising

[tim-salabim]

@SymbolixAU this is great news and I hoped that this would be the case at some stage.
I still think that having a bare- bones cesium wrapper package is worth pursuing.

But I really want to emphasise that this would need to be a joint effort as my time is too limited to implement this on my own.

[mdsumner]

I'm definitely keen, and I look in detail - it's just still outside my abilities. These meshy WebGL sides are the parts I can probably get into. Really appreciate your efforts here!

This in particular looks like something I can hook CesiumGS/cesium#5995

[tim-salabim]

I think the most important thing is to have functioning API to generate a base globe and then put layers on it via add* calls, similar to leaflet/mapdeck. Then a Layermanager to flick between those.

[goergen95]

Hi everyone,

I implemented a first draft of an R cesium package
that I wanted to bring to your attention.
All kinds of contributions are welcome, but most
urgently from my view is setting up a proper JavaScript
binding that enables layer management and the addition of
color legends. Unfortunately, that is above my abilities
on the JavaScript side.

This initial design of the R package is essentially an
sf-to-CZML converter for small to medium sized data sets.
Using CZML has
the benefit of being able to render different
type of geometries quiet easily on a 3D-interactive globe
simply by calling the respective CesiumJS method.

Currently, with this approach we can:

• add points,
• add markers,
• add labels,
• add lines,
• add polygons,
• add rasters

using sf and stars, all with a potential temporal dimension.

I set up some usecases
that show what currently is possible. Sorry that I could not include the data, so
you'll have to install some packages and download the data if you want to
run the code (but I set up renv so hopefully this runs seamless).

Please consider contributing in one way or another if you also
are excited about having a working R wrapper for CesiumJS! :)

[mdsumner]

nice! just off the cuff does everything have to go through conversion to longlat in R spatial formats for input to cesium or can we input geocentric xyz coordinates in raw or mesh form, which it presumably uses internally?

I'll explore, this is just my ever-present upfront question for this topic generally because often we can shortcut conversion to meshes 👌

[mdsumner]

this is awesome btw, having fun with it - will have some feedback ongoing - thanks!!! very nice touch with the texture for the sea ice extent haha

[goergen95]

Haha, I was hoping someone would appreciate the icy texture, glad you enjoy it!

I am also just beginning to learn CesiumJS internals, so take everything I say with caution.
When we talk about using CZML to add entities to the globe, I think there are 4 options to specify position:

• cartesian values in relation to the reference frame
• radians in relation to WGS84
• degrees in relation to WGS84
• cartesian velocity, so a cartesian value plus its derivative

Now, I am not sure what you are referring to by raw or mesh form, but I think to determine the anchor position (not anything about rendering here) of an entity, CesiumJS actually uses the cartesian3 value.

If we talk about rendering complex objects as meshes (are we?), there are two things that come to mind:

• The first is the model type entity supported in CZML, with which you can put glTF models on the globe. Related to that is also the 3D Tileset which is a tiled quadtree or octree that can contain many 3D models and point clouds. Here is the specification.

• The second would be quantized meshes that represent terrain which enables you to bring your own terrain data. There is OpenSource tooling to create such meshes.

For both of these items it does not make any sense to me to do anything serious through sf, except maybe for the first item where we still would need to define an anchor position and other arguments specifying how it is actually rendered. Note, none of these items is currently implemented in cesium but I hope we'll get there!

I hope this makes sense, and I am looking forward for your feedback once you were able to try out the package.

[mdsumner]

excellent answer I really appreciate it, I can definitely contribute at this level but the js itself was not in my grasp

fwiw I wrote a version of your seaice extent file getter that lets sf (or any gdal reader for that matter) read directly from the zip urls and do the transformation to longlat in gdal before tbe data hits R - it's very much a side topic but enjoyed the motivation to dive into the examples 👌 I got bogged down in wrapping it up but very keen to do that , it's related to a lot of other work we're doing