New Cesium KML-CZML Editor Features: Custom Data & Styling, Google 3D Tiles, and More

2025-06-13T00:00:00+00:00

I have made some updates to the Cesium KML-CZML editor I created and maintain.

The most important additions and changes are:

Support for Google 3D tiles
Support for writing many more features, including interpolation and time series data for some properties. There are still no editing capabilities for these properties, but while previously the editor would strip these values from the data, it will now copy them into the output file.
Export to KML and KMZ
Support for custom data and styling using that custom data
Switched frontend framework from Vue to React

Adding support for Google 3D tiles is what caused me to create this major version update. In a nutshell, Cesium has its own way of adding reactivity to Entities and Vue doesn’t always play nice with it. If I add Google 3D tiles to the scene, it looks like that Cesium Entities have some references to the scene and that causes Vue to apply reactive getters and setters to the whole scene.

So, I’ve switched to using React because it’s easier to control which parts should be reactive, as well as when and how you update Cesium Entities and UI components.

The next important piece is the CZML exporter. The main issue here is that I don’t want to strip away features even if I don’t support editing them.

Even if I don’t have the UI to edit certain properties or animations for properties, a user can load a CZML document with a mixture of supported and unsupported features without losing the unsupported features. That means that the exporter should be more robust and feature complete than editor itself.

I will probably separate the exporter as standalone package because it is valuable on its own — I couldn’t find a way to export Cesium entities as CZML within the library.

Custom data & styling

This part is my favorite. I have some experience creating maps, and when you are working with maps you are not focused on polygons or billboards, you are focused on the data, while graphics are just a tool to represent it.

The previous iteration of the KML-CZML editor was more oriented toward importing KML and massaging it to have the same look in Cesium as it would in Google Earth. That puts focus on graphical features. This time I wanted to make it easy to edit data and style things based on the data.

Demo

We’ll load in some demo data from New York elections in Mike4326.geojson.

From here, we’ll click on the “Data table & Conditional Styling” button. Then, in the menu that opens, we’ll set up Color by value so that we can display different regions differently by our selected attribute. Note the “Mike_prc” column which displays a percent value. The app will select a color from the gradient based on this value.The app will select a color from the gradient based on this value.

To group values together, we’ll toggle the “Fixed gradations” switch. Then hit the “Preview” button. By default, there are 9 gradations.

We want fewer gradations than that. Let’s try out 6.

Not much difference, but we’ll go with the 6 gradations. I’ll hit apply, and you can see the colors are now displayed in the “Style” column, while the “Preview” column has been hidden.

Let’s see how it looks on the map.

Very nice! Now let’s add some labels for a different attribute, the election district.

You can see the text color defaults to black, which won’t read well on our colored districts. Let’s change it by hitting the “edit” button next to the color.

I changed it to a light gray. Let’s look at the map now.

Lots of labels! This is quite a dense area, so you would probably want to zoom in further to see the labels more clearly.

See my previous blog post introducing the Cesium CZML-KML Editor for more about the Cesium CZML-KML editor.

Place Labels in Cesium using Vector Data Tiles

2025-02-13T00:00:00+00:00

Cesium is like an IKEA globe: it can do almost anything, but you have to put it together yourself. One major missing feature is labels for cities. Compare the default views of Google Earth and Cesium, and you’ll notice this immediately.

Left: Google Earth default view, with labels and state lines. Right: Cesium default view, with no labels or markers.

If you’re reading this post, you might be able to find any major U.S. city without any clues, but most people can’t. You can overlay imagery that includes labels as part of the image, but this approach has a significant drawback: as soon as you rotate the view away from north-up, the labels become difficult to read.

In Google Earth, this issue is handled using vector data overlays. Labels, borders, and other similar elements are examples of how useful vector overlays can be.

Cesium also supports vector features such as labels, polylines, and polygons. You can create them manually or use CZML or KML to add such features to a scene. If you use KML, Cesium translates it internally, but the result is the same. Vector features have distinct advantages for 3D geographic data, with labels being the most obvious example.

Challenges of Vector Data in Cesium

Displaying vector data in Cesium comes with some challenges. Since we cannot load and display all data at once, we have two options: keep it as vector data or rasterize it into imagery. Either way, we need to tile the data, breaking it into small chunks and generalizing or simplifying it.

Continuing with the example of labels: tiles covering large areas should include only essential labels (e.g., capital cities) to avoid excessive clutter. Similarly, for polylines such as roads or boundaries, we need to prioritize important roads and simplify their geometries.

Most GeoServers and data providers serve vector tiles encoded as GeoJSON, KML, or other binary formats. However, integrating them into Cesium or Google Earth requires additional steps.

There are two big considerations that need to be taken into account when integrating tiled vector data into any application:

How particular geometric features (points, lines, and polygons) are encoded for every tile. Also, what are their attributes and how should they be represented and styled? This involves considering whether a point should have a label or an icon, what color should it be, etc.
How the data is arranged. This includes how many levels it has, how you fetch new tiles, what the area each tile covers is, and how the software you are integrating with (in our case, Cesium) manages rendering, loading, and unloading the data.

