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.

Exploring Geodatabase Files

2024-08-14T00:00:00+00:00

One of our clients recently provided us with a dataset of real estate properties that they manage, and asked us to generate content based off of the points and polygons in the dataset.

We will walk through the process of extracting polygons, placemarks, and other info from a geodatabase file and converting them into separate KML files using the ogr2ogr command-line tool, adding some logic to the data selection to limit the subset of features. We will also explore the GDB file using the GDAL Python library to export the data as JSON for use in other scripts.

Prerequisites

Basic understanding of geospatial data
Installed versions of the GDAL/OGR library
A geodatabase file (.gdb, .gdb.zip, or .shp)

A first look into the contents of the GDB file

ogrinfo example.gdb.zip

This command will list all layers that are available in the dataset. Add a specific layer as a parameter to the same command, and it will output all the fields, their types, and values for every feature in the layer.

ogrinfo example.gdb.zip a_layer_name

The parameter -so can be used to omit the values from the output and get only the layer field names and types:

#$> ogrinfo example.gdb.zip Land_Points -so
INFO: Open of `example.gdb.zip'
      using driver `OpenFileGDB' successful.

Layer name: Land_Points
Geometry: Point
Feature Count: 219
Extent: (-122.699891, -23.590280) - (139.763352, 59.622821)
Layer SRS WKT:
GEOGCRS["WGS 84",
    DATUM["World Geodetic System 1984",
        ELLIPSOID["WGS 84",6378137,298.257223563,
            LENGTHUNIT["metre",1]]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433]],
    CS[ellipsoidal,2],
        AXIS["geodetic latitude (Lat)",north,
            ORDER[2],
        ANGLEUNIT["degree",0.0174532925199433]],
    USAGE[
        SCOPE["unknown"],
        AREA["World"],
        BBOX[-90,-180,90,180]],
    ID["EPSG",4326]]
Data axis to CRS axis mapping: 2,1
FID Column = OBJECTID
Geometry Column = Shape
asset_type: Integer (0.0)
asset_id: String (15.0)
property_code: String (255.0)
full_address_text: String (255.0)
land_name: String (255.0)
land_address1: String (255.0)
land_city: String (255.0)
land_sate_code: String (50.0)
land_postal_code: String (10.0)
land_country_code: String (50.0)
division_name: String (255.0)
region_name: String (255.0)
market_name: String (255.0)
submarket_name: String (255.0)
supplemental_portfolio_name: String (255.0)
ownership_name: String (255.0)
land_held_for_sale_acre: Real (0.0)
land_held_for_sale_hect: Real (0.0)
land_held_for_development_acre: Real (0.0)
land_held_for_development_hect: Real (0.0)
total_land_acre: Real (0.0)
total_land_hectare: Real (0.0)
buildable_area_sf: Real (0.0)
buildable_area_sm: Real (0.0)
buildable_area_tsubo: Real (0.0)
land_latitude: Real (0.0)
land_longitude: Real (0.0)
geocoded: Integer (0.0) DEFAULT 0
globalid: String (0.0) NOT NULL
created_user: String (255.0)
created_date: DateTime (0.0)
last_edited_user:  String (255.0)
last_edited_date: DateTime (0.0)

This command shows you information for a single layer, which can be helpful if you are only looking for certain values. However, the geographic data is not much to look at in the terminal. To visualize it, we can convert the data to KML, which applications like Google Earth or Cesium can render while keeping the information as text that can be read:

ogr2ogr -f "KML" example_output.kml example.gdb.zip layer_name

-f "KML" specifies the output format
example_output.kml is the name of the output KML file
example.gdb.zip is the path to the geodatabase file
layer_name is the geodatabase layer to export

This command will export into a KML file:

All the geometries in the layer, be it placemarks or polygons in our case
All the other fields of information as extended data, which will show up for each feature as a balloon table when visualized in Google Earth

The `ogr2ogr` `-sql` option

The default balloon popup was not the outcome we wanted for this KML file. We first used sed to remove all the extended data from the KML files, but after looking into it a bit further, we found an ogr2ogr option, -sql, that made the data filtering easier. This option lets us add a query to the command just like getting the data from a SQL database.

1. Extract property names

To create a KML file with just the names of the properties, look up the layers and fields in them using ogrinfo and find the points layer that has the names—in this case, Layer_Points. Then, add the desired SQL query to the command.

ogr2ogr -f "KML" output_names.kml example.gdb.zip -sql "SELECT name FROM Layer_Points"

2. Extract polygons only

The polygon geometries are stored in Layer_Polygons. They can be selected using the special OGR field OGR_GEOMETRY that refers to the geometry of the selected layer:

ogr2ogr -f "KML" output_polygons.kml example.gdb.zip -sql "SELECT OGR_GEOMETRY FROM Layer_Polygons"

3. Create KML with pins and names

To create a KML file with property names as placemarks with pins, we just select the name. The point placemark seems to be included with all data:

ogr2ogr -f "KML" output_pins.kml input.gdb layer_name -sql "SELECT name FROM layer_name"

4. Create KML with pins only, no names

To get the points with nothing else, we use the SQLite MakePoint function, which selects a list of points from the KML.

ogr2ogr -f "KML" output_pins.kml input.gdb layer_name -dialect SQLite -sql "SELECT MakePoint(land_longitude, land_latitude) AS geom FROM Land_Points"

5. Extract limited properties

For extracting a limited number of properties, we can add the WHERE clause to the SQL command:

ogr2ogr -f "KML" output_pins.kml input.gdb layer_name -sql "SELECT name FROM layer_name"

We can also use the ogr2ogr -where flag to use that part of the query only:

ogr2ogr -f "KML" limited_output_polygons.kml input.gdb layer_name -where "ID IN (1, 2, 3)"

6. Run it all in a Python script

There is a Python GDAL library, which I will cover the basics of later, but first, here is a simplified example using Python subprocess to run the ogr2ogr commands we tested in the terminal.

import subprocess

gdb_file = "example.gdb.zip"
column_name = "p_code"
elem_str = "'a1', 'a2', 'b1', 'b3'"

sql_land_labels = f"SELECT land_name FROM Land_Points WHERE {column_name} IN ({elem_str})"
subprocess.run(['ogr2ogr', '-f', 'KML', 'land_labels.kml', gdb_file, '-sql', sql_land_labels])

sql_land_points = f"SELECT MakePoint(land_longitude, land_latitude) AS geom FROM Land_Points WHERE {column_name} IN ({elem_str})"
subprocess.run(['ogr2ogr', '-f', 'KML', 'land_points.kml', gdb_file, '-dialect', 'SQLite', '-sql', sql_land_points])

sql_land_polygons = f"SELECT OGR_GEOMETRY FROM Land_Polygons WHERE {column_name} IN ({elem_str})"
subprocess.run(['ogr2ogr', '-f', 'KML', 'land_pols.kml', gdb_file, '-sql', sql_land_polygons])

This script will create the three different KML files that we usually need for our presentations. We used variables for the gdb_file, column_name, and elem_str command line parameters to make the script easy to use for selecting other data. We also use them in other scripts to join, apply custom styling, and add regions to the KMLs, which will be covered in another blog post.

7. Extract all data as JSON from one layer using the Python GDAL library

I probably should have started here, but I only used the Python library later on in the process to join the gdp.zip file data with data from other sources (spreadsheets, emails, etc.).

First, install the GDAL library:

pip install gdal

Then you can use the following Python script, changing as necessary the gdb_file, layer_name, and the unique field chosen to structure the data. The code is explained in the comments.

#!/bin/python

import json
from osgeo import ogr

