Solving High-Resolution Video Stutter with GStreamer Hardware Acceleration

2026-05-18T00:00:00+00:00

In April, a client at Auburn University reached out to VisionPort Support to ask us to look into an issue with video playback for an upcoming presentation. They were running into performance issues attempting to play a video matching the full resolution of the seven-screen video wall, across all screens.

We have other clients playing video across all screens normally, on the same hardware and software, with no issue, so this was a strange report to the team. The seemingly simple request ended up leading us down a rabbit hole into how video playback works on the VisionPort platform and ultimately led to some serious modernization of our video rendering stack, the process of which we would like to share with you today.

Why was a system designed to play high-resolution video seamlessly across seven screens performing so poorly?

The System: A GStreamer Pipeline

The VisionPort video player is a custom application built on top of the GStreamer framework, initially developed to synchronize video across separate computers on our legacy Liquid Galaxy hardware configurations.

Each instance of the player renders a single video. This can be the full 7560x1920 canvas size of a seven-screen VisionPort, or often various subdivisions of the full resolution that cover two or three displays. Although the host hardware of our modern servers is theoretically sufficient, in practice the pipeline was overwhelmed.

High-level overview of the content playback flow for VisionPort systems

First Instinct: The Encoding

Our initial hypothesis was that video encoding was to blame. Encoding impacts file size, quality, and playback compatibility, and we have previously encountered issues with certain Apple workflows, videos exported from Final Cut Pro, for example. Although nothing about the original video stood out to our team as improperly configured, we re-encoded the source using an H.264 codec and a well-formed container, and tested reducing the resolutions of the video.

The stutter persisted consistently across the test videos, ruling out encoding as the root cause. In fact, the lower-resolution videos still had stuttering issues, furthering our confusion.

Hardware Decoding, Take One

We next considered that the pipeline was running entirely on the processor (CPU) instead of utilizing the ample graphics card resources (GPU). Although the video player was originally designed to support hardware decode elements, software decode had been the default configuration for a number of years.

Architecturally, the video player runs from within an application layer deployed to the host via a Docker container. The host features an NVIDIA graphics card, so our logic was that leveraging the GPU for this high-resolution video should, in theory, reduce bottlenecks induced by running everything off of the CPU.

Implementing hardware decode was a project in itself. We discovered that the original legacy decoders present in the video player, such as vaapidecodebin and vaapipostproc, were not available to our server’s CPU. NVIDIA’s accelerated decoders are not part of GStreamer’s default plugin set packaged on the Ubuntu base that we use, meaning we had to identify and install the correct package source and plugin in our Docker images. The necessary plugin package, via apt, ended up being gstreamer1.0-plugins-bad.

Lastly, we needed to resolve Docker-related resource-visibility issues to ensure the container could access the GPU. That meant using the NVIDIA Container Toolkit and passing the correct environment variables to the container so that it could utilize the GPU resources.

Once properly configured, and by enabling hardware decode in the launch command, we were able to determine that hardware decoding was functional.

A few useful commands to check whether the expected resources are present in the container:

nvidia-smi
# Checks if the container can access the GPU at all.

nvidia-smi dmon -s u
# Provides an ongoing report of what GPU features are being utilized over time,
# so we can see whether the decoder is being used.

gst-inspect-1.0 nvcodec
# Gets a list of supported features present for your current implementation of
# GStreamer with the NVIDIA codecs. You can also run the command without a
# specific feature to list every supported feature present.

After finally confirming that hardware decode was functioning, we discovered that playback had improved somewhat, but the stutter was not fully resolved.

The Real Culprit: Rendering, Not Decoding

At this point we were stumped, so we tried playing the video in another player we had available on the system, ffplay. The video appeared to play back somewhat normally.

We reported this to our developer, who decided to enable GStreamer’s debug output. The logs were filled with quality-of-service messages, indicating that one or more pipeline elements could not process frames quickly enough, causing downstream stages to drop or delay them.

The QoS pattern suggested the bottleneck was in the sink, not the decoder. The video player’s GStreamer autovideosink element was defaulting to xvimagesink, which relies on the CPU for color-space conversion and video texture handling. At 7560x1920px resolution and 60 fps, the CPU was unable to keep up with rendering the large amount of data. It turns out that the source of the issue had more to do with the framerate of the high-resolution video than with the resolution itself.

The host had glimagesink available, which is an alternative sink that uses OpenGL for GPU-based color-space conversion and texture upload. By explicitly specifying glimagesink instead of relying on autovideosink, we assigned rendering to the appropriate hardware.

This single change restored smooth playback at the target resolution.

Putting the Pieces Together

Even though we had a solution for the issue at hand, there were a few more details to sort out to make this universal for all media going forward. It turns out that the NVIDIA accelerated H.264 decoders for the hardware generation we use top out at 4K, meaning that H.264 encoded videos larger than 3840x2160 would not be able to run on the GPU even if we specified use of the decoder. Luckily, our implementation was robust enough to swap back to decoding on the CPU in the case of a fault.

Additionally, the H.265 decoder supports higher resolutions, comfortably handling 7560x1920 and allowing for future scalability.

The complete pipeline now runs the GL-backed sink with the option to enable hardware decode for H.264, H.265, VP8, VP9, or AV1, all common encoding formats. The format is auto-detected and will utilize the decoder if the content is acceptable. The CPU render is no longer a bottleneck for decoding or rendering, allowing videos to play back at the full 60 fps, even at higher resolutions.

Beyond One Engagement: Broader Implications

The Auburn University request prompted us to reevaluate our video player stack, particularly a legacy renderer choice and plugin-installation pattern from prior to our move to containerized deployments. Not mentioned in our process above were bug fixes to fix potential memory bugs and improvements to our testing process to simplify future changes.

These improvements are now incorporated into the upcoming VisionPort Library MQTT migration of the VisionPort application layer. New deployments will default to hardware-accelerated decoding via NVIDIA decoders and GL-backed rendering via glimagesink, rather than defaulting to the CPU path with the old renderer.

Key takeaways include:

Instrument first if a video pipeline is stuttering. GStreamer’s verbose debug output, particularly QoS messages, identifies pipeline bottlenecks.
Do not assume the autodetected sink is optimal. autovideosink is frequently adequate, but check the available sinks for your operating system.
Hardware acceleration in a container requires more than package installation. The container must have GPU visibility and the correct plugin set, which may be its own task.
Decoder and renderer can be independently CPU- or GPU-bound. Ensuring both are GPU-accelerated is crucial for high-resolution pipelines.

Working with End Point

If you’re facing video playback or multimedia pipeline performance challenges, whether with GStreamer, in a containerized environment, or across a multi-screen VisionPort-style installation, End Point’s Immersive and Geospatial division has extensive experience with these issues.

The GStreamer documentation is a valuable resource, and we are available to discuss our insights from similar deployments. Get in touch to set up a consultation.

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.

Converting MIDI to KML using AI: Bach’s Notes in the Hills of Greenland

2025-05-02T00:00:00+00:00

I have always been interested in ways of representing music visually. Aside from conventional music notation, I imagined other cross-modal generation methods that could take a sound and generate an image. In the same vein, I have frequently envisioned a 3D landscape in which you could discover musical “objects”.

Well, now I’ve realized a version of this dream — with caveats which will be mentioned later. In this blog I would like to demonstrate how I used AI (in my case ChatGPT using GPT-4 Turbo) to create an interesting JavaScript application from just a few phrases. In this case, we will be making an application that can take as input an existing piece of music represented by a MIDI file and as output, create a KML file that you can view as 3D objects somewhere on the globe.

Here is how I enlisted ChatGPT to help me:

please make a javascript application that can take a MIDI file and covert it to extruded polygons in a kml file

Here is a part of its response:

I was amazed. It included code to select the MIDI file, convert it to KML, and generate an output file. Plus, ChatGPT correctly interpreted my request despite my “covert” typo. :-)

Before testing it I was interested in having the color of the extruded polygon be dependent on the pitch of the note. So next I entered:

please change the color of the extruded polygon dependent on the pitch

Here is what it said:

It was implemented using npm and Node.js, which seemed excessive for this small application. To make an easier-to-run version in a single html file, I entered:

please rewrite it so it is in an html page without node.js

I thought it would be nice to be able to place the polygons, easily, wherever you wanted to, in the world.