In Google Earth, KML covers both issues in one technology. KML describes features and their styling, while for the arrangement of tiles you can use Network Link Regions. To put it simply, Network Link Regions define an area and as soon as the camera gets close enough to that area, Google Earth loads a new chunk of data for that area. You can read more about that in the KML docs.

In Cesium, this process is covered by multiple technologies, and not all of them work together. We have several encoding and styling options (CZML, KML, GeoJSON), but none of them natively support tiling.

On the other hand, Cesium 3D Tiles work well for large 3D meshes and point clouds, but they do not support CZML, KML, or GeoJSON as tile content.

To bridge this gap, Cesium provides the Vector Data tile format and 3D Tiles Styling.

Although they are still experimental, these features work with the standard Cesium distribution without any hacks or undocumented options.

Since I previously implemented city labels in Cesium, I decided to revisit the task to do it with this new standard in mind. In my earlier implementation, I had to rely on undocumented Cesium features to determine which tiles should be loaded and unloaded. More details about that approach can be found in my previous blog post.

Technical Implementation

For this tileset generation, I use two standards:

Vector Data tile content with tileset styling
- Vector Data tile content defines how each tile is encoded
- Tileset styling determines how points, lines, and polygons are rendered
Implicit tiling
- Implicit tiling defines tile arrangement and availability

Both standards use a mix of JSON and binary-encoded features. In a nutshell, to encode a point with a label you have to write a vctr file, a subtree file and a tileset.json file.

Each vctr file consists of the following sections:

Header: Defines technical data, like the size of the sections in bytes and their offsets
Feature Table: Defines how to read points, lines, or polygons from the binary data section In our case we just specify how many points we have
Batch Table: Defines data specific attributes, in our case that will be a name for a point
Binary data with positions and indices: Coordinates of the points optimized for storage size

Subtree files encode which child tiles are available, which of them have content, and what are the available subtrees.

tileset.json puts all that information together, defining what region the whole tileset covers, specifying that we are using implicit tiling, and defining URL templates for fetching vctr and subtree files.

Add a style which tells Cesium that it should create a label for every point with its name attribute. And congratulations, we have our first set of labels!

Managing Uneven Label Distribution

But as soon as we zoom in we hit a problem: we have too many labels too close to each other.

In order to avoid having the globe polluted with messy clumps of labels when zooming in, we have to discern how the visibility of 3D tile content is determined by Cesium. A key concept for handling this is assigning a geometricError value to each tile. The exact value might be complex to calculate, but the general rule is: the larger the geometricError, the bigger the distance from which a tile should be visible.

So as you zoom in closer, labels from tiles with bigger geometricError will appear sooner. Furthermore, for implicit tiling the geometricError of children tiles should be half of what their parent tiles’ geometricError values are. Practically speaking, this means that the geometricError value assigned to the root tile cascades throughout the system and changes how soon all of the labels become visible. To have some of the labels appear later than the others we have to push them down the tile tree.

The first thing I tried was to set a minimum tree depth for a label based on city size, but the end result was pretty much the same:

The root cause of the points clumping up is not small towns appearing too early, it’s how the populated places themself are distributed. “The Bronx” and “Manhattan” are just big and too close to each other and to “New York City”. If I try to push “Manhattan” deep enough so it doesn’t overlap with “New York City” based just on its size we won’t be able to see Boston or Baltimore or Hamilton, although they have plenty of space to be shown at this zoom level. Hence, we need a way to cluster points and determine point depth based on how much space there is between neighbours.

Clustering Labels

Clustering is a well-established problem in computational geometry, and there are plenty of libraries to solve it, but if I used one of them I would also have to integrate it with the tree structure of the tiles. So instead I’ve implemented a straightforward approach that is effective, although not 100% correct mathematically:

For every level of the tree, calculate a distance threshold. The threshold gets smaller and smaller with every level of the tree. Let’s follow the same pattern as the tiles’ geometricError for this threshold
For every point to be inserted into the tree, calculate the distance to a closest point in the tree
1. If the distance is more than the threshold, just insert the point. If the distance is smaller than the threshold, let’s calculate how many levels we should skip to get the threshold small enough to insert the point at this level
2. If an inserted point is more important than an existing point, then put the inserted point at the current level and push the old one down the tree instead

And so, there you have it:

Next Steps

Further steps I have in mind to expand on this work with vector tiles include:

Enhancing styling options
Encoding polylines
Encoding polygons

Notes

The project is available on GitHub under the Apache-2.0 license: https://github.com/EndPointCorp/cesium-vector-data-tiles.

Place data is from GeoNames.org under the CC-BY license.

Screenshots use Bing Imagery, ArcGIS World Imagery, and Google Earth.

Compressed CZML

2023-06-13T00:00:00+00:00

Let’s talk about CZML, Cesium’s main language for specifying 3D scenes, and how to incorporate external resources such as billboard graphics, material textures, and 3D models into CZML files.

For example, let’s look at how we can include glTF models.