# Open the Geodatabase file
driver = ogr.GetDriverByName('OpenFileGDB')
gdb_file = 'example.gdb.zip'
data_source = driver.Open(gdb_file, 0)

# Get the layer
layer_name = 'Building_Points'
layer = data_source.GetLayerByName(layer_name)
if layer:
    # Get the layer definition
    layer_defn = layer.GetLayerDefn()

    # Get the number of fields in the layer
    num_fields = layer_defn.GetFieldCount()

    # Initialize an empty list to store field names
    field_names = []

    # Iterate over each field and add its name to the list
    for i in range(num_fields):
        field_defn = layer_defn.GetFieldDefn(i)
        field_name = field_defn.GetName()
        field_names.append(field_name)

    print("Field names:", field_names)
else:
    print(f"Layer '{layer_name}' not found.")

all_info = {}

# Iterate over all features and organize all field names under a unique one for the dictionary structure
for feature in layer:
    if feature is not None:
        globalid = feature.GetField('globalid')
        all_info[globalid] = {}
        for fn in field_names:
            all_info[globalid][fn] = feature.GetField(fn)

# Close the data source
data_source = None

# Save information to a JSON file
output_file = 'info.json'
with open(output_file, 'w') as json_file:
    json.dump(all_info, json_file, indent=4)
print(f"Information saved to {output_file}")

The script will create a JSON file with all the information on the layer.

Conclusion

Following these steps, we can efficiently manage and visualize geospatial data using ogr2ogr, SQL, and KML, and in some cases, JSON. These methods allow for a high degree of customization and can be tailored to specific project requirements.

Additional Resources

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.

The New Earth

2017-04-21T00:00:00+00:00

As many of you may have seen, earlier this week Google released a major upgrade to the Google Earth app. Overall, it’s much improved, sharper, and a deeper experience for viewers. We will be upgrading/incorporating our managed fleet of Liquid Galaxies over the next two months after we’ve had a chance to fully test its functionality and polish the integration points, but here are some observations for how we see this updated app impacting the overall Liquid Galaxy experience.

Hooray! The new Earth is here! The New Earth is here! Certainly, this is exciting for us. The Google Earth app plays a key central role in the Liquid Galaxy viewing experience, so a major upgrade like this is a most welcome development. So far, the reception has been positive. We anticipate it will continue to get even better as people really sink their hands into the capabilities and mashup opportunities this browser-based Earth presents.

We tested some pre-release versions of this application, and successfully integrated them with the Liquid Galaxy and are very happy with how we are able to view-synchronize unique instances of the new Google Earth across displays with appropriate geometrically configured offsets.

What to look for in this new application:

Stability: The new Google Earth runs as a NaCl application in a Chrome browser. This is an enormous advance for Google Earth. As an application in Chrome it is instantly accessible to billions of new users with their established expectations. Because the new Google Earth uses Chrome the Google Earth developers will no longer need to engage in the minutiae of having to support multiple desktop operating systems, but now can instead concentrate on the core-functionality of Google Earth and leverage the enormous amount of work that the Chrome browser developers do to make Chrome a cross-platform application.
Smoother 3D: The (older) Google Earth sometimes has a sort of “melted ice cream” look to the 3D buildings in many situations. Often, buildings fail to fully load from certain viewpoints. From what we’re seeing so far, the 3D renderings in the New Earth appear to be a lot sharper and cleaner.
Browser-based possibilities: As focus turns more and more to browser-based apps, and as JavaScript libraries continue to mature, the opportunities and possibilities for how to display various data types, data visualizations, and interactions really start to multiply. We can already see this with the sort of deeper stories and knowledge cards that Google is including in the Google Earth interface. We hope to take the ball and run with it, as the Liquid Galaxy can already handle a host of different media types. We might exploit layers, smart use controls, realtime content integration from other available databases, and… okay, I’m getting ahead of myself.

The New Google Earth makes a major point of featuring stories and deeper contextual information, rather than just ogling at the terrain: as pretty as the Grand Canyon is to look at, knowing a little about the explorers, trails, and history makes it such a nicer experience to view. We’ve gone through the same evolution with the Liquid Galaxy: it used to be just a big Google Earth viewer, but we quickly realized the need for more context and usable information for a richer interaction with the viewers by combining Earth with street view, panoramic video, 3D objects, etc. It’s why we built a content management system to create presentations with scenes. We anticipate that the knowledge cards and deeper information that Google is integrating here will only strengthen that interaction.

We are looking to roll out the new Google Earth to the fleet in the next couple of months. We need to do a lot of testing and then update the Liquid Galaxies with minimal (or no) disturbance to our clients, many of whom rely on the platform as a daily sales and showcasing tool for their businesses. As always, if you have any questions, please reach us directly via email or call.

ROS Platform Upgrades for Liquid Galaxy

2015-12-14T00:00:00+00:00

For the last few months, End Point has been rolling out a new application framework along with updated display applications and monitoring infrastructure for the Liquid Galaxy Display Platform. These upgrades center on the ROS framework and allow a great number of functionality extensions and enhancements for the end user, as well as improvements to the stability and security of the core systems. It is intended that the 50+ systems that we currently maintain and support on behalf of our enterprise clients will be upgraded to this new platform.

ROS Overview

ROS is short for “Robot Operating System”. Just as it sounds, it is a framework used for controlling robots, and handles various environmental ‘inputs’ and ‘outputs’ well. End Point chose this framework in conjunction with related ongoing development projects on behalf of our enterprise clients. This system allows complex interactions from a touchscreen, camera, SpaceNav, or other device to be interpreted conditionally and then invoke other outputs such as displaying Google Earth, Street View, or other content on a given screen, speaker, or other output device. For more details, see: http://www.ros.org

Liquid Galaxy Enhancements

This new platform brings a number of improvements to the back-end systems and viewing customer experience.

Improved Street View Panospheres

The new Street View viewer draws Street View tiles inside a WebGL sphere. This is a dramatic performance and visual enhancement over the older method, and can now support spherical projection, hardware acceleration, and seamless panning. For a user, this means tilting the view vertically as well as horizontally, zooming in and out, and improved frame rates.

Improved Panoramic Video

As with the panoramic Street View application, this new platform improves the panoramic video playback as well. YouTube and Google have announced major initiatives to start actively supporting 360° panoramic video, including the financial backing of some high profile projects as example use cases. The Liquid Galaxy, with its panoramic screen layout already in place, is ideally suited for this new media format.

Improved Touchscreen

The touchscreen incorporates a templated layout for easier modification and customization. The scene view selector is now consolidated to a single interface and no longer requires sub-pages or redundant touches. The Street View interface, complete with the ‘pegman’ icon, is a photo-realistic map with pinch and zoom just like a tablet interface.

Browser Windows

The Liquid Galaxy can control multiple browser windows that can appear anywhere on the screens, often across multiple screens. These browser windows can show anything that can appear in a desktop web browser: web pages, videos, social media updates, data visualizations, etc.

Content Management System

Beginning in 2014, End Point began to upgrade the content management system for the Liquid Galaxy. With the new ROS platform, we have updated this application to Roscoe (the ROS content experience). Roscoe gives registered users the ability to create complex presentations with specific scenes. Each scene can have a specific global location to guide the Google Earth or Street View, and then invoke overlays that appear across the screens. These overlays can include photos, data graphs, videos, or web pages. Each scene can also include a specific KML data set e.g., population density data, property value data, etc.) that can appear as 3D bar graphs directly in the ‘Earth’ view.

Content Isolation

Isolating the entire presentation layer in ROS makes it easy to develop exhibits without a full-fledged Liquid Galaxy system. The entire ROS stack can be installed and run on an Ubuntu 14.04 computer or within a Docker container. This ROS stack can be used by a developer or designer to build out presentations that will ultimately run on a Liquid Galaxy system.