I asked it to take a Google Street View position from Google Maps and decode the latitude, longitude, and heading.

Next, I asked it to make a nicer user interface. It “understood” the purpose of the application very well and came up with a very nice interface explaining what it does.

How to try out the application

You can try out a version of the application at https://darius.endpointdev.com/midi2kml/midi2kml_improved.html.

Find a nice place to have the MIDI data displayed. Copy the URL and paste it into the Street View URL field.

For example, here is a place in Greenland:

And here’s one on the beach in Texel in the Netherlands:

Find a nice MIDI file like Bach’s prelude and fugue in C major. Download it and put it in the “choose MIDI file” field
Press “Convert to KML”
Click on the “download KML” link
Open the KML file in a KML viewer or by manually by loading it into a program like Google Earth or Cesium.

Issues

This application works at least partially — it puts triangular prisms for each MIDI track, over time, and shows different colors for different notes (though the color–note correlation is not clear). There are plenty of issues and questions, however:

There are lots of overlapping polygons. It’s unclear whether these are just errors, or represent different dynamics or articulations
The “Play MIDI” button doesn’t work — it plays tones of some kind, but in my testing it was either a single bell sound, or computer noise reminiscent of an AOL dial-up modem.
When I tested it on an orchestral score (Mozart’s Requiem, Kyrie), the instrument label pins were off to the side, not indicating which line of notes they corresponded to, and were mostly labeled “acoustic grand piano,” which is not an instrument included in the MIDI file.

Using AI for blog post image processing

As an aside, I created this blog using Google Docs with PNG pictures embedded in it. Our blog structure requires a Markdown document with separate WebP images. Google Docs has a nice Markdown export function, but it converts the PNG images into embedded Base64-encoded PNG. So I asked ChatGPT to extract the Base64-encoded PNG and create WebP files. It created a Python script that did this perfectly:

import os
import base64
import re
from PIL import Image
from io import BytesIO

# Path to your Markdown file
md_file_path = "example.md"

# Directory to store extracted and converted WEBP images
output_dir = "converted_images"
os.makedirs(output_dir, exist_ok=True)

# Load the Markdown content
with open(md_file_path, "r") as md_file:
    content = md_file.read()

# Regex to find base64-encoded PNGs in the Markdown

base64_pattern = re.compile(
    r"\[.*?\]:\s*<data:image/png;base64,([A-Za-z0-9+/=]+)>"
)

# Initialize a counter for naming the files
counter = 1

for match in base64_pattern.finditer(content):

    print(f"Match found: ")
    base64_data = match.group(1)
    print(base64_data)

    # Decode the base64 string to a PNG image
    png_data = base64.b64decode(base64_data)
    png_image = Image.open(BytesIO(png_data))

    # Save the PNG as a WEBP file
    webp_name = f"image_{counter}.webp"
    webp_path = os.path.join(output_dir, webp_name)
    png_image.save(webp_path, "WEBP")

    # Replace the base64 PNG in the Markdown with a reference to the WEBP file
    content = content.replace(match.group(0), f"![Image {counter}]({webp_path})")
    counter += 1

# Save the updated Markdown file
updated_md_path = os.path.splitext(md_file_path)[0] + "_updated.md"
with open(updated_md_path, "w") as updated_md_file:
    updated_md_file.write(content)

print(f"Updated Markdown file saved: {updated_md_path}")
print(f"WEBP images saved in: {output_dir}")

Unfortunately, when Google Docs embeds the images, it seems to downsize the resolution, so for this post, old-school image processing it is!

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.

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

An OpenStreetMap Editor for Adding Public Transit Data Using GTFS

2024-05-08T00:00:00+00:00

You can think of OpenStreetMap (OSM) as Wikipedia for maps. While it may not be as well known as Google Maps or Apple Maps, OSM becomes indispensable when you need data, rather than just a visual representation on your phone. The only other real option for data retrieval is to consult a local agency, so if you’re in search of a comprehensive and global cartographic dataset, OSM is the go-to choice.

OSM also excels in providing navigation for pedestrians and cyclists. For the past decade, I’ve navigated the US, Canada, and Europe using OSM through the OsmAnd app, a dedicated Android application for OpenStreetMap.

Overall, my experience has been quite positive, except for one significant weakness: public transportation. Specifically, I’ve been missing the convenient access to timetables for buses, trams, or any other form of public transit.

A significant part of the challenge in making public transportation data readily available on OSM and its associated applications is the fact that the OSM data model isn’t particularly well suited for this type of information. While OSM can store the location of bus and train stops, the actual timetables change so often that keeping them up to date in OSM is essentially impossible.

Enter the General Transit Feed Specification (GTFS), a widely adopted standard for managing public transportation data. I wanted to explore ways to integrate OSM with GTFS effectively.

My OpenStreetMap editor for GTFS data

A simple approach for addressing this challenge would be to overlay an OSM map with stops from GTFS. While this would be relatively straightforward, it doesn’t leverage OSM’s biggest strength—its vibrant community. One of OSM’s most significant advantages is that it dynamically incorporates user contributions: as soon as the community accesses useful data, members enhance the details and accuracy of its mapping data. Therefore, I’ve been working on truly integrating GTFS data with OSM, creating a cohesive mapping experience rather than settling for a disjointed overlay.

Although the implementation is a bit trickier, I believe the better approach for handling this challenge involves merging GTFS stops with those already present in OSM and incorporating GTFS stop codes into OSM data. Hence, I’ve developed a single-page online editor. This tool facilitates the creation, editing, and deletion of stops within OSM. It also highlights stops based on their alignment with stops specified in a given GTFS file.

Editing the routes wasn’t a priority, yet I found it necessary to match GTFS routes and trips with OSM routes and their variants. Displaying trips shows which part of a street a route uses and also which side of a street bus stops are located on.

I’ve deployed the app on my GitHub, where you can try it out: https://kiselev-dv.github.io/osm-gtfs/.

How to use the app

To start, download a GTFS data dump. They are usually published by local transit companies. As an example, I’ll use data from Halifax, Nova Scotia.

Open the GTFS ZIP file in the editor. The editor should parse stops from GTFS.

Next, query OSM data and select “OSM Tag with GTFS stop code.” After OSM data is loaded you will get OSM tags statistics which might help you to see if there are some popular tag combination for GTFS data in the area. OSM doesn’t have strict data model, but as a rule of thumb for that type of data ref or gtfs:ref should work. If there are multiple agencies sharing a stop and each of them publishes its own GTFS data, you can use something like gtfs:<agency_name>:ref. By default the editor will substitute the most popular tag containing ref or gtfs.

Now you can match stops from OSM with stops from GTFS. Matches are color coded:

Blue: matching stops
Red: stops which are present in GTFS but not mapped in OSM (stops to add)
Black: stops mapped in OSM but not matched with GTFS stop (probably outdated stops which are no longer in use and may be deleted, or stops not used by the agency whose GTFS data you are using)

Adding stops to OSM

There are two main cases for adding or matching a stop:

There is no stop in OSM at all and we want to create a new one
There is a stop in OSM and we want to edit it and add GTFS data

Select one of the GTFS stops. On the left panel there will be two buttons: “Create” and “Assign”.

The “Create” button will switch the map into satellite mode, create a new OSM stop with GTFS code, and add a stop name at the point where you click. When creating a stop or editing its location, pay attention to which side of the road it should be on. To simplify that, you can highlight one of the routes in the “Routes on this stop” section.

The “Assign” button allows you to select one of the existing OSM stops, and set its GTFS code.

Demo videos

You can see a video on my YouTube channel with the latest updates to the editor, along with a live editing session.

I have also created a YouTube playlist with more demos.

An important note

An important note is that I do not upload results directly into OSM. Instead, I generate an XML file for an OSM changeset which you can view and edit in JOSM or another editor. I do this partly so I do not have to deal with authentication, but more importantly, because I see editing public transport relations in OSM as an advanced topic and it makes sense for editors to demonstrate a higher level of sophistication than general users. But I might change my mind about this if I get feedback that it would be desirable.

My app is built using React and Leaflet. You can find the code on my GitHub: https://github.com/kiselev-dv/osm-gtfs

Making a Loading Spinner with tkinter

2024-03-05T00:00:00+00:00