glTF models are composed of multiple files: a single JSON index file along with a variable number of binary buffer files and textures. So, in order to package CZML assets that include glTF models for distribution, you have to read the CZML document itself, then read the referenced glTF files. If they are not binary GLB files, you must also read the glTF files and package all of the files referenced by the glTF models. And if you find this paragraph cumbersome, that’s no accident. Indeed, the whole process is quite cumbersome!

So we are dealing with something like:

CZML Document
- glTF Model
  - buffer1.bin
  - buffer2.bin
  - texture1.png
  - texture2.png
  - …

If you want to keep the glTF model as a single asset, you can convert the glTF files into binary (GLB) files, and then embed them as base64 data links into CZML.

Another example would be a set of points with billboards, let’s say a couple hundred points with plenty of different images. Keeping track of what images you have to ship along with a CZML document is very inconvenient, so you might want to embed the images.

As with 3D models you could use base64 data links, but you will lose readability. You won’t be able to easily edit an image itself; you will have to decode it back into an image file, edit it, re-encode it, and write it back into the CZML file.

And furthermore, while many billboards can share the same image, if you are going to encode it to base64, you either have to repeat the same base64-encoded string over and over or use CZML reference properties. On the one hand, repeating the same base64 string makes a file terribly bloated, while on the other, with CZML reference properties you have to keep track of Entity IDs. Tracking Entity IDs means you need to be sure that you don’t accidentally delete the Entity which others refer to, and you’ll need to copy it if you want to split the dataset into different files.

What I really want is to use the same approach that Google Earth uses for KMZ files: KMZ is just a ZIP archive with a KML document and referenced assets packed together. Let’s do the same trick with CZML.

So the general approach would be:

Read CZMZ ZIP archive.
Index ZIP entries as blob objects.
Find the main CZML document.
Load it with Cesium CzmlDataSource and proxy all local URLs to blobs from step 2.
Add destructor to DataSource to revoke blob URLs.

To set a proxy we have two main options: read the whole CZML document as a JavaScript object and replace all of the URLs with Cesium.Resource objects using a proxy, or provide a Cesium.Resource to CzmlDataSource.load instead of URLs. In most cases the second option is easier, unless you do some preprocessing on the CZML document before loading.

You can read zip archives with a library of your choice. I’m using zip.js because Cesium already uses some methods from it.

const data = await (await fetch(assetPath)).blob();
const reader = new zip.ZipReader(new zip.BlobReader(data));

const entriesMap = new Map();

for (let entry of entries) {
   const blob = await entry.getData(new zip.BlobWriter());
   const blobURL = URL.createObjectURL(blob);

   entriesMap.set('/' + entry.filename, blobURL);
}

Now get the document:

const documentEntry = entries.find(e => /\.czml$/i.test(e.filename));
const documentBlob = entriesMap.get('/' + documentEntry.filename);

And load the DataSource:

DataSourceInstance.load(new Cesium.Resource({
   url: documentBlob,
   proxy: {
      getURL: URL => {
          if (/^blob:/.test(URL)) {
               const blobId = new URL(URL.replace(/^blob:/, '')).pathname;
               const blobURL = entriesMap.get(blobId);
               return blobURL ? blobURL : URL;
           }
           console.warn('URL not found inside czmz', URL);
           return URL;
       }
   }
}));

That’s mostly it. We just want to clean up after ourselves; we have to unregister blob URLs to free the resources.

It’s not documented, but if you remove a DataSource from DataSourceCollection with the destroy parameter set to true, and DataSource has a destroy method, it will be called.

DataSourceInstance.destroy = function() {
   for (let blobUrl of entriesMap.values()) {
       URL.revokeObjectURL(blobUrl);
   }
};

Cesium Labels

2023-05-24T00:00:00+00:00

Improving place labels in CesiumJS, the open source JavaScript library for 3D globes and maps, has been a longstanding request from some of our VisionPort clients. The display of labels embedded in imagery has not been up to their expectations. The names look upside down as the globe is rotated and there’s no option to change the language:

Cesium has vector labels which allow you to anchor some text to a point on a map which will always be aligned with the camera. However, there is no ready-to-use solution to display city names in particular and no way to load them according to a specific zoom level.

To improve performance when displaying labels in Cesium it would make sense to load labels as a tile tree and only show some of the top of the tree at different zoom levels in a manner similar to how KML Regions with NetworkLinks work. Unfortunately, although Cesium supports KML, it doesn’t support KML Regions and NetworkLinks updates on Region change.

Another off-the-shelf solution that might conceivably work would be to use Cesium 3D tiles, but unfortunately, tiles do not support 2D Billboards.

Calculating regions and their level of detail is complicated, but Cesium already does most of that work for us. Cesium already calculates visible tiles and their corresponding levels of detail for ImageryProviders. An ImageryProvider is supposed to load imagery for a given tile’s coordinates and zoom level, which is almost what we want, except that we want to render some 3D primitives for labels, not 2D images for the earth surface.

We can read what tiles are going to be rendered by Cesium and store them in a variable:

const tilesToRender = viewer.scene.globe._surface._tilesToRender;

Then, we get the TMS coordinates out of the visible tiles on screen. Then we calculate the difference between the currently visible tiles and the new ones. We grab all the new tiles that we need from that list, and then we create the Entities with labels and some other styling properties.