App Modularization

Each component of a Liquid Galaxy exhibit is a configurable ROS node, allowing us to reuse large swaths of code and distribute the exhibit across any number of machines. This architecture brings two strong advantages: 1) each ROS node does one specific thing, which increases portability and modularity, and 2) each node can be tested automatically, which improves reliability.

Enhanced Platform Stability

By unifying all deployments on a common base, End Point is able to deploy bug fixes, monitoring scripts, and ongoing enhancements much more quickly and safely. This has enhanced the overall stability for all supported and monitored Liquid Galaxy platforms.

Product Roadmap

The items described above are the great things that we can do already with this new platform. Even greater things are coming soon:

LiDAR Point Clouds

End Point has already built early prototypes for the Liquid Galaxy platform that can view LiDAR point clouds. LiDAR is rapidly gaining traction in the architecture, surveyor, and construction industries. With the large viewing area of the Liquid Galaxy, these LiDAR point clouds become much more impactful and useful to the command and control center.

Google Earth and Google Maps Upgrades

End Point continues to work with the latest developments in the Google Earth and Google Maps platforms and is actively working to integrate new features and functionality. These new capabilities will be rolled out to the fleet of Liquid Galaxies as available.

3D WebGL Visualizations

The Liquid Galaxy will be enhanced to view completely virtual 3D environments using WebGL and other common formats. These environments include complex data visualizations, interior space renderings for office planning, and even games.

Next Steps

If you’re considering the Liquid Galaxy platform, contact us to discuss these latest enhancements and how they can improve the communications and presentation tools for your organization.

Non-English Google Earth Layers on the Liquid Galaxy

2015-05-12T00:00:00+00:00

The availability to activate layers within Google Earth is one of the things that makes Earth so powerful. In fact, there are many standard layers that are built into Earth, including weather, roads, place names, etc. There are also some additional layers that have some really interesting information, including one I noticed relatively recently called “Appalachian Mountaintop Removal” which is interesting to me now that I live in Tennessee.

As you can see, however, that while some of these available layers are interesting on a desktop, they’re not necessarily very visually appealing on a Liquid Galaxy. We have identified a standard set of layers to enable and disable within Earth so that things don’t appear too cluttered while running. Some things we’ve disabled by default are the weather and the roads, as well as many levels of place names and boundaries. For example, we have boundaries of countries and water bodies enabled, but don’t want lines drawn for states, provinces, counties, or other areas such as those.

To disable these layers, we modify the GECommonSettings.conf file on the machines that running Earth. This file has everything pretty well spelled out in a readable manner, and it’s fairly easy to determine what layers you’re enabling or disabling.

Here’s an example of some of the entries contained within the GECommonSettings.conf file:

1st%20Level%20Admin%20Names%20%28States_Provinces%29=false
2nd%20Level%20Admin%20Regions%20%28Counties%29=false
Islands=false
http%3A__mw1.google.com_mw-earth-vectordb_geographic_features_en.kml\Geographic%20Features=false
Water%20Bodies=true
Places%20=false
Panoramio=false
360%20Cities=false
Photorealistic%20=true
Trees=true
Populated%20Places=true
Roads=false
Gray%20=false
http%3A__mw1.google.com_mw-weather_base_files_kml_weather_en.kmz\Clouds=true
http%3A__mw1.google.com_mw-weather_base_files_kml_weather_en.kmz\Radar=true
http%3A__mw1.google.com_mw-weather_base_files_kml_weather_en.kmz\Conditions%20and%20Forecasts=true
http%3A__mw1.google.com_mw-weather_base_files_kml_weather_en.kmz\Information=true
http%3A__mw1.google.com_mw-earth-vectordb_gallery_layers_gallery_root_en.kmz\360Cities=false

See, that’s pretty self-explanatory, isn’t it?

Well, it is until you start introducing other languages to the mix. For example, we needed to run Earth in Korean language mode for one of our clients. Once we fired up Earth and specified that the language would be Korean, Earth came up with all of the default layers turned on. All of those layers that we’d disabled in English Earth stayed on and cluttered the displays with so many icons for each and every layer.

It took some trial and error, but I was eventually able to figure out what to do to resolve this. I loaded Google Earth in Korean mode on my Ubuntu VM, made my changes to the selected layers via the Layers selection area within Earth, then quit. When I looked at the GECommonSettings.conf file after quitting Earth, I found a bunch of new line items added to the file. It seems that each of the options had new lines, though I couldn’t exactly decipher which lines controlled which options.

Here’s an example of some of the new entries that are now contained within my GECommonSettings.conf file:

http%3A__kh.google.com%3A80_\%UAD6D%UACBD=false
http%3A__kh.google.com%3A80_\%UAD6D%UAC00%UBA85=false
http%3A__kh.google.com%3A80_\%UD574%UC548%UC120=false
http%3A__kh.google.com%3A80_\1%UCC28%20%UD589%UC815%20%UACBD%UACC4%UC120%28%UC8FC_%UB3C4%29=false
http%3A__kh.google.com%3A80_\2%UCC28%20%UD589%UC815%UB2E8%UC704%20%UC9C0%UC5ED%28%UAD70%29=false
http%3A__kh.google.com%3A80_\%UC778%UAD6C%UBC00%UC9D1%UC9C0%UC5ED=true
http%3A__kh.google.com%3A80_\%UC12C=false

Now, I’ll be honest and say that I don’t have clue exactly what %UAD6D%UACBD and 1%UCC28%20%UD589%UC815%20%UACBD%UACC4%UC120%28%UC8FC_%UB3C4%29 mean, but I really don’t have to know. All I know is that they got disabled when I disabled the undesired layers within Earth. I then copied these lines to the configuration on my Liquid Galaxy, and the next time I fired it up in Korean, the layers were no longer cluttering up the displays.

I was able to use this exact same method to determine which layers to enable or disable for one of our Spanish-language clients, as well.

Liquid Galaxy for Google.org at SXSW

2015-03-24T00:00:00+00:00

End Point enjoyed an opportunity to work with Google.org, who bought a Liquid Galaxy to show their great efforts, at last week’s SXSW conference in Austin. Google.org has a number of projects worldwide, all focused on how tech can bring about unique and inventive solutions for good. To showcase some of those projects, Google asked us to develop presentations for the Liquid Galaxy where people could fly to a given location, read a brief synopsis of the grantee organizations, and view presentations which included virtual flight animations, map overlays, and videos of the various projects.

Some of the projects included are as follows:

Charity:Water—The charity: water presentation included scenes featuring multi screen video of Scott Harrison (Founder/CEO) and Robert Lee (Director of Special Programs), and an animated virtual tour of charity: water well sites in Ethiopia.
World Wildlife Fund—The World Wildlife Fund presentation featured a virtual tour of the Bouba N’Djida National Park, Cameroon putting the viewer into the perspective of a drone patrolling the park for poachers. Additional scenes in the presentation revealed pathways of transport for illegal ivory from the park through intermediate stops in Nigeria and Hong Kong before reaching China.
Samasource—The Samasource presentation showed slums where workers start and the technology centers they are able to migrate to while serving a global network of technology clients.

But the work didn’t stop there! Google.org was also sharing the space with the XPrize opening gala on Monday night. For this event, we drew up a simple game where attendees could participate in various events around the room, receive coded answers at each station, and then enter their code into the Liquid Galaxy touchscreen. If successful, the 7-screen display whisked them to the Space Port in the Mojave, then into orbit. If the wrong code was entered, the participant got splashed into the Pacific Ocean. It was great fun!