When you need a loading spinner, you really need a loading spinner. Interested in putting something on the screen without installing a pile of dependencies, I reached deep into the toolbox of the Python standard library, dug around a bit, and pulled out the tkinter module.

The tkinter module is an interface to the venerable Tcl/Tk GUI toolkit, a cross-platform suite for creating user interfaces in the style of whatever operating system you run it on. It’s the only built-in GUI toolkit in Python, but there are many worthy alternatives available (see the end of the post for a list).

Here I’ll demonstrate how to make a loading spinnner with tkinter on Ubuntu 22.04. It should work on any platform that runs Python, with some variations when setting up the system for it.

Prerequisites

My vision for the loading spinner is some spinning dots and a logo, since this is such a convenient branding opportunity. To accomplish this we’ll be extending tkinter with Pillow’s ImageTk capability, which can load a PNG with transparency.

To produce that PNG with transparency, first we may need to rasterize an SVG file, because wise designers work in vectors. This is made trivial by Inkscape, a free and complete vector graphics tool:

$ inkscape logo.svg -o logo.png

With the logo in hand, we can move on to setting up our dependencies. Ubuntu’s python3 distribution doesn’t include tkinter by default, so we’ll need to install it explicitly, along with Pillow’s separate ImageTk support:

$ sudo apt install python3-tk python3-pil.imagetk

This may occupy up to 75MB, if Python was already installed. This was still the smallest apt footprint of all of the Python GUI libraries in consideration. Pygame was also a strong contender.

Code

Let’s start with something simple: putting the logo on the screen.

#!/usr/bin/env python3

from PIL import Image, ImageTk
from tkinter import BOTH, Canvas, Tk


# Desired dimensions of our window.
WIDTH, HEIGHT = 500, 500

if __name__ == "__main__":
    # Create the root window object.
    root = Tk()
    # Create a canvas for drawing our graphics.
    canvas = Canvas(root, width=WIDTH, height=HEIGHT, background="black")
    # Fill the entire window with the canvas.
    canvas.pack(fill=BOTH, expand=1)

    # Load the logo PNG with regular PIL.
    logo_img = Image.open("logo.png")
    # Convert the logo to an ImageTk PhotoImage.
    logo_pi = ImageTk.PhotoImage(logo_img)
    # Add our logo image to the canvas.
    canvas.create_image(
        WIDTH / 2,
        HEIGHT / 2,
        image=logo_pi,
    )

    # Run the tkinter main loop.
    root.mainloop()

This puts the logo in the center of a window, but the logo may be too large or small. Let’s scale it according to the window dimensions, let’s say to about ⅔ of the width so we have some room for spinning dots:

#!/usr/bin/env python3

from PIL import Image, ImageTk
from tkinter import BOTH, Canvas, Tk


# Desired dimensions of our window.
WIDTH, HEIGHT = 500, 500

if __name__ == "__main__":
    # Create the root window object.
    root = Tk()
    # Create a canvas for drawing our graphics.
    canvas = Canvas(root, width=WIDTH, height=HEIGHT, background="black")
    # Fill the entire window with the canvas.
    canvas.pack(fill=BOTH, expand=1)

    # Load the logo PNG with regular PIL.
    logo_img = Image.open("logo.png")
    # Resize the logo to about 2/3 the window width.
    scaled_w = round(WIDTH * 0.6)
    scaled_h = round(scaled_w / (logo_img.width / logo_img.height))
    logo_img = logo_img.resize((scaled_w, scaled_h), Image.LANCZOS)
    # Convert the logo to an ImageTk PhotoImage.
    logo_pi = ImageTk.PhotoImage(logo_img)
    # Add our logo image to the canvas.
    canvas.create_image(
        WIDTH / 2,
        HEIGHT / 2,
        image=logo_pi,
    )

    # Run the tkinter main loop.
    root.mainloop()

That’s better. Now let’s add the promised spinning dots. We’ll draw some ovals on the canvas and modify our main loop to animate them:

#!/usr/bin/env python3

import math
import time

from PIL import Image, ImageTk
from tkinter import BOTH, Canvas, Tk


# Desired dimensions of our window.
WIDTH, HEIGHT = 500, 500
# Coordinates of the center.
CENTER_X, CENTER_Y = WIDTH / 2, HEIGHT / 2
# How many spinning dots we want.
NUM_DOTS = 8

if __name__ == "__main__":
    # Create the root window object.
    root = Tk()
    # Create a canvas for drawing our graphics.
    canvas = Canvas(root, width=WIDTH, height=HEIGHT, background="black")
    # Fill the entire window with the canvas.
    canvas.pack(fill=BOTH, expand=1)

    # Load the logo PNG with regular PIL.
    logo_img = Image.open("logo.png")
    # Resize the logo to about 2/3 the window width.
    scaled_w = round(WIDTH * 0.6)
    scaled_h = round(scaled_w / (logo_img.width / logo_img.height))
    logo_img = logo_img.resize((scaled_w, scaled_h), Image.LANCZOS)
    # Convert the logo to an ImageTk PhotoImage.
    logo_pi = ImageTk.PhotoImage(logo_img)
    # Add our logo image to the canvas.
    canvas.create_image(
        CENTER_X,
        CENTER_Y,
        image=logo_pi,
    )

    # Radius in pixels of a single dot.
    dot_radius = WIDTH * 0.05
    # Radius of the ring of dots from the center of the window.
    dots_radius = WIDTH / 2 - dot_radius * 2

    # Helper function to calculate dot position on each update.
    def get_dot_coords(n: int, t: float):
        """Get the x0, y0, x1, y1 coords of dot at index 'n' at time 't'."""
        angle = (n / NUM_DOTS) * math.pi * 2 + t
        x = math.cos(angle) * dots_radius + CENTER_X
        y = math.sin(angle) * dots_radius + CENTER_Y
        return x - dot_radius, y - dot_radius, x + dot_radius, y + dot_radius

    # Create all the dots.
    t0 = time.monotonic()
    for n in range(NUM_DOTS):
        coords = get_dot_coords(n, t0)
        canvas.create_oval(
            *coords,
            fill="#888888",
            width=0,  # Border width.
            tags=f"dot_{n}",
        )

    # Set up a custom main loop to animate the moving dots.
    while True:
        # Check the time of this update.
        t = time.monotonic()
        for n in range(NUM_DOTS):
            # Get the desired coords for this dot at this time.
            coords = get_dot_coords(n, t)
            # Move the dot on the canvas, finding it by its tag.
            canvas.coords(
                f"dot_{n}",
                *coords,
            )
        # Call the required tkinter update function.
        root.update()
        # Attempt to stabilize the timing of this loop by targeting 60Hz.
        while t0 < t:
            t0 += 1 / 60
        time.sleep(t0 - t)

You may notice that the dots don’t look all that great. There’s no anti-aliasing when drawing shape primitives in tkinter, so the edges look jagged compared to our well-scaled logo image. One hack is to layer slightly larger and dimmer shapes under each object, which you might do like so:

#!/usr/bin/env python3

import math
import time

from PIL import Image, ImageTk
from tkinter import BOTH, Canvas, Tk


# Desired dimensions of our window.
WIDTH, HEIGHT = 500, 500
# Coordinates of the center.
CENTER_X, CENTER_Y = WIDTH / 2, HEIGHT / 2
# How many spinning dots we want.
NUM_DOTS = 8
# Colors for each layer of fake anti-aliasing around each dot.
# Must be in order from back to front.
COLORS = ["#888888", "#BBBBBB", "#FFFFFF"]