Backend and data source

To source the labels we use GeoNames. They have a nice dataset for cities with their population included in the data. We take the city labels they provide and store them into a quadtree. Each node in the quadtree has 10 labels associated with it, starting with the largest population at the top of the data structure and going down. Based on the altitude we traverse a certain distance down the quadtree returning all cities from each node that corresponds to the tile requested.

Here is a video demonstrating how labels display with this new feature we’ve developed:

Future Plans

Currently, the entity creation is done on the frontend, but we are planning to move this to the backend sometime soon. There is also some crowding of the labels when zooming out since surface tiles aren’t immediately updated. The tiles can likely be filtered to remove unneeded ones more aggressively.

Running On Your System

We have released this code on our GitHub under the Apache license for everyone to use.

To get this up and running on your local system, start with a Git clone:

git clone https://github.com/EndPointCorp/tiled-city-labels.git

Then within the repo there’s a README to follow. We will give instructions here, but if they differ from the README follow those instead:

cd tiled-city-labels
docker build -t cesium-labels .
docker run -p 48088:48088 --rm cesium-labels

Then in a new terminal window still inside the project:

cd demo/
python -m SimpleHTTPServer 8000

Now you can navigate to http://localhost:8000/ in your browser and see the city labels up and running. To customize this to your own system, you can use the mixin demo/js/CitiesDataSource.js and add that to your own project. You can also change the port/server used in the mixin by editing the fetch command inside the queryData function.

CZML-KML Editor Geometry Editing

2021-04-13T00:00:00+00:00

We are happy to introduce a new feature for the Cesium CZML-KML Editor: polygons and polylines geometry editing. You can now edit geometries for existing entities and move entered points during the creation process. Here is a video with a short summary of the editing process:

See our previous blog post introducing the Cesium CZML-KML Editor for further reference.

Announcing the Cesium KML-CZML Editor

2020-12-21T00:00:00+00:00

End Point’s immersive technology team is happy to present a great new tool for the rapidly growing Cesium community: Cesium KML-CZML Editor. The editor gives users the ability to visually and dynamically edit KML and CZML in its Cesium browser window. Updates made with it can be exported at any time to CZML, the native markup language for Cesium.

The Cesium KML-CZML Editor addresses an important but hitherto unaddressed need of the Cesium community: It provides an intuitive interface for making adjustments to fix the many inconsistencies with how KML created for (and often by) Google Earth appears on 3D maps rendered with Cesium. It is a powerful tool for converting and adapting KML for Google Earth into CZML that displays nicely in Cesium. The editor also works as a visual editor for creating and editing CZML, regardless of whether you’re converting from KML.

The inconsistencies with how Cesium displays KML created for Google Earth are due to occasional differences between how Cesium and Google Earth render KML when various attributes aren’t specifically set within a given instance of code. The situation is similar to how web browsers sometimes interpret given instances of HTML differently. Just as with HTML, KML doesn’t require every attribute to be defined in a given instance of markup code.

On the left side we have the editor toolbar, and on the right side the Cesium globe showing loaded or created entities the way they would appear in Cesium.

The Editor Toolbar consist of the following areas:

File Import: you can load KML, KMZ, CZML and GeoJSON formatted data, and you can load multiple files to combine them into one CZML document.
Creation tools.
A list of uploaded or created entities (will appear after upload or creation of a new entity).
The actual editor for entity properties (will appear after entity selection).

Let’s start with a very basic example of highlighting a building by marking it with a pin in Google Earth:

Now let’s move the camera about in different ways, especially noticing how the pin appears when zooming in and out. The pin stays close to the top of the building.

Sorry, your browser doesn’t support embedded videos.

Then let’s open the same KML in Cesium with a 3D building tileset loaded, to compare apples to apples:

Sorry, your browser doesn’t support embedded videos.

It’s easy to see that the green frame which is placed around the geographic position stays around the building, but the icon point of rotation in Cesium doesn’t match the one in Google Earth and the pin falls through the roof and lifts up unfortunately high above the building.

KML doesn’t enforce certain aspects of its representation. If certain attributes are not specified or can’t be implemented exactly, then the KML browsers have the freedom to set different default values for them.

In this example, Cesium and Google Earth display different pixel offsets for the pin icon, because in KML the offset is specified as a ratio of the image, but Cesium specifies the offset in pixels. Cesium converts the pixel offset of the pin from the ratio specified, but with some errors. Cesium reverses the X axis, and in some cases Cesium also calculates the pin icon image size incorrectly. So here it calculates the X offset as -4, which moves the pin icon to the left. To fix that, we can reverse the X axis back to 4 or even move the pin icon 8 pixels further to the right.

🡆

The next issue is how the Z coordinate (altitude) is interpreted. Is it above sea level, above land according to some averaged model of the land, or on the land directly below a point?

Note that 3D tilesets in Cesium are absolutely positioned. This means that if you show 3D buildings and want your pin to stick to a building, it’s better to use absolute elevation. Hence, it makes sense to set Height Reference to NONE, which will force Cesium to use the absolute pin position.