The SXSW engagement is the latest in an ongoing campaign to bring attention to global challenges and how Google.org is helping solve those challenges. End Point enjoys a close working relationship with Google and Google.org. We relish the opportunity to bring immersive and inviting displays that convey a wealth of information to viewers in such an entertaining and engrossing manner.

This event ran for 2 days at the Trinity Hall venue just 1 block from the main SXSW convention center in downtown Austin, Texas.

Kamelopard version 0.0.15 released

2014-05-22T00:00:00+00:00

The Camelopardalis constellation, as shown in Urania’s Mirror

I’ve just pushed version 0.0.15 of Kamelopard to RubyGems. As described in several previous blog posts, Kamelopard is a Ruby gem designed to create KML documents quickly and easily. We use it to create content for our Liquid Galaxy customers. This release doesn’t include any major new features, rather it provides a number of small but very helpful modifications that taken together make life much easier.

New Spline Types

Perhaps the most useful of these new features relate to spline functions, introduced in Kamelopard version 0.0.12. The original spline function interface described here accepts a series of equi-dimensional vectors as control points, and returns vectors as results, but there’s no indication of what each dimension in the vector means. This is convenient in that you can use splines to make nice paths through any number of dimensions and use them however you’d like, but in practice we most commonly want to make tours which fly through sets of either KML Points or AbstractViews (Points include just a latitude, longitude, and altitude, but AbstractViews include a direction vector, so they describe cameras and their positions). Two new classes, called PointSplineFunction and ViewSplineFunction, accept Points and AbstractViews respectively as their control points, and return those types when evaluated, freeing the user from having to map each control point’s coordinates to a simple vector.

Often when creating tours, we’ll use Google Earth to find a set of views we like, save them to a KML file, and then write a script to make a tour out of those placemarks. With these new classes, that becomes much easier. Here’s an example which ingests a KML file containing several placemarks, and creates a simple spline-based tour through them, in the order in which they appear in the KML file.

sp = Kamelopard::Functions::ViewSpline.new
each_placemark(XML::Document.file('waypoints.kml')) do |p, v|
  sp.add_control_point(w, 10)
end

(1..30).each do |i|
  fly_to sp.run_function(i.to_f/30.0), :duration => 0.8, :mode => :smooth
end

This uses the each_placemark function Kamelopard has had for quite a while to iterate through the file’s placemarks and create control points, and then calculates the value of the spline along 30 points to create the flight path. This is such a common idiom when making tours that this Kamelopard version makes it even easier with a new fly_placemarks helper function. Using the new function, the code above becomes simply this:

fly_placemarks XML::Document.file('waypoints.kml')

More Flexible Geocoding

Kamelopard tries to make it easy to use geocoding services, which allow users to convert things like street addresses into latitudes and longitudes. This has its difficulties, as service providers regularly change formats or requirements, or quit the business altogether. Kamelopard has supported various geocoders in its time; this version finally adds support for Google’s service. I’d left it out in previous versions because of an incorrect understanding of Google’s licensing terms. It became important now because for the data we had from one particular client, Google’s geocoding was significantly more accurate than the MapQuest geocoder I had been using previously. For different data sets, of course, some other service might get the most accurate results, but geocoding accuracy is a big concern for the work we do. No client wants to ask their shiny new Liquid Galaxy to zoom in on the corporate headquarters and see instead a seven screen panorama of the neighboring grocery store.

For geocoding projects of your own, there are a few considerations to keep in mind. First, geocoding services often impose usage limits. We’ll sometimes find when geocoding a list of addresses that the service rejects every third or fourth query simply because we’re querying faster than it wants to allow. They generally limit the number of queries allowed in one day, too, so debug your scripts using a small list of addresses before trying out a whole bunch at once. Having a project delayed simply because the geocoding service has stopped talking to you for the day is frustrating. Finally, it’s often a good idea to geocode in one step, save the results somewhere, and make the tour in a second step using the saved results. This frees you from dependence on access to the service, and allows manual tweaking of the geocoded results. Note, however, that some services’ licenses forbid saving the results anywhere.

Whichever service you end up using, Kamelopard code for geocoding generally looks like this:

g = GoogleGeocoder.new('my-api-key')
results = {}

Addresses.each do |t|
  results[t] = g.lookup(t)
end

Most services require an API key used for authorization, and return a large JSON structure which includes latitude and longitude, a status code, result quality, and any other useful information the service provider thinks you should have.

Other Updates

It seems it has always been hard for newcomers to get used to Kamelopard. This version includes a number of updates to the documentation, which will hopefully make it easier for them. It also includes new helper functions for writing out all KML documents in memory at once, and creating KMZ files automatically where desired.

Please give the new version a try. We’d love to hear how it’s being used.

Liquid Galaxy at the Economist World Ocean Summit

2014-03-03T00:00:00+00:00

The Liquid Galaxy with image capture equipment

End Point had the distinct privilege of providing a Liquid Galaxy to the Economist World Ocean Summit held in Half Moon Bay, California last week. Originally conceived as a Google Earth and Google Street View platform, the Liquid Galaxy is rapidly becoming a premiere display for ocean content as well. Google is partnering with NGOs and corporations that are actively working toward ocean sustainability. Together, these organizations capture and categorize a great deal of ocean content, with most of that content publicly available via Street View. Some of this equipment was on display next to the Liquid Galaxy: a Trekker camera for remote areas and an underwater camera provided by the Catlin Seaview Survey for capturing hi-definition panoramas underwater.

This deployment used a custom configuration with six large HDTVs arrayed in a curved 3x2 panorama. The Liquid Galaxy is able to show this content as a single large surface with geometrically-adjusted angles. In short, it’s like a bay window on a submarine. Viewers are able to navigate to different locations through a touchscreen interface, and then rotate and zoom in on detailed panoramic photos with a 6-axis controller.

End Point enjoys a close working relationship with Google, and is happy to provide a Liquid Galaxy for such events. Our engineer Neil assembled a custom frame to hold the 3x2 screen configuration (deployed for the first time here), tested all devices, adjusted viewing angles, and then deployed and supported the full rig onsite at the Ritz-Carlton Hotel in Half Moon Bay.

Newest European Liquid Galaxy installation: Google Hamburg shop-in-shop

2013-10-02T00:00:00+00:00

In September 2013, Google opened a store-in-store within the large electronics retailer Saturn in Hamburg. Dominating the visuals of the store is a large Liquid Galaxy on the back wall.

We partnered with system integrator Pixel Projects this time, and instead of our usual 7 screen display, worked the Liquid Galaxy into an unique 3x3 video wall array. The Liquid Galaxy shows Google Earth and will be showing Google Street View starting later this month, further highlighting the rich set of services offered by Google. It is also integrated with traditional video wall software configured by Pixel Projects such that it it can be switched to displaying Google services such as YouTube, Google Drive, Hangouts, and more. As always, the Liquid Galaxy is a huge customer draw. Customers who come through the store can explore any point on the globe while they browse the Google products.

End Point worked under the direction of the retail experience agency, Make Retail, to design a fully integrated experience. Once the unique configuration of the Liquid Galaxy was set, we sent along one of our top engineers, Matt Vollrath, to oversee the final hardware and software integration and installations, together with our local deployment partners Pixel.

As a new step for Google in Europe, the Liquid Galaxy creates a fantastic experience for consumers and enhances the impact of the retail store.

Kamelopard update—Panoramic camera simulation, and splines have returned

2013-07-16T00:00:00+00:00

A few days ago I pushed Kamelopard version 0.0.12 to RubyGems. This version includes a couple big items. The first of these is a new implementation of the spline code that was removed a while ago. As I mentioned in a previous blog post, this original implementation was built in anticipation of an API that never materialized. The new version is built on the same API discussed in the previous post I mentioned, modified to support multidimensional functions. More information about these splines is available on the wiki for Liquid Galaxy.