if __name__ == "__main__":
    # Create the root window object.
    root = Tk()
    # Create a canvas for drawing our graphics.
    canvas = Canvas(root, width=WIDTH, height=HEIGHT, background="black")
    # Fill the entire window with the canvas.
    canvas.pack(fill=BOTH, expand=1)

    # Load the logo PNG with regular PIL.
    logo_img = Image.open("logo.png")
    # Resize the logo to about 2/3 the window width.
    scaled_w = round(WIDTH * 0.6)
    scaled_h = round(scaled_w / (logo_img.width / logo_img.height))
    logo_img = logo_img.resize((scaled_w, scaled_h), Image.LANCZOS)
    # Convert the logo to an ImageTk PhotoImage.
    logo_pi = ImageTk.PhotoImage(logo_img)
    # Add our logo image to the canvas.
    canvas.create_image(
        CENTER_X,
        CENTER_Y,
        image=logo_pi,
    )

    # Radius in pixels of a single dot.
    dot_radius = WIDTH * 0.05
    # Radius of the ring of dots from the center of the window.
    dots_radius = WIDTH / 2 - dot_radius * 2

    # Helper function to calculate dot position on each update.
    def get_dot_coords(n: int, t: float, c: int):
        """Get the x0, y0, x1, y1 coords of dot at index 'n' at time 't'.
        Inflate the radius by color index 'c'."""
        angle = (n / NUM_DOTS) * math.pi * 2 + t
        x = math.cos(angle) * dots_radius + CENTER_X
        y = math.sin(angle) * dots_radius + CENTER_Y
        # Invert the color index and add to the radius.
        radius = dot_radius + (len(COLORS) - c) * 0.75
        #radius = dot_radius + c
        return x - radius, y - radius, x + radius, y + radius

    # Create all the dots.
    t0 = time.monotonic()
    for c, color in enumerate(COLORS):
        for n in range(NUM_DOTS):
            coords = get_dot_coords(n, t0, c)
            canvas.create_oval(
                *coords,
                fill=color,
                width=0,  # Border width.
                tags=f"dot_{c}_{n}",
            )

    # Set up a custom main loop to animate the moving dots.
    while True:
        # Check the time of this update.
        t = time.monotonic()
        for c, color in enumerate(COLORS):
            for n in range(NUM_DOTS):
                # Get the desired coords for this dot at this time.
                coords = get_dot_coords(n, t, c)
                # Move the dot on the canvas, finding it by its tag.
                canvas.coords(
                    f"dot_{c}_{n}",
                    *coords,
                )
        # Call the required tkinter update function.
        root.update()
        # Attempt to stabilize the timing of this loop by targeting 60Hz.
        while t0 < t:
            t0 += 1 / 60
        time.sleep(t0 - t)

The fake anti-aliasing was a fun exercise, but for this use case you’ll probably get better-looking results out of scaling a PNG asset like we did the logo.

Resources

If you’re interested in learning more about tkinter, see also:

Other Python GUI/graphics toolkits you might consider:

Pygame
Pyglet
PySide6 (official Qt binding)
PyQt (unofficial Qt binding)
wxPython

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);
   }
};

VisionPort: The Future of Tourism Marketing

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

In a world of rapidly evolving technology, businesses and organizations in the tourism industry must adapt to stay relevant and competitive. VisionPort offers innovative and powerful technological solutions that can help organizations and destinations in tourism enhance the customer experience and reach a wider audience.

By showcasing destinations and providing immersive and engaging content, VisionPort can help agencies stay ahead of the competition through the use of geographic information systems and customized presentations.

Showcase destinations

VisionPort’s ability to showcase destinations through interactive panoramic views and virtual tours is a game-changer for the tourism industry. By providing immersive and engaging content, potential visitors can get a real sense of what it would be like to experience a particular destination. This can help to spark their interest and inspire them to plan a trip to that location.

With its support for a variety of media types, including panoramic views, photos, and videos, VisionPort enables businesses to create high-quality content that highlights their unique features and attractions. For instance, a resort or hotel can create panoramic views of its grounds, showing off its pools, restaurants, and other amenities. These views can be further enhanced by overlaying information about the features and services available.

Moreover, VisionPort allows businesses to create maps and guides that display the different attractions and points of interest within a destination. Visitors can explore the map and click on various locations to learn more about them with photos, videos, and other relevant information. For instance, a map of a city could point to different neighborhoods, museums, and restaurants, allowing visitors to plan their itinerary before arriving at the destination. This way, visitors have a more engaging and personalized experience while exploring the destination.

Overall, VisionPort’s ability to feature destinations through interactive panoramic views and maps provides an innovative and powerful tool for the tourism industry. It enables businesses to create high-quality and engaging content that can inspire potential visitors to experience a destination for themselves, thereby boosting the tourism industry as a whole.

Display a multitude of media

VisionPort’s support for a wide range of media types, including GIS map layers, customizable graphics, videos, and panoramic media, is a key feature that can help destinations create immersive content that illustrates their unique features and attractions. By leveraging these different media types, destinations offer a more personalized and engaging experience to potential visitors, which can be a powerful motivator for them to plan a visit.

For example, videos can be a great way to exhibit the sights and sounds of a destination, allowing viewers to see the beauty of the landscape, the energy of the local culture, and the excitement of various activities and events that take place there. Videos can also be used to introduce key stakeholders, such as local business owners and tourism officials, and to provide an overview of the destination’s history and significance.

Similarly, panoramic media offers a 360° view of a location, allowing viewers to experience the destination in a more immersive and interactive way. This is particularly useful for destinations that have unique or hard-to-reach features, such as mountain ranges, waterfalls, or historic sites, which are difficult to capture in a traditional photograph or video.

By using these different media types, destinations can create content that is not only informative but also inspiring, helping potential visitors to feel a deeper connection to the destination and motivating them to plan a trip. This can ultimately lead to increased tourism revenue and a stronger local economy.

Marketing

The VisionPort platform helps businesses refine their marketing strategies and create more effective campaigns with engaging, dynamic presentations to present the analytics of their latest marketing campaigns.

VisionPort also helps businesses collaborate more effectively across departments and teams. Providing a common platform for information sharing and collaboration, VisionPort has facilitated greater communication and teamwork, leading to overall more efficient and effective operations. This translates to increased productivity, streamlined processes, and ultimately, revenue.

Conclusion

VisionPort is a powerful platform that is helping businesses enhance customer experience and reach wider audiences. By showcasing destinations, creating immersive content, and providing personalized and engaging experiences, agencies are inspiring visitors to plan trips and create unforgettable memories.

By increasing interaction and developing new methods of presenting and communicating information, VisionPort is a tool that has its place in the future of marketing, especially in the tourism industry.

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.

Tennessee Hackathon 2023

2023-03-30T00:00:00+00:00

We just had our first company gathering in our Tennessee office after a hiatus of several years. About 20 End Pointers came to our Johnson City, Tennessee office to work on various VisionPort projects. For several of us, it also provided an opportunity to meet each other in person for the first time.

End Point Tennessee office (EPTN)

Other than our Johnson City-based team, for many of us this was our first look at our Tennessee office from which the VisionPort systems are assembled, tested and shipped.

Our Content Management System (CMS) team worked on some exciting updates to our VisionPort CMS, including important modifications to our touchscreen systems and improvements to the user interface.

Meanwhile our Research & Development team worked on upgrades to the VisionPort system itself, focusing on integrating large and small touchscreens for multimedia presentations. One such improvement was support for 8 tabletop touchscreens integrated to serve 16 museum visitors simultaneously.

Our support team worked on testing and spinning up documentation to bring our inventory up to date and prepare for the next wave of our new VisionPort CMS installations.

Casablanca

The luxurious lounge working space at one of our Airbnb locations, nicknamed Casablanca, enabled us to be comfortably spread out as we worked together on various projects.

A morning meeting with plenty of room left:

A quiet comfy corner for planning!

Working breakfasts:

Pigeon

Just across from Casablanca, we did some relaxing in the “Pigeon coop”, another luxurious abode:

Impromptu roof terrace get together:

Birthdays, dinner, and farewell

We also had a couple of employee birthdays to celebrate during the hackathon!

And a tasty dinner with everyone the final evening:

It was great to see everyone at the Tennessee office. We did plenty of hard work, sometimes sitting elbow to elbow. It certainly was a great opportunity after working together remotely, and helped us experience the camaraderie which is typical of End Point’s unique spirit. Until next time, we will continue to improve our VisionPort systems and extend our remote collaboration!

University of Denver and VisionPort: The Classroom of the 21st Century

2022-10-18T00:00:00+00:00

VisionPort’s recent installation at the University of Denver is transforming education and has even found itself featured in Forbes.

Installed in the Marion J. Crean Collaboratory room, VisionPort is doing what it does best: engaging audiences and bringing ideas to life.

The Collaboratory room gets its name from its mission, to be a collaborative laboratory, specifically for DU’s real estate and construction management students.