Another option in cases like this is to use relative elevation. This can be helpful if you don’t use 3D tiles, but instead use 3D terrain data, for example, with Cesium World Terrain or Maptiler. It’s especially helpful if you will be switching 3D terrain on and off. In this case, a relatively positioned pin will follow the elevation regardless of whether 3D terrain is turned on or off.

To set it up, adjust Altitude and set Height Reference to RELATIVE_TO_GROUND:

Here are the results for both options:

Sorry, your browser doesn’t support embedded videos.

As you can see, now we have the pin-point of the marker stuck to the desired location.

These are the basics for how to match pins created in Google Earth with their Cesium representations, but in Cesium there are many more options for rendering pins. You can read the relevant Cesium documentation (in Cesium terminology Pins are called Billboards) or interactively explore a live version of this editor to change color, rotation, translucency by distance, and other properties.

Now let’s look at a polygon created in KML for Google Earth:

Then let’s open it in Cesium:

Well, we can select a polygon, but we don’t see it. This happens because the 3D terrain data covers the polygon. Just changing the Height reference helps, but it’s still not what we want:

Cesium has some default assumptions about polygons and rectangles and when to clamp them to the ground.

As commented in the Cesium SandCastle Clamp to Terrain demo code:

Corridors, polygons and rectangles will be clamped automatically if they are filled with a constant color and have no height or extruded height.

NOTE: Setting height to 0 will disable clamping.

So to get a polygon actually clamped to ground, we have to delete the Height property, not just set it to 0:

Now let’s add a 3D tileset:

And again, this is probably not exactly what you wanted. By default, Cesium doesn’t know what type of 3D tileset you would prefer, or whether you want the polygons to cover the tiles, or the tiles to cover the polygons. If you have a fairly large polygon covering a whole city, and a fairly low resolution 3D tileset, you probably want to highlight the whole area. But in the example above, we want our polygon to stick to the ground but not the buildings.

Next, let’s use the Classification Type field, setting it to “TERRAIN” to select what the clamped polygon applies to:

Now, let’s open some exported data. Here’s a typical set of exported points generated with geojson.io:

Let’s choose a point and change its icon and its icon’s vertical alignment (so it doesn’t fall through the terrain) and dimensions:

Here we have selected one icon and updated its properties to make it appear as we want, but changing all the icons one by one would take forever, especially for large data sets.

Click “COPY TO OTHER PINS”:

On the left is a list with all the entities to which the changed properties are applicable and on the right is the list of the properties that were changed for the model entity selected. By default, all the properties are checked to be copied to applicable entities but in this example we only want to change the vertical alignment for all the pins, but want to keep the icon and icon dimension of the other pins unchanged. So we uncheck the image, width and height properties:

Below we see how our scene looks after the update is applied. All the pins are above the ground, but the icons and dimensions are not changed:

After you have all the data styled the way you want, download your CZML!

The Cesium KML-CZML Editor code is Apache 2 licensed. It is available here.

Liquid Galaxy at 2017 BOMA International Annual Conference & Expo

2017-07-03T00:00:00+00:00

We just returned from Nashville after bringing Liquid Galaxy to the 2017 BOMA International Annual Conference & Expo. Commercial real estate has always been a seamless fit for Liquid Galaxy due to the system’s ability to showcase real estate and property data in an interactive and panoramic setting. Within real estate, Liquid Galaxy was first used by CBRE and has since been adopted by Hilton, JLL, and Prologis to name a few.

In preparation for BOMA (Building Owners and Managers Association), we prepared sample commercial real estate content on our content management system to be displayed on the Liquid Galaxy. This included the creation of content about Hudson Yards, the new development being built in lower Manhattan.

The content that was created demonstrates how brokers and directors at commercial real estate companies can tell an immersive, panoramic, and interactive story to their potential clients and investors. Future developments can be shown in developing areas, and with the content management system you can create stories that include videos, images, and 3D models of these future developments. The following video demonstrates this well:

We were able to effectively showcase our ability to incorporate 3D models and mapping layers at BOMA through the use of Google Earth, Cesium, ArcGIS, Unity, and Sketchfab. We were also able to pull data and develop content for neighboring booths and visitors, demonstrating what an easy and data-agnostic platform Liquid Galaxy can be.

We’re very excited about the increasing traction we have in the real estate industry, and hope our involvement with BOMA will take that to the next level. If you’d like to learn more about Liquid Galaxy, please visit our website.

Successful First GEOINT Symposium for End Point Liquid Galaxy

2017-06-16T00:00:00+00:00

This past week, End Point attended GEOINT Symposium to showcase Liquid Galaxy as an immersive panoramic GIS solution to GEOINT attendees and exhibitors alike.

At the show, we showcased Cesium integrating with ArcGIS and WMS, Google Earth, Street View, Sketchfab, Unity, and panoramic video. Using our Content Management System, we created content around these various features so visitors to our booth could take in the full spectrum of capabilities that the Liquid Galaxy provides.