The other big new feature is the ability to simulate multiple-camera panoramic images, which we’re calling “multicam”. It has its own wiki page as well, but I wanted to describe it in greater detail, because there’s a fair bit of 3D geometry involved that seemed blog-worthy. First, though, it’s important to understand the goal. In a Liquid Galaxy, each instance of Google Earth displays the view from one virtual “camera”. One display’s camera points exactly where you tell it to point; the others point to one side or the other, based on a few settings in a Google Earth configuration file. When placed side-by-side in the right order, these displays form a single panoramic image. Google Earth itself figures out where these displays’ cameras should point, but for some applications, we wanted to be able to calculate those display angles and position the cameras on our own. For instance, it would sometimes be nice to pre-record a particular tour and play it back on a Liquid Galaxy as a simple video. For a seven-screen galaxy, we’ll need seven different video files, each with the same movements to and from the same geographic locations, but each with a slightly different camera orientation.

Camera orientation is controlled by KML AbstractView elements, of which there are two varieties: Camera, and LookAt. The former tells the camera its position and orientation exactly; the latter describes it in terms of another point. For now, multicam only supports Camera objects, because LookAt is somewhat more complicated.

A Camera object gives the camera’s latitude, longitude, and altitude, and three angles called heading, tilt, and roll. The camera initially points straight down, positioned so that north is up. When orienting the camera, Google Earth first rotates around the Z axis, which extends through the lens of the camera, by the heading amount. Then it rotates around the X axis, which extends through the sides of the camera, by the amount given by the tilt angle. Finally, it rotates around the Z axis again, by the roll amount. The Y axis always points in whatever direction the camera thinks is “up”.

With that background, we’re ready to tackle the problem at hand. We’ll consider our cameras as shown in the drawing. Camera 0 is the master view, positively numbered cameras go off to the master camera’s right, and negatively numbered cameras to the left. Each camera has the same view angle. We want an API that will accept the master camera’s orientation, the number of the camera we’re interested in, and the view angle of each camera, and return the orientation for the camera number we gave. We’ll consider each camera’s orientation in terms of two vectors; the first will tell us what direction the camera is pointing, and the second, the up direction. I’ll call these the “camera” vector and the “up” vector. The first step will be to find these two vectors for the camera we want, and the second will be to translate that back into a Camera object.

Getting the position of these vectors for any given camera is a simple application of rotation matrices. In the Kamelopard code, there’s a function defined for rotating around each of the three axes. Here’s the example for the X axis; the others are all similar:

def self.rot_x(a)
   # Convert the angle to radians
   a = a * Math::PI / 180.0
   return Matrix[[1, 0, 0], [0, Math.cos(a), -1 * Math.sin(a)], [0, Math.sin(a), Math.cos(a)]]
end

So we start with a camera pointed at the ground, and we multiply it by a rotation matrix, so that it points in the direction our camera would, before the heading, tilt, and roll rotations are applied. When we perform those rotations, we’ll end up with a vector pointed in the right direction for our camera. This code does just that.

# The camera vector is [0,0,1] rotated around the Y axis the amount
# of the camera angle
camera = rot_y(cam_angle) * Vector[0,0,1]

# The up vector is the same for all cameras
up = Vector[0,1,0]
matrix = rot_z(heading) * rot_x(tilt) * rot_z(roll)
(h, t, r) = vector_to_camera(matrix * camera, matrix * up)

The last line of this snippet calculates the camera and up vectors, and passes them to the vector_to_camera() function, which takes care of the second step in the process: converting these vectors back into a usable heading, tilt, and roll. Two operations fundamental to linear algebra will become important here. Both take two vectors as input. The dot product returns product of the two vectors’ magnitudes and the cosine of the angle between them. We’ll use it here to find the angle between two vectors. The cross product returns a normal vector, or a vector which is perpendicular to the two input vectors.

First we want to calculate the heading, which we can find by calculating the angle between two planes. The first plane is defined by the camera vector and the Z axis, and the second is the plane of the Y and Z axes. To find the angle between two planes, we find the angle between their normal vectors. The normal vector of the YZ plane is simply the X axis; the normal vector for hte first plane is the cross product of the camera vector and the Z axis. The dot product lets us find the angle between these two vectors, which is our heading.

Tilt is simply the angle between the camera vector and the original Z axis, but roll is a bit harder. To find it, we transform the original Y axis—the original “up” vector—using the heading and tilt calculated previously. We then find the angle between it and the current “up” vector, again using the dot product.

These calculations underlie a simple API, which simply takes a view, for the original camera, the number of the camera we’re interested in getting, and the camera angle or total number of cameras. Like this, for instance:

view_hash = {:latitude => otp[:latitude], :longitude => lo,
    :altitudeMode => otp[:altitudeMode], :altitude => otp[:altitude],
    :roll => otp[:roll], :timestamp => Kamelopard::TimeStamp.new('1921-07-29'),
    :heading => otp[:heading], :tilt => otp[:tilt]}
v = Kamelopard::Multicam.get_camera_view(make_view_from(view_hash), camera, nil, CamCount)

Estimating overlayfs File Space Usage on Ubuntu 12.04 LiveCD

2013-04-24T00:00:00+00:00

End Point’s Liquid Galaxy platform is a cluster of computers distributing the rendering load of Google Earth and other visualization applications. Each of these “display nodes” boots the same disk image distributed over the local network. Our disk image is based on the Ubuntu 12.04 LiveCD, and uses the same overlayfs to combine a read-only ISO with a writeable ramdisk. This Union mount uses Copy-on-write to copy files from the read-only “lower” filesystem to the virtual “upper” filesystem whenever those files or directories are opened for writing.

We often allocate 4GB of system memory to the ramdisk containing the “upper” filesystem. This allows 4GB of changed files on the / filesystem, most of which are often Google Earth cache files. But sometimes the ramdisk fills up with other changes and it’s difficult to track down which files have changed unexpectedly.

The df command properly displays total usage for the overlayfs “upper” filesystem mounted at /.

$ df -h
Filesystem              Size  Used Avail Use% Mounted on
/cow                    3.9G  2.2G  1.8G  55% /
/dev/loop0              833M  833M     0 100% /cdrom
/dev/loop1              808M  808M     0 100% /rofs

But how can we identify which files are consuming that space? Because the root device has been pivoted by the casper scripts at boot, the /cow device is not readily available. We often use the du tool to estimate disk usage, but in this case it cannot tell the difference between files in the “upper” ramdisk and the “lower” read-only filesystem. To find the files filling our /cow device, we need a way to enumerate only the files in the “upper” filesystem, and then estimate only their disk usage.

The mount command shows the / filesystem is type “overlayfs”.

$ mount
/cow on / type overlayfs (rw)
/dev/loop0 on /cdrom type iso9660 (ro,noatime)
/dev/loop1 on /rofs type squashfs (ro,noatime)

The find command does indicate that most directories exist in the filesystem of type “overlayfs”, and most unmodified files are on the “lower” filesystem, in this case “squashfs”.

$ sudo find / -printf '%F\t%D\t%p\n' | head -n 7 ### fstype, st_dev, filename
overlayfs 17 /
overlayfs 17 /bin
squashfs 1793 /bin/bash
squashfs 1793 /bin/bunzip2
squashfs 1793 /bin/bzcat
squashfs 1793 /bin/bzcmp
squashfs 1793 /bin/bzdiff

However, the modified files are reported to be on an “unknown” filesystem on a device 16. These are the files that have been copied to the “upper” filesystem upon writing.