VisionPort was designed with geographic information systems (GIS) in mind, and the content management system we built from the ground up allows experts and novices alike to explore real estate and construction opportunities. From flying around undeveloped land, to exploring cityscapes in three dimensions, the VisionPort is the best platform for presenting GIS data.

“What [the VisionPort] is going to give us is the opportunity to sit in class, and literally, be able to fly to any property, anywhere in the world, and walk that property, see that property.” —Dr. Barbara Jackson

Seven displays spanning 18 feet, installed in a custom case on top of a beautiful wood stage, the Collaboratory’s design is one of the most unique and intriguing yet.

The world is once again facing new real estate market conditions and the VisionPort platform is the perfect tool to assist in presenting the data needed to understand how the landscape will look over the coming years.

Developers and real estate professionals are realizing that data is more important than ever to cope with the evolving market. Efficiency is the name of the game, and to be able to collect, analyze, and present that data is VisionPort’s bread and butter.

“Our students will walk out of here with state-of-the-art knowledge about how technology in real estate development and construction management will play in the field.” —Vivek Choudhury, dean of the Daniels College of Business

You can hear what Dr. Barbara Jackson has to say about the Collaboratory and VisionPort’s role on DU’s Burns School YouTube channel.

We are grateful to be able to contribute to the education experience and look forward to seeing the Collaboratory’s VisionPort play its part in what Dr. Jackson has dubbed “the classroom of the 21st century.”

For more information about VisionPort, email sales@visionport.com or visit www.visionport.com.

Kansas State University: One Year with VisionPort

2022-08-18T00:00:00+00:00

It has been almost a year since Kansas State University brought the VisionPort platform into their Hale library. I recently had the pleasure of connecting with Jeff Sheldon, Associate Director of the Sunderland Foundation Innovation Lab, to discuss how the school has been using the platform.

It’s no surprise to hear that the Architecture, Planning and Design (AP) students have taken to VisionPort immediately. Being originally designed around displaying geographic information system (GIS) data, the platform allows users to fly over and through city streets and see buildings in 3D, as well as travel around the world looking for areas of possible real estate development. Many of our clients also use VisionPort to give panoramic, three-dimensional tours of building interiors, to show future tenants properties right from their office and brainstorm design possibilities.

In addition to the AP Design students, VisionPort has found itself being used to immerse students in their education with an incredible National Geographic presentation that features 360° videos including swimming with sharks and getting up close to sea lions and elephants in their natural habitats, as well as presentations about the moon landing, and even the reconstruction of the Hale library after a fire in 2018.

An extremely innovative application KSU has come up with is using the VisionPort system to create a quiet space for students. During exam weeks, the platform is used to create a calming environment, displaying relaxing scenes to help students alleviate stress and promote good mental health.

“Ultimately, people don’t expect this sort of device in a library and VisionPort has helped change the longstanding narrative that a library is just about books.”

It’s always great to hear about VisionPort being a catalyst for collaboration among students and faculty. Students are encouraged to work together to bring their projects to life on VisionPort and share tips and tricks they’ve learned by working with our content management system.

Interview

End Point Dev: How has VisionPort aided the evolution of the Hale Library?

Jeff Sheldon: VisionPort, as a feature of the new Sunderland Foundation Innovation Lab in Hale Library, has helped evolve the University’s library space in several ways. As a visualization tool, VisionPort allows our students, faculty, and visitors to experience rich immersive presentations in a way they haven’t before. Featuring the same Google products we see in classroom instruction, at scale and in high resolution, also affords students an unexpectedly different perspective from what they experience more traditionally on a small screen or in washed-out projections. This has been especially valuable amidst the pandemic, which has transformed expectations to the virtual almost as a default.

Ultimately, people don’t expect this sort of device in a library and VisionPort has helped change the longstanding narrative that a library is just about books.

What types of presentations have students and faculty been creating with VisionPort?

The presentations our students and faculty have been most excited about feature video across our entire 7-panel display and 360° integration for photos and videos. Some have experimented with data visualization and location-to-location journeys, but an overwhelming number have been drawn to the simple navigation controls to use locations and sites as visual aids during group presentations and as a complement to other examples they wheel in.

What are some ways in which Google Earth is being utilized with VisionPort?

Google Earth’s ability to roll onto the screen and zoom into specific locations has the effect of taking viewers on a journey. You can read that in the faces of those watching as a destination unfolds or the promise of a demonstration materializes in front of a tour group. We have quite a few guests visit their hometowns to reminisce and share stories with others, access remote sites to plan for travel, wander the streets of historic figures, and to experience the cultural and socioeconomic influences on a community.

What content on the VisionPort have students been most excited about?

That’s a tough one to narrow down. There have been a few unexpected moments during some of our featured 360° videos where a visitor will turn the camera view around and be charged by an elephant or sniffed by a lion. Seeing such an experience result in a yelp or jump is thrilling.

What fields of study are being presented most frequently?

Kansas State’s Architecture, Planning and Design (AP Design) students are regulars, but we’ve also fielded student presentations from our history and language departments. A number of ad-hoc classes have worked on presentations as well, but there are many curious about the act of how to visualize and present data to different audiences and who enjoy the process of exploration, but aren’t always looking to produce a specific outcome to share. We create accounts for those students to access the system and learn from their peers and the stock examples.

How are panoramic images being used on the VisionPort?

We’re very interested in panoramic and 360° images for the sake of storytelling. One example has been to tell the history of Hale Library in the aftermath of the 2018 fire it endured. Another has been to show the ruins of culturally significant sites some of our students have visited. We’ve also worked with faculty members to produce wellness videos during exam weeks, such as a calming aquarium or nature scene.

Conclusion

We are always happy to hear first-hand experiences universities are having with the VisionPort platform and we are honored to be able to contribute to the education experience.

Thank you to Mr. Sheldon for the great meeting. We look forward to hearing how KSU innovates with VisionPort over the next year!

For more information about VisionPort, email sales@visionport.com or visit www.visionport.com.

Auburn University and VisionPort: How the World Gets Its Water

2022-07-28T00:00:00+00:00

The IBT Water Project at Auburn University, headed by Associate Professor P.L. Chaney, has done outstanding work illustrating in a GIS format how cities around the world get their water. The Geoscience department has mapped how water is captured and distributed in Australia, Egypt, India, Mexico, Kazakhstan, and the western USA.

The department chose the Central Arizona Project to turn into an interactive presentation on the VisionPort platform.

Starting at the Mark Wilmer Pumping Plant, water is pumped from the Colorado River towards over a dozen plants and lifted up over 2,000 feet in elevation across a series of “stair-steps” before it reaches its final destination near Tucson, where it is then distributed across the state to where it is most needed.

This data displayed on their VisionPort, installed in a custom wood case in their library, allows students to see the entire journey in a 3D environment spanning seven 65-inch displays. The presenter can take them to each stop and explain the functions of the many plants, check gates, and turnouts along the way.

Numerous departments at Auburn University have had success turning their presentations into engaging experiences on the VisionPort platform and I look forward to seeing and reporting on what their students and faculty do next.

For more information about VisionPort, email sales@visionport.com or visit www.visionport.com.

VisionPort at University of Tokyo, New York office: An Exhibition for Peace on August 6th and 7th

2022-07-26T00:00:00+00:00

Ground Zero, Hiroshima, Japan – August 6th, 1945. Visualized by the lab of Professor Hidenori Watanave.

Technology and education go hand in hand, and the VisionPort platform is being used every day to make that connection.

We are extremely honored to be able to contribute to the first exhibition at the University of Tokyo’s New York office, “Convergence of Peace Activities: Connecting and Integrating by Technologies”.

It is said that those who do not learn from history are condemned to repeat it, and in that vein, the exhibition, drawing from the work of Professor Hidenori Watanave, will be using the VisionPort platform to educate viewers on the realities of the bombings of Hiroshima and Nagasaki, on the date of the 77th anniversary of the first nuclear weapon used in war.

The team has been collecting and colorizing photographic material from the aftermath of the bombings for over 10 years. The exhibition will combine that work with interviews and writings from survivors on a GIS canvas to allow attendees to see what it looked like and to hear from those who were there.

The lab will also be presenting the work they have been doing covering the ongoing conflict in Ukraine. Day by day they collect the latest images from the war, identify the locations of the events and use geospatial data to map and present it in an interactive, 3D environment.