Additionally, we were able to take data feeds for multiple other booths and display their content during the show! Our work served to show everyone at the conference that the Liquid Galaxy is a data-agnostic immersive platform that can handle any sort of data stream and offer data in a brilliant display. This can be used to show your large complex data sets in briefing rooms, conference rooms, or command centers.

Given the incredible draw of the Liquid Galaxy, the GEOINT team took special interest in our system and formally interviewed Ben Goldstein in front of the system to learn more! You can view the video of the interview here:

We look forward to developing the relationships we created at GEOINT, and hope to participate further in this great community moving forward. If you would like to learn more please visit our Liquid Galaxy website!

Full Cesium Mapping on the Liquid Galaxy

2017-02-07T00:00:00+00:00

A few months ago, we shared a video and some early work we had done with bringing the Cesium open source mapping application to the Liquid Galaxy. We’ve now completed a full deployment for Smartrac, a retail tracking analytics provider, using Cesium in a production environment! This project presented a number of technical challenges beyond the early prototype work, but also brought great results for the client and garnered a fair amount of attention in the press, to everyone’s benefit.

Cesium is an open source mapping application that separates out the tile sets, elevation, and markup language. This separation allows for flexibility at each major element:

We can use a specific terrain elevation data set while substituting any one of several map “skins” to drape on that elevation: a simple color coded map, a nighttime illumination map, even a water-colored “pirate map” look.
For the terrain, we can download as much or as little is needed: As the Cesium viewer zooms in on a given spot, Cesium uses a sort of fractal method to download finer and finer resolution terrains in just the surrounding area, eventually getting to the data limit of the set. This gradual approach balances download requirements with viewable accuracy. In our case, we downloaded an entire terrain set up to level 14 (Earth from high in space is level 1, then zooms in to levels 2, 3, 4, etc.) which gave us a pretty good resolution while conserving disk space. (The data up to level 14 totaled about 250 GB.)
Using some KML tools we have developed for past projects and adapting to CZML (“cesium language”, get it?), we were able to take Smartrac’s supply chain data and show a comprehensive overview of the product flow from factories in southeast Asia through a distribution center in Seattle and on to retail stores throughout the Western United States.

The debut for this project was the National Retail Federation convention at the Javitz Center in New York City. Smartrac (and we also) wanted to avoid any show-stoppers that might come from a sketchy internet connection. So, we downloaded the map tiles, a terrain set, built our visualizations, and saved the whole thing locally on the head node of the Liquid Galaxy server stack, which sat in the back of the booth behind the screens.

The show was a great success, with visitors running through the visualizations almost non-stop for 3 days. The client is now taking the Liquid Galaxy and the Cesium visualizations on to another convention in Europe next month. The NRF, IBM, and several other ecommerce bloggers wrote up the platform, which brings good press for Smartrac, Cesium, and the Liquid Galaxy.

Smartrac’s Liquid Galaxy at National Retail Federation

2017-01-25T00:00:00+00:00

Last week, Smartrac exhibited at the retail industry’s BIG Show, NRF 2017, using a Liquid Galaxy with custom animations to showcase their technology.

Smartrac provides data analytics to retail chains by tracking physical goods with NFC and Bluetooth tags that combine to track goods all the way from the factory to the distribution center to retail stores. It’s a complex but complete solution. How best to visualize all that data and show the incredible value that Smartrac brings? Seven screens with real time maps in Cesium, 3D store models in Unity, and browser-based dashboards, of course. End Point has been working with Smartrac for a number of years as a development resource on their SmartCosmos platform, helping them with UX and back-end database interfaces. This work included development of REST-based APIs for data handling, as well as a Virtual Reality project utilizing the Unity game engine to visualize data and marketing materials directly on several platforms including the Oculus Rift, the Samsung Gear 7 VR, and WebGL. Bringing that back-end work forward in a highly visible platform for the retail conference was a natural extension for them, and the Liquid Galaxy fulfilled that role perfectly. The large Liquid Galaxy display allowed Smartrac to showcase some of their tools on a much larger scale.

For this project, End Point deployed two new technologies for the Liquid Galaxy:

Cesium Maps - Smartrac had two major requirements for their data visualizations: show the complexity of the solution and global reach, while also making the map data offline wherever possible to avoid the risk of sketchy Internet connections at the convention center (a constant risk). For this, we deployed Cesium instead of Google Earth, as it allowed for a fully offline tileset that we could store locally on the server, as well as providing a rich data visualization set (we’ve shown other examples before).
Unity3D Models - Smartrac also wanted to show how their product tracking works in a typical retail store. Rather than trying to wire a whole solution during the short period for a convention, however, they made the call to visualize everything with Unity, a very popular 3D rendering engine. Given the multiple screens of the Liquid Galaxy, and our ability to adjust the view angle for each screen in the arch around the viewers, this Unity solution would be very immersive and able to tell their story quite well.

Smartrac showcased multiple scenes that incorporated 3D content with live data, labels superimposed on maps, and a multitude of supporting metrics. End Point developers worked on custom animation to show their tools in a engaging demo. During the convention, Smartrac had representatives leading attendees through the Liquid Galaxy presentations to show their data. Video of these presentations can be viewed below.