$ find /home/lg/ -printf '%F\t%D\t%p\n' | head -n 33
overlayfs 17 /home/lg/
squashfs 1793 /home/lg/.Xresources
unknown  16 /home/lg/.bash_history
squashfs 1793 /home/lg/.bash_logout
squashfs 1793 /home/lg/.bashrc
overlayfs 17 /home/lg/.config
overlayfs 17 /home/lg/.config/Google
unknown  16 /home/lg/.config/Google/GoogleEarthPlus.conf
unknown  16 /home/lg/.config/Google/GECommonSettings.conf

I couldn’t quickly discern how find is identifying the filesystem type, but it can use the -fstype test to reliably identify files that have been modified and copied. (Unfortunately find does not have a test for device number so if you have more than one overlayfs filesystem this solution may not work for you.)

Now that we have a reliable list of which files have been written to and copied, we can see which are consuming the most disk space by piping that list to du. We’ll pass it a null-terminated list of files to accommodate any special characters, then we’ll sort the output to identify the largest disk space hogs.

$ sudo find / -fstype unknown -print0 | du --files0-from=- --total | sort -nr | head -n 4
2214228 total
38600 /var/cache/apt/pkgcache.bin
38576 /var/cache/apt/srcpkgcache.bin
17060 /var/log/daemon.log

We included a total in this output, and notice that total is exactly the 2.2GB indicated by the df output above, so I believe this is measuring what we intend.

Of course five hundred 2MB Google Earth cache files consume more space than a single 38MB apt cache file, so we’d like to list the directories whose files are consuming the most ramdisk space. Unfortunately giving find and du depth arguments won’t work: the “unknown” filesystem doesn’t have any directories that we can see. We’ll have to parse the output, and that’s left as an exercise for the reader for now.

I just realized I could’ve simply looked for files modified after boot-time and gotten very similar results, but that’s not nearly as fun. There may be a way to mount only the “upper” filesystem, but I was disappointed by the lack of documentation around overlayfs, which will likely be included in the mainline 3.10 Linux kernel.

Leap Motion Controller + Liquid Galaxy

2013-04-23T00:00:00+00:00

We’re constantly trying out new things with our Liquid Galaxy at End Point: new content types, new remote management scripts, new hardware. The good people at Leap Motion sent over one of their hand motion controllers and we couldn’t wait to get it unpacked and driving the Liquid Galaxy that sits in our office.

With access to developer tools, we were able to configure the Leap Motion and update the device firmware. Then, after a quick installation of the latest Google Earth build v 7.1.1.1550 that includes Leap Motion controller support, we were ready to test out the new device on our 7-screen Liquid Galaxy.

Watch the video and see for yourself—we think the combination is fantastic! That superhero feeling of flying around the world with a Liquid Galaxy is only enhanced that much more by now commanding the movement of the planet with subtle flexing of your fingers. (That’s Kiel in the video—personally, I think he looks like Magneto without the helmet.)

End Point continues to push the boundaries on what the Liquid Galaxy can do. We want to experiment some more and see what else might be possible with the Leap Motion controller for Google Street View, panoramic photos, videos, and maybe even games. If you’ve got an idea, or if you have a cool place where this might be deployed, please contact us!

Creating Smooth Flight Paths in Google Earth with Kamelopard and Math

2013-04-15T00:00:00+00:00

The major motivation for writing Kamelopard was that writing XML by hand is a pain in the neck. But there were other motivations as well. In particular we found some limitations of Google Earth’s default FlyTo behavior, and wanted to be able to address them flexibly. Version 0.0.11, just released, does exactly that.

Bezier curve, similar to a cspline

Our clients often want Google Earth’s camera to fly smoothly from one place to another, through a precisely defined set of waypoints. Earth does this with a FlyTo, one of Google’s extensions to KML. It tells Earth to move from its current camera position to a new one, following a nice path Google Earth calculates automatically. Most of the time this works just fine, but on occasion, Earth’s automatic path will run into buildings or mountains, or do other unexpected and strange things. There are a few KML tricks we’ve learned to handle those cases, but it would often be nice to have tighter control. Unfortunately getting that level of control means calculating the flight path ourselves. We’ve developed the smarts to do that, a little bit at a time.

The first version involved Catmull-Rom splines, a variant of a cubic spline (or “cspline”) that gives nice results and is fairly simple to calculate. The idea of a spline is to build a curve that passes smoothly through a set of “control points”. To achieve this, in essence we project those points into a vector space defined by a special set of cubic basis functions. In other words, we turn our control points into a matrix and multiply it by another matrix to end up with a function describing our path. The general cspline requires “tangents” in addition to the control points to define behavior at the ends of the curve; the Catmull-Rom variant derives the tangents from the control points, which limits flexibility but works well for our purposes. So if we want a path between several points on a globe, we use those points as the control points in the spline, and Kamelopard would make a nice path between them automatically. Better still, csplines can support any number of dimensions, so we can include factors such as altitude or heading in the generated curve. As it turned out, though, we didn’t end up using this spline very much. It was built on top of some other code that later proved insufficient for what we wanted, and that was removed.

Parabola defined by three points

The next iteration, recently committed, allows Kamelopard scripts to define mathematical functions in terms of the same control points, and asks Kamelopard to use those functions to build smooth paths. Right now Kamelopard supports cubic, quadratic, and linear functions; others would of course be possible given sufficient reason to develop them, but the existing functions seem to work very well. The matrix math to interpolate these types of functions based on control points was straightforward, and they can define a wide variety of paths.

One limitation of the new code compared to the old: the spline functions would take any number of control points, whereas the mathematical function versions are more limited. Three points in a particular order, for instance, uniquely describe a quadratic curve. As a result, our quadratic function implementation only supports three control points. I plan to reintroduce splines in the future for situations where this limitation causes problems. These functions are especially flexible, though, in that they can determine not only the camera’s latitude and longitude, but also its heading, altitude, and various other things including the duration of each FlyTo. Our cspline implementation was intended to handle those dimensions as well, but never got that far along.

So how does all this work? Here is a simple example, showing an interpolated path from a point about 10 km above one of the cows near my house, to another point a bit to the north. First, the KML itself is available for download; in Google Earth, it looks like this (click on the image to get the larger version):

Here’s the code:

require 'rubygems'
require 'kamelopard'

include Kamelopard
include Kamelopard::Functions

a = make_function_path(10,
    :latitude => Line.interpolate(38.8, 40.3),
    :longitude => Cubic.interpolate(-112.4, -111.9, -0.5, -113, 0.5, -110),
    :altitude => Line.interpolate(10000, 2000),
    :heading => Line.interpolate(0, 90),
    :tilt => Line.interpolate(40.0, 90),
    :altitudeMode => :absolute,
    :show_placemarks => 1,
    :duration => Quadratic.interpolate(2.0, 4.0, 0.0, 1.0),
)

name_document 'Functions test'
name_folder 'Placemarks'
name_tour 'Function test'

write_kml_to 'doc.kml'

The make_function_path call does most of the work here. We’ve given it functions to interpolate the latitude, longitude, and other characteristics of the flight path we want, along with a few other options described in the gem documentation. We also tell it how many points to create in the path, in this case 10. The root of the flying is still Google Earth’s FlyTo algorithm, but we set to smooth mode, to keep Earth doing more precisely what we want it to, and we create waypoints on the flight path frequently enough that we have tight control over where Earth actually flies.

Creating the functions themselves is relatively easy, but you need to remember the order of the arguments, which in this case at least can be confusing. I’ll probably change it in a future version, once I come up with something better. This code defines the latitude function in terms of the beginning and ending latitude, and that’s all since we only need two points to define a line. The quadratic and cubic functions take three and four points, respectively. Although not demonstrated here, make_function_paths can also take a code block for more complex behaviors at each point.