Invasion of Ukraine, provided by the labs of Professors Hidenori Watanave and Taichi Furuhashi.

The exhibition will serve to show us where we have been and where we are now, in hopes of being a “convergence,” a place to connect and use all of our available information and technologies so that we may begin a new era of understanding and in turn, peace.

The exhibition will also feature work done by Co-Op Peace Map, Mainichi Newspaper and the University of Kyoto.

The educational work that the University of Tokyo is doing with the VisionPort platform is inspiring and we look forward to being there to see it in memoriam of that fateful day.

Register here and join us for this viewing on August 6th and 7th at the University of Tokyo’s New York office located at 145 W. 57th St., 21st Floor, New York, NY 10019.

For more information about VisionPort, email sales@visionport.com or visit visionport.com.

Images and photography provided by the University of Tokyo, the department of Interfaculty Initiative in Information Studies, the lab of Professor Hidenori Watanave, and the lab of Professor Taichi Furuhashi.

Job opening: VisionPort support engineer (western U.S.)

2022-04-14T00:00:00+00:00

We are looking for an engineer to join the End Point Immersive and Geospatial Support (I+G) Team—a small, multidisciplinary team that supports our company’s clients with their VisionPort systems incorporating Liquid Galaxy technology. VisionPort hardware consists of large-panel HD TVs within a curved panoramic environment, supported by a server stack with power, video, audio, and network connections and equipment.

The candidate will be based out of a home office in the western United States (Washington, Oregon, California, Idaho, Utah, Nevada, Arizona, Montana, Wyoming, New Mexico, and Texas). The engineer will be asked to travel to, perform, and supervise system installations, in addition to day-to-day remote support work from a home office.

Occasional evenings and weekend on-call shifts are shared amongst the team.

This is a great entry-level opportunity for people already familiar with light audiovisual, server room, and/or installation handiwork to get experience with all aspects of production computer systems and their deployment. More experienced individuals will have the opportunity to work directly in feature development on production systems and possibly assist with other ongoing consulting projects the I+G team takes on.

Overview

Job Level: Entry-level or experienced, full-time or part-time.
Location: Remote work with occasional on-site.
Environment/Culture: Casual, remote management, lots of video meetings.
Benefits: For full-time employees, paid vacation and holidays, 401(k), health insurance.

Core responsibilities

Support clients over email and video calls, troubleshooting system features or content.
Build server stacks, troubleshoot hardware, and fix software issues during installation.
Track, monitor, and resolve system issues on production computer systems.
Report and document issues and fixes.
Adapt to differing needs day to day!

Preferred skills and experience

A driver’s license is required for travel.
Comfortable with basic installation tools: hand drill, cable dressing, cable pulls, crimping, etc.
Experience on an active construction or office renovation site.
Working familiarity with computers, general exposure to internal components and software.
Self-driven, results-, detail-, and team-oriented, follows through on problems.
Familiarity with Linux basics, or willingness to learn.

What work here offers:

Flexible work hours
Annual bonus opportunity
Freedom from being tied to an office location
Collaboration with knowledgeable, friendly, helpful, and diligent co-workers around the world

About End Point

End Point is the leading global agency for developing, deploying, and supporting VisionPort systems. With over 200 installations and events worldwide, our team of engineers and content developers has a deep knowledge of the hardware, software, and aesthetics that can make a VisionPort come to life as a dazzling data, business, education, or presentation tool.

End Point was founded in 1995 and now has over 60 engineers based throughout North America, Europe, and Asia. This team brings decades of experience in systems management, database programming, web platform development, application development, and more specifically, VisionPort development and support.

Get in touch with us

~~Please email us an introduction to jobs@visionport.com to apply!~~ (This job has been filled.)

Include your location, resume, LinkedIn URL (if any), and whatever else may help us get to know you. You can expect to interview with the Support Lead and Team Manager.

We look forward to hearing from you! Direct work seekers only, please—this role is not for agencies or subcontractors.

We are an equal opportunity employer and value diversity at our company. We do not discriminate on the basis of sex/gender, race, religion, color, national origin, sexual orientation, age, marital status, veteran status, or disability status.

VisionPort Hardware Overview

2022-01-24T00:00:00+00:00

End Point’s VisionPort has gone through a number of hardware iterations before becoming the system our clients are familiar with today. In this post, we will break down the history of the changes we have made over the years, and how we ended up where we are today.

The latest server specification used for all current VisionPort installations is known internally as the “LGOne” (Liquid Galaxy One): a node that can support up to eight discrete displays as a single desktop. LGOne is now considered the default specification and will guide the direction and future of VisionPort platform development.

A few definitions before we continue

Node: a single computer/server.
Display node: A computer that acts as a source for the displays, and runs applications.
Head node: A computer that acts as the “brain” of the system.

Some history

The original server specification for the Liquid Galaxy (now known as VisionPort), was developed around 2011 and is now known as “LGClassic”. The LGClassic specification supported one display per node. For the typical seven-screen installation, this meant that eight individual LGClassic display nodes and one head node were required to run our seamless video wall technology with an integrated podium. While the experience was seamless for users, improvements to the performance, flexibility, and overall cost could be made.

Around 2015, advances in graphics and computing technology allowed us to proceed to the next generation: the LGX. LGX nodes supported up to four discrete displays, and thus brought the number of display nodes necessary to run a typical seven-screen installation down to two. This meant that users could experience improved performance and syncing of applications, fewer points of failure, and more modern components. Around this same time, the CMS (Content Management System, known internally as “Roscoe CMS”) was released with a modern interface and tools that made it easier for users to generate content quickly for their system. Still, there were some nuances that affected performance and made content creation less than ideal, like how a seemingly seamless video wall was in actuality two discrete computer desktops.

Although the LGX line of systems have been updated with newer graphics cards and processors over the years, there have been few significant changes to the standard server specification since 2016. As of 2021, the majority of existing systems in the field continue to utilize the LGX specification.

Released in early 2020, LGOne continued the trend towards improved reliability, performance, and feature support. Systems with an LGOne specification can expect:

Support for 8 (typical) to 16 (advanced) discrete displays running full-resolution application imagery without the need for expensive AV technology such as digital matrix switchers or video wall processors.
A unified desktop experience, greatly simplifying content creation for CMS users. Consider no rules, borders, or needing to split up images to act a specific way. Simply drag and drop the image anywhere on screen to place it. Images, web pages, and videos can easily span all screens as well, if desired. In addition, support for graphic transparency allows presentation creators flexibility in how they present their content to viewers.
Increased stability and performance of the system with enterprise grade Nvidia Quadro RTX graphics and Intel Xeon processors.
Reduced server room footprint allows for simpler installation and maintenance with fewer moving parts.
Support for technology integrations, like native Video Conferencing or Screen Sharing solutions.
Support for live view and remote control, for when a user is not in the office.
Improved window management tricks that allow for improved scene transitions and smarter content switching.

The LGOne server stack

In addition to all the above, standardization of the spec allows VisionPort systems with the LGOne specification to support all of our future development. This includes an upcoming rewrite to the CMS with a new interface, improved workflow, and a significant change to how content is previewed. As always, any customer with an up-to-date maintenance agreement will receive all updates and support for the above when made available.

Over the years we have received plenty of feedback and insight into how the system is used by our client base. We hope that the changes we are making, and will continue to work on, show the effort to respect our users, encourage excitement in using the system, and provide better tools towards creating dynamic and impactful presentations for your customers and consumers.

Please reach out to sales@visionport.com for any questions about pricing and availability or visit www.visionport.com to learn more.

VisionPort: A Breakdown

2022-01-01T00:00:00+00:00

In late 2021, End Point Corporation’s immersive technology team officially launched VisionPort. Evolved from End Point’s Liquid Galaxy, VisionPort allows presenters to share content between embedded displays, managed devices, and wireless controllers, all from the tap of a finger. VisionPort was created to incorporate relevant conferencing and office technologies with a powerful and impactful video wall solution.

Unique to VisionPort is the method that allows for full-resolution applications — synchronized, with geometrically adjusted instances — regardless of the number of displays. This technique avoids the fish-eye distortion commonly seen on conventional video walls created by stretching content beyond its typical aspect ratio, and ensures that the highest quality content can be delivered to viewers.