Smartrac’s Liquid Galaxy received positive feedback from everyone who saw it, exhibitors and attendees alike. Smartrac felt it was a great way to walk through their content, and attendees both enjoyed the content and were intrigued by the display on which they were seeing the content. Many attendees who had never seen Liquid Galaxy inquired about it.

If you’d like to learn more about Liquid Galaxy or new projects we are working on or having custom content developed, please visit our Liquid Galaxy website or contact us here.

Cesium on the Liquid Galaxy

2016-07-13T00:00:00+00:00

Data visualization continues to evolve, with ever-more complex data sets available openly, and a corresponding increased pace in visualization tools. In mapping GIS data, the Cesium app is gaining quite a bit of traction. As we continue to branch out with new functionality and visualization apps for the Liquid Galaxy, we wanted to try the Cesium app as well.

Cesium is written all in JavaScript WebGL and offers some nice advantages over other engines: it’s open source, it’s flexible, and it’s quick. It can accept an array of points, shapefiles, 3D models, and even KML. The JavaScript then chews these up and delivers a nice consistent 3D environment that we can fly through with the SpaceNav controller, set scenes in a presentation to tell a story, or mix together with video or graphic popups for a fully immersive multimedia experience. Cesium is open source, and provides a great deal of flexibility and accessibility to build different kinds of data visualizations and interactions. There are a lot of new startups exploiting this platform and we welcome the opportunity to work with them.

As we’ve written previously, the main advantage of the Liquid Galaxy platform is the ability to adjust the viewing angle on each screen to match the physical offset, avoiding (as much as possible) artificial distortions, fisheye views, or image stretching. The trickiest bit of this project was setting the distributed camera driver, which takes input from the SpaceNav controller and correctly aligns the view position for each of the geometrically offset displays. Once the math is worked out, it’s relatively quick work to put the settings into a rosbridge WebSockets driver. Once again, we’re really enjoying the flexibility that the ROS architecture grants this system.

Looking forward, we anticipate this can open up many more visualizations for the Liquid Galaxy. As we continue to roll out in corporate, educational, and archival environments such as real estate brokerages, hospitality service providers, universities, and museums, the Cesium platform will offer yet another way for our customers to visualize and interact with their data.

Story telling with Cesium

2016-03-07T00:00:00+00:00

Let me tell you about my own town

I was born in Yekaterinburg. It’s a middle-sized town in Russia.

Most likely you don’t know where it is. So let me show you:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Hello World!</title>
    <script src="/cesium/Build/Cesium/Cesium.js"></script>
    <link rel="stylesheet" href="layout.css"></link>
  </head>
<body>
  <div id="cesiumContainer"></div>
  <script>
    var viewer = new Cesium.Viewer('cesiumContainer');
    (function(){
        var ekb = viewer.entities.add({
          name : 'Yekaterinburg',
          // Lon, Lat coordinates
          position : Cesium.Cartesian3.fromDegrees(60.6054, 56.8389),
          // Styled geometry
          point : {
            pixelSize : 5,
          color : Cesium.Color.RED
          },
          // Labeling
          label : {
            text : 'Yekaterinburg',
            font : '16pt monospace',
            style: Cesium.LabelStyle.FILL_AND_OUTLINE,
            outlineWidth : 2,
            verticalOrigin : Cesium.VerticalOrigin.BOTTOM,
            pixelOffset : new Cesium.Cartesian2(0, -9)
          }
        });

        // How to place camera around point
        var heading = Cesium.Math.toRadians(0);
        var pitch = Cesium.Math.toRadians(-30);
        viewer.zoomTo(ekb, new Cesium.HeadingPitchRange(heading, pitch, 10000));
    })();
  </script>
</body>
</html>

Now, I would like to tell you about the history of my town. In the beginning it was a fortified metallurgical plant with a few residential blocks and some public buildings. It was relatively small.

I could say that its size was about the size of a modern city-center, but that description is too vague. I think the best way to tell you something about the city is with a map.

I’ll show you two maps.

A map from 1750, early in the town’s history when it was just a factory: http://www.retromap.ru/m.php#r=1417506
A map from 1924 at about the start of Soviet industrialization, just before Yekaterinburg became the industrial center of the Urals: http://www.retromap.ru/m.php#r=1419241

Thanks for these beautiful maps to http://www.retromap.ru.

The map from 1750 is a small image, so I’ve added it via SingleTileImageryProvider. Just specifying the src and coordinates:

function setupImagery() {
    var layers = viewer.scene.imageryLayers;

    var s = 56.8321929;
    var n = 56.8442609;
    var w = 60.5878970;
    var e = 60.6187892;
    var l1750 = layers.addImageryProvider(new Cesium.SingleTileImageryProvider({
        url : 'assets/1750.png',
        rectangle : Cesium.Rectangle.fromDegrees(w,s,e,n)
    }));
    l1750.alpha = 0.75;
}

Now you can see how small my town was initially.

The second image is larger, so I’ve split it up into tiles. If you use gdal2tiles.py for generating tiles, it creates all the metadata necessary for TMS and you are able connect the imagery set via TileMapServiceImageryProvider. Otherwise, you can use UrlTemplateImageryProvider.