In the end this generates a Google Earth Tour, which flies from the start point to the end point very smoothly. This code has demonstrated that it works well for flights over large areas; my next goal is to use it to navigate between 3D buildings on a precisely defined path. That will be for another article, though.

Kamelopard Updates

2013-02-15T00:00:00+00:00

I’ve just pushed Kamelopard v0.0.10 to RubyGems. With the last couple of releases, Kamelopard has gained a couple of useful features I felt deserved some additional attention.

Support for viewsyncrelay actions

Many of our Liquid Galaxy tours require more than just Google Earth. For instance, it’s not uncommon to want audio or video media to play at a certain point in the tour. We may want our Liquid Galaxy enabled panoramic image viewer to start up and display an image, or perhaps we need to signal some other external process. Unfortunately Google Earth tours don’t support configuration to run these actions directly upon reaching a certain point, but there are alternatives. Google Earth synchronizes nodes in a Liquid Galaxy with what are called ViewSync packets, which tell all the slave nodes exactly where a master node’s camera is positioned, in terms of latitude, longitude, tilt, etc. We can watch this traffic to determine the master node’s progress through a tour and trigger actions at defined locations, and we use an application called viewsyncrelay (available here) to do exactly that. We configure viewsyncrelay to run certain actions when the ViewSync traffic matches a set of constraints. For instance, an action might require ViewSync packets to fall within a certain latitude, longitude, altitude, and heading, and a particular previous action might have to run first in order to activate this one.

This works well enough for most purposes, but the viewsyncrelay configuration files can become complicated, and difficult to debug. Here’s where Kamelopard comes in. Now, the same code that creates a tour can create viewsyncrelay actions. Here’s an example. The code is still a bit unwieldy; it will get simpler and more elegant in future versions, after we’ve seen the best ways people come up with to use the feature.

require 'rubygems'
require 'kamelopard'

name_folder 'test'
name_document 'test'
pt = point 100, 100
pl = placemark 'test placemark', :geometry => pt
get_folder << pl

Kamelopard::VSRAction.new('action name',
    :action => 'mplayer play_this_video.webm',
    :constraints => {
        :latitude => to_constraint(band(100, 0.1).collect{ |l| lat_check(l) }),
        :longitude => to_constraint(band(100, 0.1).collect{ |l| long_check(l) }),
    }
)

write_kml_to 'doc.kml'
write_actions_to 'actions.yml'

In addition to the VSRAction object, these changes introduce a few new functions, including those shown here: band(a, b) returns a +/- b, in an array; lat_check() and long_check() ensure each value in the array is a valid latitude or longitude; and to_constraint() turns this validated array into a string suitable for use in a viewsyncrelay constraint. As I mentioned, this may prove awkward, but it’s a first step. This code creates a file called actions.yml, ready for use in viewsyncrelay:

---
actions:
- name: action name
  input: ALL
  action: mplayer play_this_video.webm
  repeat: DEFAULT
  constraints:
    :latitude: ! '[-80.1, -79.9]'
    :longitude: ! '[99.9, 100.1]'

Master/slave modes

Liquid Galaxy tours often consist of two different KML files: one to run on the master, and another to run on each of the slaves. The slave versions generally don’t include all of the screen overlay and network link objects used by the master, in particular, but there are plenty of objects that you might not want on the slaves. In the past we’ve had to edit the KML files manually to remove unnecessary objects, which is of course error prone, sometimes difficult, and something we have to redo every time we run our Kamelopard script and create a new tour version. Now, Kamelopard supports tagging objects as “master-only”, and creating KML documents in either normal or master-only mode, to make this process entirely automatic. Here’s an example:

require 'rubygems'
require 'kamelopard'

name_folder 'test'
name_document 'test'
pt = point 100, 100
pl = placemark 'test placemark', :geometry => pt
get_folder << pl

get_folder.master_only = true
write_kml_to 'slave.kml'
get_document.master_mode = true
write_kml_to 'master.kml'

This results in two files, called master.kml and slave.kml. Only master.kml contains the Folder object:

<!--?xml version="1.0" encoding="UTF-8"?-->
<kml xmlns="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2">
  <document id="Document_1">
    <name>test</name>
    <visibility>1</visibility>
    <open>0</open>
    <folder id="Folder_2">
      <name>test</name>
      <visibility>1</visibility>
      <open>0</open>
      <placemark id="Placemark_4">
        <name>test placemark</name>
        <visibility>1</visibility>
        <open>0</open>
        <point id="Point_3">
          <coordinates>100.0, 100.0, 0</coordinates>
          <extrude>0</extrude>
          <altitudemode>clampToGround</altitudemode>
        </point>
      </placemark>
    </folder>
  </document>
</kml>

The slave is essentially empty, because we didn’t tell Kamelopard about any objects that weren’t master-only:

<!--?xml version="1.0" encoding="UTF-8"?-->
<kml xmlns="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2">
  <document id="Document_1">
    <name>test</name>
    <visibility>1</visibility>
    <open>0</open>
  </document>
</kml>

New repository

Since Kamelopard is developed primarily for our use creating Liquid Galaxy tours, it has been moved from github to a portion of the GitHub Liquid Galaxy project. Clone the repository at https://github.com/liquidgalaxy/liquid-galaxy to get your own copy, or install the gem from rubygems to play around.

Josh Tolley: About Google Earth Tours

2012-06-14T00:00:00+00:00

Josh Tolley spoke on the building of tours for viewing within Google Earth and the Liquid Galaxy. It seems that everybody has data and wants a way to view it, such as businesses who want to visually represent where their customers are based, or even documenting where lightning strikes within a certain region. Google Earth is a fantastic tool for the viewing of this data.

Josh talked about what is required to display geographical data in Google Earth. The data needs to go through the process of geocoding, which is the conversion to latitudinal and longitudinal format. As this is a tedious process, it is highly recommended to use a script and loop through the conversion. Google Earth is based upon KML documents, which are XML documents that contain geographical data. He explained some of the different ways to create the KML documents, including the use of Google Earth itself, writing by hand, or using a tool such as kamelopard or PyKML to create the data.

He demonstrated how a KML file can contain data such as placemarks, polygons, time lapses, overlays, and animations, and he showed his own farm with an overlay placed in the wheat field. Now the zombies know where to find wheat. Josh talked about the uses of Google Earth tours, including the display of ocean currents, tsunami shock waves, wind patterns, and even historical events with a time lapse.

Kamelopard is a Ruby-based KML writer that Josh created. It uses Ruby code to identify a point, fly to it, stay there for a bit, then fly to the next place. It loops through all of the coordinates given and creates a tour. An example tour that Josh has written is one for Google’s Ocean Conservation Group, which displays fishery data around the world.

KML can handle large datasets, and has multiple ways of being displayed. It can have regions and ground overlays, and combining the two can show increasingly detailed images and sets of placemarks as the level of zoom increases. DataAppeal can create maps with various models in them, scaling and coloring them based upon users’ data.

Giraffes and Liquid Galaxy

2011-08-25T00:00:00+00:00

We build lots and lots of Google Earth tours, typically for use with a Liquid Galaxy. These tours tell Google Earth to start at one point and fly to another, displaying various images along the way. They’re written in an XML-based language called Keyhole Markup Language, or KML. Various KML elements describe points on the globe, 3D objects, tracks through space, or other items, and a series of Google-specific KML extensions can define an automated tour in which Google Earth flies through these objects.

