Cesium in 2013 - Content

CesiumJS
1

All,

Since we first presented Cesium (not counting the one slide it showed up in for a guest lecture a few months prior), we recognized that supporting standard formats is key to success. “Content is king” is the catchphrase. Cesium alone is cool, but if users can’t get their data into it, it’s useless to them.

We’ve done some nice work for content so far. In particular, Cesium supports six imagery providers. We continue to work on terrain. We started CZML, and for vector data, created converters for KML and Shapefiles (there’s also one for WebGL Globe JSON, but that was really just to get our feet wet).

We still have significant improvements to make:

  • 3D Models
  • We started discussing 3D models back in June. Since then, we prototyped enough that it was demoed at ITSEC with great success. We wanted to make more progress, but the Santa tracker took precedence. Good news - my plate is starting to clear, and other folks have expressed interest in helping with 3D models and related optimization pipelines and authoring tools. The roadmap page is almost up-to-date.
  • Longer-term, in addition to just drawing models, we plan to support the emerging Rest3D REST API for accessing models from the cloud. We hope to see several services support Rest3D, providing Cesium users with quite a selection of 3D model content.
  • CZML
  • We expect some big improvements to CZML and the DynamicScene in Cesium as we rework and finalize the spec.
  • I personally would like to see
  • A separate CZML mailing list for CZML spec discussion. This will help keep the community-based spirit and will create archives for how the spec was created, like the GeoJSON archives.
  • Tell the OGC what we’ve done so far, that we are starting the mailing list, and that we welcome early input since we ultimately intend to propose this as an OGC standard.
  • Determine if CZML fits the vector data needs for OpenLayers 3.
  • An adoption plan:
  • What key converters do we need an on-ramp to CZML? When do we write custom code for the Cesium client to handle formats that we can convert to CZML?
  • What is the future of the GeoServer CZML writer? When do we write a converter vs. rely on GeoServer?
  • What other key apps should support CZML? OpenLayers? Google Maps?
  • Vector Data
  • Formats
  • Improve the workflow for importing vector data. Conversion from KML will be seamless. Conversion from Shapefiles will not require the custom code it requires now.
  • Continue to add more complete support for KML (currently supported feature).
  • Add support for GeoJSON.
  • Rendering
  • Improve polyline styling with the material system.
  • Polygons, polylines, and billboards on terrain.
  • Widgets
  • A table-of-contents widget will enable end-users to access and manage content in Cesium Viewer and other Cesium apps.
  • Misc
  • (This is minor) - We need at least a temporary place, even on the website, to host assets like higher-resolution sky boxes for stars, etc.

Thoughts and other ideas?

Regards,

Patrick

2

Thanks

All,

Since we first presented Cesium (not counting the one slide it showed up in
for a guest lecture a few months prior), we recognized that supporting
standard formats is key to success. "Content is king" is the catchphrase.
Cesium alone is cool, but if users can't get their data into it, it's
useless to them.

+1 I strongly agree, the ImageryLayer(Collection) is a great starting point.

We've done some nice work for content so far. In particular, Cesium
supports six imagery providers. We continue to work on terrain. We started
CZML, and for vector data, created converters for KML and Shapefiles
(there's also one for WebGL Globe JSON, but that was really just to get our
feet wet).

Cesium needs a VectorLayer(Collection) that supports at least one common
and established standard.
Converters are nice but as long as cesium does not support one of the current
standards ootb the bar to get it running is set to high.

I advocate for GeoJson mainly because it has become the Lingua Franca
for a lot of web maps (leaflet, polymaps, Openlayers, ...). The downside
of Geojson is of course that it does not define a temporal component or
styling. As formats go I think it is the lowest hanging fruit.

KML is supported by openlayers, googlemaps and the google earth plugin
so my guess is that there will be some demand for this format. Styling
and to some extent temporal information are also present in this format

We still have significant improvements to make:

3D Models

We started discussing 3D models back in June. Since then, we prototyped
enough that it was demoed at ITSEC with great success. We wanted to make
more progress, but the Santa tracker took precedence. Good news - my plate
is starting to clear, and other folks have expressed interest in helping
with 3D models and related optimization pipelines and authoring tools. The
roadmap page is almost up-to-date.
Longer-term, in addition to just drawing models, we plan to support the
emerging Rest3D REST API for accessing models from the cloud. We hope to
see several services support Rest3D, providing Cesium users with quite a
selection of 3D model content.

CZML

We expect some big improvements to CZML and the DynamicScene in Cesium as we
rework and finalize the spec.
I personally would like to see

A separate CZML mailing list for CZML spec discussion. This will help keep
the community-based spirit and will create archives for how the spec was
created, like the GeoJSON archives.
Tell the OGC what we've done so far, that we are starting the mailing list,
and that we welcome early input since we ultimately intend to propose this
as an OGC standard.
Determine if CZML fits the vector data needs for OpenLayers 3.
An adoption plan:

What key converters do we need an on-ramp to CZML? When do we write custom
code for the Cesium client to handle formats that we can convert to CZML?
What is the future of the GeoServer CZML writer? When do we write a
converter vs. rely on GeoServer?
What other key apps should support CZML? OpenLayers? Google Maps?

Vector Data

Formats

Improve the workflow for importing vector data. Conversion from KML will be
seamless. Conversion from Shapefiles will not require the custom code it
requires now.
Continue to add more complete support for KML (currently supported feature).
Add support for GeoJSON.

just FYI: https://github.com/simplegeo/polymaps/tree/master/examples/kml

3

Christian,

Thanks for the input. Although I don’t think it came across well in my above email, we’re likely to add support for GeoJSON without CZML conversion.

We also want to improve the CZML conversion pipeline so it is not a barrier like it is now. With web services for conversion, it will be the same amount of client-side code to visualize a KML file via CZML conversion compared to if KML were supported directly on the client. One downside to web service converters is many of our users run on a closed network and/or aren’t allowed the send their data over the wire.

This all alludes to a question I proposed above:

When do we write custom code for the Cesium client to handle formats that we can convert to CZML?

I suspect the answer is when the format is easily handled in JavaScript, there is enough demand for it, and the benefits outweigh the cost of extra client-side code instead of just using our CZML renderer.

Regards,

Patrick

4

Christian,

Thanks for the input. Although I don't think it came across well in my
above email, we're likely to add support for GeoJSON without CZML
conversion.

great :slight_smile:

We also want to improve the CZML conversion pipeline so it is not a barrier
like it is now. With web services for conversion, it will be the same
amount of client-side code to visualize a KML file via CZML conversion
compared to if KML were supported directly on the client. One downside to
web service converters is many of our users run on a closed network and/or
aren't allowed the send their data over the wire.

They can run the conversion web services on their own network, can't they?
The downside I see here is that the conversion adds some latency.

This all alludes to a question I proposed above:

When do we write custom code for the Cesium client to handle formats that
we can convert to CZML?

I suspect the answer is when the format is easily handled in JavaScript,
there is enough demand for it, and the benefits outweigh the cost of extra
client-side code instead of just using our CZML renderer.

+1

5

Christian,

Right - latency can be a problem too, but it depends. If the file is hosted on the server, it can be faster to convert it server-side if it reduces the amount of data sent over the wire, and there are opportunities to cache the conversion for multiple clients. For some users, this may be the case, but for lots of other users their data will be hosted elsewhere.

Regards,

Patrick