var l1924 = layers.addImageryProvider(new Cesium.TileMapServiceImageryProvider({
    url: 'assets/1924t',
    minimumLevel: 8,
    maximumLevel: 16,
    credit: 'retromap.ru'
}));

l1924.alpha = 0.75;

I’ve used QGIS for geo referencing. Here is a good tutorial.

User interface and Angular.js

And below here you see how I’ve added some controls for visibility and opacity of the overlays. Later we will bind them with an Angular-driven GUI:

// APP is global

var layersHash = {
    'l1750': l1750,
    'l1924': l1924
}

APP.setAlpha = function(layer, alpha) {
    if(layersHash[layer] && layersHash[layer].alpha !== undefined) {
        layersHash[layer].alpha = alpha;
    }
};

APP.show = function(layer) {
    if(layersHash[layer] && layers.indexOf(layersHash[layer]) < 0) {
        layers.add(layersHash[layer]);
    }
};

Why not keep our views in a namespace and access them directly from an Angular controller? Using this approach will give us a lot of flexibility:

You can split up the GUI and Cesium modules and use something else instead of Cesium or Angular.
You are able to make a proxy for APP and add business logic to the calls made to it.
It just feels right not to meld all parts of the application into one unmanageble mish-mash of code.

For the GUI I’ve added a big slider for the timeline, small sliders for layer opacity, checkboxes for visibility, and call APP methods via Angular’s $watch.

$scope.$watch('slider.value', function() {
    var v = $scope.slider.options.stepsArray[$scope.slider.value];
    if (v >= 1723 && v <= 1830) {
        $scope.menu.layers[0].active = true;
        $scope.menu.layers[1].active = false;
    }
    if (v > 1830 && v < 1980) {
        $scope.menu.layers[0].active = false;
        $scope.menu.layers[1].active = true;
    }
    if(v >= 1980) {
        $scope.menu.layers[0].active = false;
        $scope.menu.layers[1].active = false;
    }

    $scope.updateLayers();
});

$scope.updateLayers = function() {
    for (var i = 0; i < $scope.menu.layers.length; i++) {
        if ($scope.menu.layers[i].active ) {
            APP.show && APP.show($scope.menu.layers[i].name);
        }
        else {
            APP.hide && APP.hide($scope.menu.layers[i].name);
        }
    }
};

Back to the history

Yekaterinburg was founded on November 7, 1723. This is the date of the first test-run of the forging hammers in the new factory. The original factory design by Tatishew had 40 forging hammers and 4 blast furnaces. That may well have made it the best equipped and most productive factory of its time.

Now I want to add text to the application. Also, I have some cool pictures of the hammers and furnaces. Adding an overlay for text and binding its content is a matter of CSS and ng-include/ng-bind knowledge and it’s a bit out of scope for this post, but let’s push on and add some pictures and link them to the timeline. Cesium has KmlDataSource for KML loading and parsing. This is how my application loads and accesses these attributes:

var entityByName = {};
var promise = Cesium.KmlDataSource.load('assets/foto.kml');
promise.then(function(dataSource) {
    viewer.dataSources.add(dataSource);

    //KML entities
    var entities = dataSource.entities.values;
    for (var i = 0; i < entities.length; i++) {
        var entity = entities[i];
        // <Data> attributes, parsed into js object
        var ed = entity.kml.extendedData;

        entityByName[entity.id] = {
            'entity': entity,
            since: parseInt(ed.since.value),
            to: parseInt(ed.to.value)
        };
    }
});

Add bindings for Angular:

APP.filterEtityByY = function(y) {
    for (var k in entityByName) {
        if(entityByName.hasOwnProperty(k)) {
            var s = entityByName[k].since;
            var t = entityByName[k].to;
            entityByName[k].entity.show = (y >= s && y <= t);
        }
    }
};

var heading = Cesium.Math.toRadians(0);
var pitch = Cesium.Math.toRadians(-30);
var distanceMeters = 500;
var enityHeading = new Cesium.HeadingPitchRange(heading, pitch, distanceMeters);

APP.zoomToEntity = function(name) {
    if(name && entityByName[name]) {
        viewer.zoomTo(entityByName[name].entity, enityHeading);
    }
};

I’ve added object timespans via extended data. If you want to use the Cesium/GE default timeline, you should do it via a TimeSpan section in the KML’s entries:

<timespan>
  <begin>2000-01-00T00:00:00Z</begin>
    <end>2000-02-00T00:00:00Z</end>
 </timespan>

Another interesting fact about my town is that between 1924 and 1991 it had a different name: Sverdlovsk (Свердловск). So I’ve added town name changing via APP and connected it to the timeline.

Using APP.filterEtityByY and APP.zoomToEntity it’s relatively easy to connect a page hash like example.com/#!/feature/smth with features from KML. One point to note is that I use my own hash’s path part parser instead of ngRoute’s approach.

You can see how all these elements work together at https://dmitry.endpointdev.com/cesium/ekb/ and the sources are on GitHub: https://github.com/kiselev-dv/EkbHistory/tree/master