Now for a bit of dogma: writing large volumes of XML by hand is a drag. Writing KML is no exception. So when I started building KML tours, I was keen to build or find tools to make it easier. For my first KML project, making a tour through each End Point employee’s home city, I built a Perl script to convert a file of employee data to KML. This worked well enough, but I soon learned typing out all the KML was just half the pain. The other half was adjusting camera paths, camera angles, timing, and all sorts of other little things. Unfortunately all these adjustments had to be done by trial and error, and all by hand. Getting Google Earth’s camera to circle a particular point, for instance, takes about three screens worth of KML code. If a point’s coordinates were off or a tour’s timing wasn’t quite right, I had to find the right spot in a vast field of KML, tweak a number, and try it all again.

Enter Kamelopard. Named, as dictated by long-standing End Point tradition, after a strange animal, Kamelopard is a Ruby gem designed to make all this easier (“Camelopard” is the ancient English word for “giraffe” and several mythical and heraldic giraffe-like creatures; the various modern giraffe sub-species are grouped under the name Giraffa camelopardalis). Right now it’s not much more than a set of classes which mirror the basic KML objects—or most of them, anyway—but already it has proven itself very useful. For instance, for one project we’re working on, a Ruby script of about 150 lines uses Kamelopard to digest a set of data files and produce a 12,000 line KML file. Fortunately, Kamelopard is sufficiently flexible that I can finish adjusting all the timing and camera angles and other details in the Ruby code, without having to dig through the KML output itself; we can regenerate the KML with whatever tweaks we need, as often as we need it.

As a very simple example, here’s a Kamelopard script to turn a CSV file into KML. The CSV contains the name, description, latitude, and longitude of a bunch of placemarks (e.g. “Mount Everest”,“The world’s tallest mountain”,“27d58m37.15s N”,“86d55m15.93s E”), and the script turns them into KML, including a Google Earth tour that will fly past each in turn. The KML result amounts to about 45 lines per placemark, so the Ruby version is much more concise and much simpler to modify.

require 'rubygems'
require 'kamelopard'
require 'csv'

CSV.foreach('placemarks.csv') do |a|
    pl = Placemark.new a[0], point(a[3], a[2])
    pl.description = a[1]

    mod_popup_for pl, 1
    fly_to pl, 5
    pause 3
    mod_popup_for pl, 0
end

puts get_kml

Along with its library of classes, Kamelopard does have a (fairly unorganized, ad hoc) set of helper functions which I hope one day will evolve into a full-fledged domain-specific language. While they’re currently loosely organized and none too intelligent, there are a few jewels worth noting. For instance, my multi-page KML to orbit a point takes one line of Kamelopard. Conversion from one latitude / longitude notation to another happens automatically (manually converting 24°10’44.3994” N, 55°44’25.7274” E to the decimal notation KML requires becomes a dreary task when performed manually for ten or twenty different points). Finally, Kamelopard includes a helper function for Google’s Geocoding API, so users can translate addresses and location names to latitude and longitude.

Kamelopard’s future development will most likely follow whatever lines our clients, and any contributors that care to help out, most wish to pursue, but I suspect it will include increased automation of tour timing, so developers don’t need to figure out timings for each step in a tour manually, and more helper functions to create objects, so users don’t have to instantiate classes directly, and can get more done in a line of code.

I imagine the audience is fairly small, but I’d welcome any feedback, suggestions, patches, and interest.

Google Earth KML Tour Development Challenges on Liquid Galaxy

2011-02-24T00:00:00+00:00

Because Liquid Galaxy runs Google Earth, it can easily visualize an organization’s GIS data. End Point also develops tours within Google Earth to better present this data. A Liquid Galaxy’s networked multi-system architecture presents unique technical challenges to these tours.

Many Google Earth tours incorporate animations and dynamic updates using the <gx:AnimatedUpdate> element. KML features in the Earth environment can be modified, changed, or created during a tour, including the size, style, and location of placemarks, the addition of ground overlays, geometry, and more.

However, these updates are only executed on the Liquid Galaxy master system running the tour, not sent to its slaves. Liquid Galaxy nodes communicate primarily via ViewSync UDP datagrams. These datagrams contain only the master’s position in space and time. This means we cannot use <gx:AnimatedUpdate> to animate features across all Liquid Galaxy systems, sharply limiting its utility.

But tours can also use chronological elements to display, animate, and hide features. Using <gx:TimeSpan> or <gx:TimeStamp> within an tour stop enables flying to a specific location in space and time. All Google Earth features may be assigned a TimeStamp, and all Liquid Galaxy screens display the same chronological range of features. This works around the single-system limitation on animation, and enables sweeping changes across all screens. The picture below shows a data animation in progress across three screens; the green dots are filling in the area previously occupied by the red dots, while the time sliders in the upper left corners advance.

Taking this technique a step further, we also “wrapped” some very large KML datasets in NetworkLink elements, and wrapped those NetworkLinks in Folder elements with TimeStamp elements as well. This allowed fine control over when to fetch and render the large set, just-in-time to be featured in its own tour. These large loads can cause the Earth client to stutter, so we also stopped the flight motion and displayed a balloon full of text for the audience. A KML example of this wrapper is below.

<Folder>
    <name>Region Link Two</name>
    <TimeStamp><when>2010-09-19T16:00:00Z</when></TimeStamp>
    <NetworkLink>
         <name>Region Link Two</name>
         <Region>
              <LatLonAltBox>
                   <north>41.8</north>
                   <south>41.6</south>
                   <east>-86.1</east>
                   <west>-86.3</west>
              </LatLonAltBox>
              <Lod>
                   <minLodPixels>256</minLodPixels>
                   <maxLodPixels>-1</maxLodPixels>
              </Lod>
         </Region>
         <Link>
              <href>network_view.kml</href>
              <viewRefreshMode>onRegion</viewRefreshMode>
         </Link>
    </NetworkLink>
</Folder>

These techniques, and the Liquid Galaxy platform, combine to coordinate a moving visual experience across the audience’s entire field of view. Animations highlight GIS data and narrate its story, creating an impressive presentation.

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

Custom data & styling

Demo

Exploring Geodatabase Files

Prerequisites

A first look into the contents of the GDB file

The ogr2ogr -sql option

1. Extract property names

2. Extract polygons only

3. Create KML with pins and names

4. Create KML with pins only, no names

5. Extract limited properties

6. Run it all in a Python script

7. Extract all data as JSON from one layer using the Python GDAL library

Conclusion

Additional Resources

CZML-KML Editor Geometry Editing

Announcing the Cesium KML-CZML Editor

The New Earth

ROS Platform Upgrades for Liquid Galaxy

ROS Overview

Liquid Galaxy Enhancements

Improved Street View Panospheres

Improved Panoramic Video

Improved Touchscreen

Browser Windows

Content Management System

Content Isolation

App Modularization

Enhanced Platform Stability

Product Roadmap

LiDAR Point Clouds

Google Earth and Google Maps Upgrades

3D WebGL Visualizations

Next Steps

Non-English Google Earth Layers on the Liquid Galaxy

Liquid Galaxy for Google.org at SXSW

Kamelopard version 0.0.15 released

New Spline Types

More Flexible Geocoding

Other Updates

Liquid Galaxy at the Economist World Ocean Summit

Newest European Liquid Galaxy installation: Google Hamburg shop-in-shop

Kamelopard update—​Panoramic camera simulation, and splines have returned

Estimating overlayfs File Space Usage on Ubuntu 12.04 LiveCD

Leap Motion Controller + Liquid Galaxy

Creating Smooth Flight Paths in Google Earth with Kamelopard and Math

Kamelopard Updates

Support for viewsyncrelay actions

Master/slave modes

New repository

Josh Tolley: About Google Earth Tours

Giraffes and Liquid Galaxy

Google Earth KML Tour Development Challenges on Liquid Galaxy

The `ogr2ogr` `-sql` option

Kamelopard update—Panoramic camera simulation, and splines have returned