The platform also integrates with other displays placed in the room, enabling users to control the experience of the visualizations presented for their participants.

A person acting as Meeting Director can both interact with and guide multiple inbound video streams via an intuitive interface on an iPad or other tablet controller. With the appropriate setup, directing someone’s laptop image to any screen in the room is as easy as swiping a video thumbnail into the appropriate square on the tablet.

Above is a conceptual rendering of how VisionPort can be integrated into a workspace. This rendering features:

The base VisionPort product, in this case outfitted with fourteen HD displays split into two rows of seven (although this could just as easily be one row of seven, two rows of five, or one single large screen).
Two additional side screens, integrated with the base VisionPort system and accessible via the CMS.
The SSI Kit incorporated on the left screen, sharing the left side’s laptop display content.
The VCI Kit incorporated on the right screen, sharing the video wall content to an active Zoom meeting, also featured on the right laptop.
Wireless controllers in the front of the room, in addition to an embedded touchscreen.
Other features not shown above include room audio and support for alternative control methods via USB.

While this particular implementation may seem extravagant, each individual part of the platform is modular, and can be included in the initial installation, or as an enhancement to an existing installation.

Our VisionPort platform combines custom server hardware with commercial displays and relevant conferencing technology to create the ideal cutting-edge conference room system for enterprises in commercial real estate, logistics, and travel, among other industries.

Central to VisionPort is End Point’s CMS (Content Management System), which enables clients to quickly and easily build multimedia presentations for the platform, and End Point’s excellent 24×7 support.

VisionPort’s system architecture is based in Linux and ROS (Robot Operating System), and provides a fundamentally secure, stable, and flexible environment for organizations seeking to display geospatial data sets in a concise and interactive manner. Research universities, multimedia studios, and data laboratories are also well positioned to fully leverage VisionPort, as it allows for multiple data sources and visualization streams to be viewed simultaneously. Museums, aquariums, and science centers use VisionPort to wow their visitors, combining immersive video with interactive displays that surround the guests in a data-immersive environment.

VisionPort is a huge step forward in End Point’s mission to create the ideal platform for shared immersive presentations, and our team put in a great effort to bring this to life. We are proud to announce that VisionPort is ready for deployment. For more information, contact sales@visionport.com or visit www.visionport.com.

VisionPort Success at Auburn University

2021-12-24T00:00:00+00:00

Auburn University’s Liquid Galaxy/VisionPort installation was the first of its kind, built into a stunning wooden cabinet. A technological showpiece that is a highlight of Auburn’s campus, the VisionPort platform is used to showcase incredible imagery and presentations created by students and faculty alike.

Auburn’s Liquid Galaxy/VisionPort is located on the first floor of the RBD (Ralph Brown Draughon) Library. As stated on Auburn’s Library webpage, “It provides a one-of-a-kind platform for 3D geospatial visualization, panoramic images, video, tours, and more in a shared immersive environment. Auburn holds the distinction of being one of the few institutions in the Southeast to make this unique and innovative resource available to its patrons.”

Chris Mixon is Auburn University’s Information Technology Specialist in the Media & Digital Resource Lab. He works closely with University groups to develop content, and also works with End Point’s support team as needs arise. As Chris has shared, “we are doing great things with this platform!” Among other projects, Chris is working with instructors and students in Urban Design Studio (CPLN 7200) and Science Communication (ESSI 7150) to display their work on the VisionPort platform.

Auburn University’s Liquid Galaxy/VisionPort is also used for Creative Explorations in Technology and Design programs geared toward 7th–11th graders. This program is focused on increasing digital literacy and building valuable technical skills as these middle and high school students prepare for the next stage of their lives.

A Liquid Galaxy/VisionPort exhibit honoring native Alabama author and educator Dr. Wade Hall by Auburn University Libraries’ Special Collections and Archives Department.

We look forward to continuing to support Auburn University in leveraging the VisionPort platform for great educational uses.

To learn more about VisionPort/Liquid Galaxy installations in custom cabinets, flat floor-mounted grids, two rows of screens, and other unique configurations, see my earlier article Custom cabinets for the Liquid Galaxy.

Read more about VisionPort in general at www.visionport.com.

From Liquid Galaxy to VisionPort

2021-11-23T00:00:00+00:00

We are rebranding! Meet the future of Liquid Galaxy: VisionPort.

We are proud to announce the official launch of VisionPort, the next phase for Liquid Galaxy. We have spent the past six months taking steps to rebrand, expand, and reposition our product to combine modern working necessities with the traditional kiosk-style, shared immersive experience familiar to our clients. Through these efforts have come a robust product encompassing an entire room of enhanced features, screens, and conference-enabling applications.

While our core product will remain consistent with what our clients know and love, current and future clients can look forward to significant updates to the content management system and user experience. We are also proud to announce advanced add-on features that will allow our current and future clients to make their systems more collaborative, interactive, and adaptable to their needs.

Our core offerings include:

Extensive preparation and customization of screens, servers, and frames
Google Earth, Cesium, Street View, etc.
Content Management System
Ongoing support service
Custom installation, system, and content consulting
Comprehensive system and content training

Our add-on offerings now include:

Video Conference Integration: Allows users to join video conferences or host meetings with a native, software-level view of the Liquid Galaxy.
Screen Share Integration: Allows users to share their content to the main displays. Supports sharing laptop, phone, or tablet’s presentation files and media to any screen on VisionPort.
Media Stream Integration: Allows users to share any HDMI video source onto any of the main displays on VisionPort.
Support for integrating all the above and the Content Management System with any additional side displays to complement the main screens.
VisionPort Remote: Full remote control of the content and camera view, intended for touch devices. Also supports remote view-only sharing.

All of these enhancements are detailed at our new website, www.visionport.com.

Please note that we also recently made a major domain change for our organization: Our new domain name is www.endpointdev.com — feel free to look through that site as well!

If you have any questions for us, please reach out to us at info@visionport.com.
For sales, sales@visionport.com.
For billing, billing@visionport.com.
For support, support@visionport.com.

In the same vein, all existing and future clients can now reach us at the www.visionport.com domain. Our team will be proactively reaching out to all of our clients to inform them of these changes, and will be available to answer any questions about the changes or upgrades available.

We are very excited about these new advancements, offerings, and rebranding opportunities. We look forward to engagement with current and future clients alike.

Liquid Galaxy Media Stream Integration

2021-11-11T00:00:00+00:00

End Point’s Immersive and Geospatial Division is proud to announce the rollout of our new Media Stream Integration as an extension to the Liquid Galaxy platform’s capabilities. This additional hardware can be added to existing installations or included in a new solution provided by our sales team.

The Media Stream Integration (“MSI”) is a collection of hardware additions to the Liquid Galaxy that allows a user to stream from any HDMI capable device in up to a 4k (3840×2160 pixels) window on the main displays of the system.

With the MSI, a user can connect and share any media source directly to the system through the touchscreen. Examples include a video game console, cable TV box, DVR device, laptop or desktop computer, Plex server, and more. In other words, users can showcase media content that may not be natively supported on the Liquid Galaxy platform.

How it works

A user simply ensures that the device is on, and it will appear as an option to share to the Liquid Galaxy screens on the touchscreen. The stream can be overlaid on top of existing content in pre-defined windows on the display wall through which the content will be displayed. When finished, the overlay window can be removed at any time.

Why we created this

We recognize the value offered in having an impressive, high-resolution display wall, and are often asked during an installation, “Can we watch the game on those screens?” In an effort to expand the flexibility of the system, we asked ourselves, “Why not?” As a dynamic presentation system, we want to equip our clients with all the tools necessary to share their stories, including supporting external content on the system.

Who this benefits

This is useful to anyone looking for a way to share content from a device not natively supported by the system. We are always looking for new ways to interact with the system and build content, and would love to hear your ideas.

If you are an existing client and have any questions about this new capability, or if you are considering a Liquid Galaxy platform for your organization and would like to learn more, please contact us!

New Jersey Liquid Galaxy Installation

2021-11-10T00:00:00+00:00

End Point Dev installed a Liquid Galaxy system at the New Jersey office of one of our clients this past March. This marks the fifth office that our client is using to showcase a Liquid Galaxy, joining offices in 4 other states. This new seven-screen Liquid Galaxy system is built into a conference room wall, and will be used as a technological showpiece to allow their team and clients to view different locations, information, and datasets in an immersive and interactive environment.

As our team is headquartered in New York City, this was a relatively local installation. Our End Point Dev engineers initially spent three days installing this system at the client’s new office; however, due to unforeseen circumstances there were a couple of return trips made to finalize details and ensure the best possible product. We also provided one day of on-site system training, walking the team through using the system and creating presentations with the Content Management System.

All Liquid Galaxy content for this client has been prepared by their global marketing team, who build region-focused content for each of the different Liquid Galaxy systems. The team effectively builds interactive content that allows their staff to home in on geographic locations and share in-depth research and datasets on their seven-screen systems.

Our client has seen great success with its growing fleet of Liquid Galaxy systems. They compare the Liquid Galaxy to being in a helicopter, due to the ability to zoom in and look at real estate properties of interest.

Our client’s in-house research team also effectively uses Liquid Galaxy to visualize opportunities and trends. The team combines information from their industry dataset, with insights from daily dialogue with leaders in manufacturing and distribution.

While our client often uses Liquid Galaxy in dedicated conference rooms specifically designed to house and experience the system, they have also found success in using the platform for portable use in exhibits and trade fair expo booths.

To learn more about Liquid Galaxy, please visit our VisionPort website.

Liquid Galaxy Hackathon 2021

2021-10-02T00:00:00+00:00

A few months ago we had our first company gathering since the pandemic started. About 20 End Pointers came to our New York City office to work on various Liquid Galaxy projects, and for several of us, to meet each other in person for the first time.

Except for our NYC-based team, this was everyone’s first look at the “new” office; we moved offices in January of 2020, so COVID-19 shut down about 14 months of office use.

Our CMS team worked on some exciting updates to our Liquid Galaxy CMS, including implementing new and improved techonologies for the database and user interface.

The CMS team: Zed, Dan, and Jeff

Our Research and Development team worked on upgrades to the Liquid Galaxy itself, focusing on creating smoother transitions for multimedia presentations. This included a custom window manager created by Matt, dubbed “Matt WM” by the team.

Will, Matt, Jacob, and Neil, hard at work

Our support team worked on spinning up documentation and data entry to bring our inventory up to date and prepare for the next wave of installations.

Darius hacking away

It was great to see everyone at the NYC office, working elbow to elbow. We saw plenty of the hard work and camaraderie which is End Point’s speciality. Until next time, we will continue to improve the Liquid Galaxy remotely!

Liquid Galaxy Screen Share Integration

2021-09-29T00:00:00+00:00

End Point’s Immersive and Geospatial Division is proud to announce the rollout of our new Screen Share Integration as an extension to the Liquid Galaxy platform’s capabilities. The additional hardware and software configuration can be added to existing installations or included in a solution provided by our sales team.

Screen Share Integration uses ClickShare, a well-regarded enterprise-grade wireless screen sharing tool already used in the offices of many of our commercial real estate clients. With Screen Share Integration you can push a button to share laptop, desktop, phone, and tablet content directly onto the displays of the Liquid Galaxy or onto an integrated side screen. We expect this to be useful for clients who are interested in sharing videos, spreadsheets, and other ad-hoc interactive media directly from their devices to supplement the main content on screen.

Why we created this

In an effort to expand the flexibility of the Liquid Galaxy platform, we thought about what tools our current clients are already using. We acknowledge that there are limitations to the interactivity of certain content types on the platform, and ClickShare is a useful tool for wireless sharing already used by our clients. Recognizing the value in supporting more interactivity with content sources and expanding on the possibility of what can be presented on the system, we invested in this feature to provide more options to our users.

Who this benefits

Any client wishing that they could share and interact with data or media from other sources can now seamlessly integrate these media streams onto the Liquid Galaxy mid-presentation, easily enabling and disabling the share as they go through their presentation.

How it works

Clients can use a USB-enabled single button device or an application compatible with iOS, Android, Windows, or macOS devices to share the content to their Liquid Galaxy. Using the touchscreen, the user can then place their content onto the main displays in pre-defined windows, seamlessly overlaid on the Liquid Galaxy.

If you are an existing client and have any questions about this new capability, please email or call us! If you are considering a Liquid Galaxy platform for your organization and would like to learn more, please contact us.

Introducing VisionPort Remote

2021-09-17T00:00:00+00:00

Welcome to End Point Liquid Galaxy’s new VisionPort Remote! This application not only allows the user to show their content on screen, but also gives control over Google Earth navigation through a number of touch actions. In addition to serving as a remote touchscreen of the system, Remote doubles as a portal that creators can use to test their content from their own devices. A new feature of Remote permits a shareable “guest view” allowing the presentation host to show their content without the possibility of a guest intervening.

Note: This interface layout is not final.

Why we created this

The COVID-19 pandemic increased the need for remote work, content, and presentations. Prior to the pandemic, the only way to use the Liquid Galaxy system was if you were in front of the display. The VisionPort Remote provides more flexibility and an ability to experience the system’s benefits from all over the world.

Who this benefits

The VisionPort remote helps content creators visualize the content that they are making without needing to be in front of the system, enables hands-free control of the Liquid Galaxy from any device, and allows for remote sharing of content to viewers who do not have easy access to a Liquid Galaxy but still want to experience the immersive environment.

How it works

The host of Remote holds control of the system and presentation, allowing others to view but not affect the Liquid Galaxy.

The “Earth preview” displays a live view of content that is being displayed on the Liquid Galaxy, and gives the presenter the ability to navigate the map as one normally would with the SpaceNav, the 3D joystick which supports easy motion in all directions.

The lower portion of the interface controls the presentation and scene. Scenes, presentations and playlists can be selected to be displayed on the Liquid Galaxy as well as within the preview window.

To the left of the scene controls is a window with preview display modes. These buttons will show a zoomed-in portion of the displays for a better view of their content. By default, wall is selected and shows an entire view of a presentation, as it would be displayed against the 7 screen wall. The other options show a view of the selected section.

The share button in the top right corner features a view-only option for the guest viewing the presentation. The guest only has the option to view the different preview display modes as they are presented. Press the share button, copy the link, and send it to your intended audience.

If you have any questions please reach out to us!

Solving High-Resolution Video Stutter with GStreamer Hardware Acceleration

The System: A GStreamer Pipeline

First Instinct: The Encoding

Hardware Decoding, Take One

The Real Culprit: Rendering, Not Decoding

Putting the Pieces Together

Beyond One Engagement: Broader Implications

Working with End Point

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

Custom data & styling

Demo

Converting MIDI to KML using AI: Bach’s Notes in the Hills of Greenland

How to try out the application

Issues

Using AI for blog post image processing

Place Labels in Cesium using Vector Data Tiles

Challenges of Vector Data in Cesium

Technical Implementation

Managing Uneven Label Distribution

Clustering Labels

Next Steps

Notes

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

An OpenStreetMap Editor for Adding Public Transit Data Using GTFS

My OpenStreetMap editor for GTFS data

How to use the app

Adding stops to OSM

Demo videos

An important note

Making a Loading Spinner with tkinter

Prerequisites

Code

Resources

Compressed CZML

VisionPort: The Future of Tourism Marketing

Showcase destinations

Display a multitude of media

Marketing

Conclusion

Cesium Labels

Backend and data source

Future Plans

Running On Your System

Tennessee Hackathon 2023

End Point Tennessee office (EPTN)

Casablanca

Pigeon

Birthdays, dinner, and farewell

University of Denver and VisionPort: The Classroom of the 21st Century

Kansas State University: One Year with VisionPort

Interview

End Point Dev: How has VisionPort aided the evolution of the Hale Library?

What types of presentations have students and faculty been creating with VisionPort?

What are some ways in which Google Earth is being utilized with VisionPort?

What content on the VisionPort have students been most excited about?

What fields of study are being presented most frequently?

How are panoramic images being used on the VisionPort?

Conclusion

Auburn University and VisionPort: How the World Gets Its Water

VisionPort at University of Tokyo, New York office: An Exhibition for Peace on August 6th and 7th

Job opening: VisionPort support engineer (western U.S.)

Overview

Core responsibilities

Preferred skills and experience

What work here offers:

About End Point

Get in touch with us

VisionPort Hardware Overview

The `ogr2ogr` `-sql` option