Building an Interactive 3D Globe: Architecture, Rendering, and Spatial Data Challenges

Rendering the Earth is relatively simple today. Libraries give you a sphere, a basemap, and even terrain almost out of the box. The hard part starts when you add your own data. That might be thousands of polygons, large raster files, or several analytical layers that all need to respond when someone zooms from orbit down to a single field. Rendering that data at a useful speed and scale is where most projects struggle, and it is where I spend most of my time on these products.

A 3D globe can quickly become a performance problem. The browser has more geometry to draw, more tiles to request, and more work to hand to the GPU than on a flat map. On a powerful development machine, everything feels smooth. On an average laptop or a phone, it can fall apart.

In this article, I will walk you through how I approach building an interactive 3D globe: the architecture, the rendering engine, data preparation, tiling, interaction design, and the performance traps I try to avoid from day one. If you are planning a product like this and want a team that has done it before, you can also look at our GIS software development services.

What Does an Interactive 3D Globe Require?

An interactive 3D globe is a small system, not just a map with a different projection. A proper 3D GIS visualization requires:

• A globe-capable renderer. This is the engine that draws the Earth and your layers in 3D
• Prepared spatial datasets.
• Tiled delivery with levels of detail (LOD). The globe should load only what the camera can see, at the detail that makes sense for that distance.
• Terrain and a basemap. These give people a sense of place, so they always know where they are on the planet.
• A data-loading strategy.
• An interaction layer. Camera moves, hover, selection, filters, and drawing tools turn a nice picture into a working tool.
• Backend and data APIs. Someone has to serve the tiles, run the queries, and handle access.
• Caching. Anything that gets requested twice should not be calculated or downloaded twice.
• Performance monitoring. Problems are much cheaper to fix when you see them early.

If one of these is missing, the globe usually still works at first. Then the dataset grows, and the missing piece shows up as lag, long waits, or a crashed tab. In the rest of the article, I will go through each of these in more detail.

What Is an Interactive 3D Globe?

People use 3D globe for several different things. Here are the four ideas I separate before any technical talk.

	Flat web map	Globe projection	Terrain-enabled map	Full 3D geospatial scene
What it is	Earth projected onto a flat surface, usually Web Mercator	The same kind of map wrapped onto a sphere	A map with elevation, so mountains rise and valleys drop	Globe, terrain, imagery, and true 3D content placed accurately on the planet
User can	Pan and zoom	Spin the planet and compare regions	Tilt the camera and look across a landscape	Move through the scene
Main strength	Fast, familiar, easy to build	True-to-life shapes and distances at world scale	A real feel for the ground	Maximum realism and spatial context
Main weakness	Distortion at high latitudes	Looks different, but often not much more informative for local work	Extra elevation data to load	Heavy data, needs streaming and LOD
Typical effort	Low	Low to medium	Medium	High

A quick example of why the projection matters: Web Mercator makes Greenland look about as large as Africa. In reality, Africa is roughly 14 times bigger. For local work, this rarely matters. For global comparisons, it can mislead your users.

What each level needs from your team

Flat web map

• Standard tiles and a web mapping library
• Small team, short timeline

Globe projection

• A renderer with globe support
• Testing of labels and layers at world scale

Terrain-enabled map

• Elevation data source
• Extra performance testing on mobile

Full 3D scene

• 3D asset pipeline and hierarchical tiling
• Backend built for streaming
• Clear budget for data preparation

When Is a 3D Globe Better Than a 2D Map?

This is the question I ask first in almost every project, because the answer is often It depends on what your users do all day. A globe can be the right choice, but it is not an upgrade over a flat map. It is a different tool with different strengths.

My position: Do not choose a globe only because it looks impressive. Choose it when the shape of the Earth, the height of the ground, or the global scale of your data helps your users make better decisions.

Requirement	2D map	3D globe
Local operations (parcels, routes, street-level editing, measuring)	Strong. Precise, fast, familiar controls	Weaker. Camera tilt and perspective make precise clicking and editing harder
Global data (shipping, climate, satellite coverage, worldwide assets)	Limited. Distortion at high latitudes, and the map “breaks” at the edges	Strong. Shapes, distances, and routes look true at world scale
Terrain and elevation	Partial. Hillshade or contours give a hint of height	Strong. Real relief, camera tilt, and line of sight
Buildings and 3D assets	Limited. Simple extrusions at best	Strong. Accurate placement of buildings, infrastructure, and models
Large-scale spatial context (seeing how a site relates to the region or planet)	Medium. Needs zooming out and mental stitching	Strong. Users move from orbit to site in one continuous motion
Complexity (build effort, data volume, device requirements)	Low to medium	Medium to high

Reference Architecture for an Interactive 3D Globe

Here is the geospatial visualization architecture we at SpdLoad use as a starting point when working on GIS 3D visualization projects:

1. Spatial sources

This is everything your globe will show, in whatever shape it arrives.

Source type	Examples
Vector	Boundaries, parcels, roads, assets, sensor locations
Raster	Satellite scenes, land cover, climate grids
Terrain	Elevation models
Imagery	Aerial and satellite basemap imagery
3D assets	Buildings, infrastructure models, point clouds

Sources are rarely consistent. Formats, coordinate systems, and quality differ. I treat this layer as raw material and never as something to send straight to the browser.

2. Processing and tiling

This is where most of the performance work happens, and it is the layer teams skip most often. Here the data is cleaned, simplified, reprojected, cut into tiles, and given several levels of detail. A far-away camera gets a coarse version. A close camera gets a precise one.

3. Spatial storage and tile storage

Processed data needs a home that matches how it will be used.

• A spatial database holds data you need to query, such as “all assets inside this area.”
• Object storage holds pre-built tiles that are simply fetched by address.

Using both is common. Queries go to the database, and anything that does not change often goes to tile storage, which is cheaper and faster to serve.

4. API, tile delivery, and CDN

This layer connects storage to the browser. It handles queries, authentication, and caching, and it delivers tiles from servers close to the user through a CDN. Clean contracts matter here, especially when several systems feed the same globe. If your globe pulls from external services or internal platforms, this is where good API integration services save a lot of pain later.

5. 3D rendering engine

The engine turns tiles and data into pixels. It manages the camera, the sphere, terrain, and layers. Mapbox GL JS and CesiumJS are the two most common choices, and I compare them in the next section. What matters here is that the engine is only as good as what it receives from layers 1 to 4.

6. Interaction layer

This layer turns a view into a tool. It includes camera controls, filters, hover, selection, and drawing areas of interest. It sits between the engine and the interface, and it should be designed on purpose. A globe with poor interaction feels like a screensaver.

7. Application UI

The part users actually touch: side panels, search, analytics, and workflows. Many products need a custom interface here, because the globe is only one part of the experience. If that is your case, our custom web development services cover this layer.

Quick reference: who owns what

Layer	Main question it answers	Typical owner
Spatial sources	What data do we have, and how good is it?	GIS / data team
Processing & tiling	How do we make it light enough?	GIS / data engineers
Storage	Where does it live, and how is it queried?	Backend / data engineers
API / CDN	How does it reach the browser quickly?	Backend / DevOps
Rendering engine	How is it drawn in 3D?	Front-end / graphics engineers
Interaction layer	How do users explore it?	Front-end + UX
Application UI	How does it fit their workflow?	Front-end + product

Choosing the Rendering Engine

Teams often ask me for a verdict: Cesium or Mapbox, which one wins?

I try not to answer it that way. Both are mature, and both can run a good globe. The better question is which one fits the product you are building. This section gives you the short version. For the full stack picture, we cover it in our guide to the GIS tech stack.

	Mapbox GL JS	CesiumJS	Embedded / managed platforms
Best known for	Interactive web maps with globe and terrain	Full 3D geospatial scenes	Fast delivery of shareable maps
3D role in the product	Complements a broader map UI	Core to the product	Limited, depends on the platform
Terrain and 3D content	3D terrain and globe projection	Terrain, imagery, 3D Tiles, glTF models	Varies
Control over rendering	Medium	High	Low
Typical effort	Low to medium	Medium to high	Low

Preparing Data for 3D Geospatial Visualization

Of all the steps in building a globe, this is the one I would protect first when a budget gets tight. The data is usually the real bottleneck.

Why you should not push raw files into the browser

It is tempting. You have a GeoJSON file or a large raster, the library can read it, and the first test works. The trouble shows up as the data grows. Here is what happens to a raw file in the browser:

Raw input	What the browser has to do	What the user feels
Large GeoJSON	Download the full file, parse it, and convert it to drawable geometry on the user’s device	A long wait, then a frozen tab
Large raster file	Download far more pixels than the screen can show	Slow loads, high memory use, crashes on phones
Detailed polygons	Draw many more vertices than the eye can see from orbit	Low frame rate while rotating
Unused attributes	Download and store fields nobody looks at	Heavier files for no benefit

This is not only my experience. Mapbox’s documentation on large GeoJSON explains how its GeoJSON sources work: the tiling is done by the client, in the web browser or on a mobile device, not on a server. So a bigger file means more work on every visitor’s device.

 

Foursquare’s documentation gives a sense of the scale: tables of about a million points, or under 250 MB, typically load and render smoothly, but the limit depends on the device, and a mobile device can load significantly less than a laptop. Past that point, it points to tiles, database queries, and preprocessing.

A real example of how much a bit of cleanup helps: in Mapbox’s large-data guide, removing unused properties and limiting coordinates to six decimals took a 19.3 MB file down to 3.3 MB, and the map rendered more smoothly. Your results will depend on your data.

Data preparation steps

Think of preparation as a funnel. Raw data goes in at the top, and only what the user needs reaches the screen.

Raw data  →  Clean  →  Simplify  →  Aggregate  →  Select attributes  →  Tile + LOD  →  Serve

1. Preprocessing

First, make the data consistent. That means fixing invalid geometries, aligning coordinate systems, removing duplicates, and checking formats. It is not exciting work, but errors found here cost minutes. Errors found in the browser cost days.

2. Simplification

From orbit, nobody can see a coastline drawn with a million points. Simplification reduces the number of vertices while keeping the shape recognizable. Mapbox notes that its simplification option implements the Douglas–Peucker algorithm and can be used to improve performance. The rule I follow is simple: the further the camera, the fewer vertices you need.

3. Feature aggregation

Ten thousand points in one city look like a blob at world scale. Instead of drawing them all, group them. At low zoom, the user sees clusters or grids with counts. At high zoom, the individual features appear. This keeps the picture readable and the browser calm.

4. Relevant attribute selection

Every field you send costs bandwidth and memory. Ask a blunt question for each attribute: does the screen need this to draw, filter, or show a tooltip? If not, it stays on the server and is fetched only when a user clicks a feature.

5. Tiling

Tiling cuts the data into small pieces, so the browser asks only for the pieces that cover the current view. MapLibre’s large-data guide recommends this approach: convert GeoJSON to vector tiles, which are designed for efficient rendering. For imagery and analytical rasters, the same idea applies with raster tiles.

6. Level of detail (LOD)

LOD means every tile exists at several resolutions. A far camera gets a light version, a close camera gets a detailed one.

7. Server-side filtering

Some questions should never reach the browser as raw data. Show assets inside this area or Show only layers this user can access are better answered by the server. Foursquare lists this as one of its main options for big data: store large datasets in databases, and load partial data via queries.

Which technique solves which problem

Problem	Technique
File is too large to download quickly	Simplify, trim attributes, tile
Too many features at world scale	Aggregate or cluster
Too many vertices per feature	Simplify by zoom level
Browser loads areas nobody is looking at	Tile and request by view
Users see data they should not	Filter on the server
Imagery is too heavy	Raster tiles with several resolutions

How 3D Tiles and Level of Detail Solve Scale

Once your data is prepared, the next question is how to deliver it. Here is the idea that makes large-scale GIS visualization possible: The browser should never try to hold the whole world. It should hold only what the user can see right now, at the detail that makes sense for that view.

Think of how you use a paper atlas. You start with a page showing the whole world. When you need a city, you open a different page with a city plan. You do not carry a street-level map of every country in your bag. Tiles and level of detail (LOD) work the same way in software.

The four ideas behind it

Idea	What it means	Why it helps
Hierarchical tiles	Data is cut into pieces and arranged as a tree. Big, rough tiles sit at the top. Smaller, more detailed tiles sit below them	The browser can start with a quick overview and add detail only where needed
Load what is visible	The engine requests only the tiles inside the camera’s view	No time wasted on the other side of the planet
Match detail to distance	A far camera uses coarse tiles. A close camera swaps in finer ones	The screen shows roughly the same number of details at every zoom level
Unload what is not needed	Tiles that move out of view are removed from memory	Memory stays stable during long sessions

How a zoom works

Camera at orbit      →   a few coarse tiles cover the planet
        ↓
Camera over a region →   coarse tiles are replaced by finer ones, only in view
        ↓
Camera over a field  →   very detailed tiles load for a small area
        ↓
Camera moves away    →   detailed tiles are unloaded, coarse ones remain

The user sees one smooth move from space to ground. Behind the scenes, the engine is constantly asking: is this tile detailed enough for the current view? If not, load its children.

Where 3D Tiles fits in

The same logic works for flat map tiles, terrain, and imagery. For true 3D content, the open standard is 3D Tiles. The OGC describes it as a standard designed for streaming and rendering massive 3D geospatial content, such as photogrammetry, 3D buildings, BIM/CAD, instanced features, and point clouds, using a hierarchical data structure and a set of tile formats that deliver renderable content.

The detail I find most useful to explain to clients is how the tree works. In the specification, tiles are structured into a tree with hierarchical level of detail, so a client decides at runtime whether a tile is detailed enough, or whether its content should be refined by child tiles of higher resolution. That is the “open the next page of the atlas” step, written as a rule.

What this means for a product

Without tiles and LOD	With tiles and LOD
The load time grows with the size of the dataset	The load time depends on what is on screen
Memory use climbs the longer people explore	Memory use stays within a predictable range
Phones and older laptops struggle first	Weaker devices can still show a useful view
Adding a new dataset can slow everything down	New datasets are added as new tile sets

My rule of thumb: if a dataset can grow, plan for tiles from the beginning. Adding them later usually means redoing the data pipeline, not just changing a setting.

Terrain, Imagery, and Vector Layers

A good globe is rarely one dataset. It is a stack of layers that must work together, and the order of that stack decides whether people understand the picture or just see a busy sphere. I think of it like a stage: the ground is built first, and the actors come in on top.

What a globe usually combines

Layer	What it gives the user	Typical form
Basemap	Geographic context: coastlines, borders, place names	Vector or raster tiles
Imagery	A realistic view of the surface	Satellite or aerial raster tiles
Elevation / terrain	Real relief: mountains, valleys, slopes	Tiled elevation data
Polygons	Areas: parcels, regions, zones, protected sites	Vector tiles
Lines	Movement and connections: routes, rivers, pipelines, boundaries	Vector tiles
Points	Specific places: assets, sensors, events	Vector tiles or clustered features
Analytical layers	Results the user needs to act on: risk, change, density, scores	Raster tiles, vector tiles, or precomputed grids

How the layers stack

        ┌───────────────────────────────────┐
  TOP   │ Labels and UI highlights          │  hover, selection, place names
        ├───────────────────────────────────┤
        │ Points                            │  assets, events, sensors
        ├───────────────────────────────────┤
        │ Lines                             │  routes, networks, boundaries
        ├───────────────────────────────────┤
        │ Polygons                          │  zones, parcels, regions
        ├───────────────────────────────────┤
        │ Analytical layers                 │  heatmaps, scores, change
        ├───────────────────────────────────┤
        │ Imagery or basemap                │  context of the surface
        ├───────────────────────────────────┤
 BOTTOM │ Terrain                           │  elevation under everything
        └───────────────────────────────────┘

Terrain sits at the bottom because everything else is draped over it. Imagery and basemap come next. Your own data goes on top, with the smallest and most clickable items closest to the user’s eye.

Terrain and imagery: the foundation

Terrain is often the first thing that makes a globe feel real. Both main engines support it. Mapbox lets you add 3D terrain on both Globe and Mercator projections. CesiumJS lets you view terrain features and stream your own tiled terrain data. Imagery is handled the same way, as tiles that load by view and detail.

Two practical points from our projects:

• Terrain is a cost, not only a feature. Elevation data adds requests and GPU work. If your users work on flat land or at one location, check whether terrain adds value before turning it on.
• Exaggeration should be deliberate. Stretching the height can make slopes easier to read, but it also distorts. If users make decisions based on slope or height, keep it honest or label it clearly.

Vector layers: polygons, lines, and points

Each geometry type has a different job, and a different way to go wrong.

Geometry	Works well for	Common problem	What I do
Polygons	Showing where something is, and how big	Heavy outlines and overlapping fills hide the surface	Light fills, thin outlines, transparency
Lines	Showing connections and flows	Too many lines become a tangle	Simplify, filter by importance, show more at close zoom
Points	Showing exact places	Thousands of points become a blob	Cluster at low zoom, individual points at high zoom

Analytical layers: the reason many people open the globe

Analytical layers carry the answer the user came for: a risk score, a change over time, a density map. They are also the layers most likely to be heavy. My approach is to compute results on the server when possible and send them as tiles, so the browser only draws. I come back to this in the performance section.

The rules we follow when arranging a stack:

1. Put the most important layer closest to the eye. If the story is “where is the risk,” the risk layer should never sit under a busy imagery layer.
2. Let the background step back. Basemap and imagery should support the data, not compete with it. Muted colors and lower contrast help.
3. Use color with meaning. One color scale per idea. If red means risk in one layer, it should not mean “forest” in another.
4. Control opacity. Semi-transparent polygons let terrain and imagery show through, so users keep their sense of place.
5. Show less at a distance. From orbit, show regional patterns. Add detail as the camera gets closer.
6. Keep labels last, and few. Labels are the first thing to clutter a globe. Show them only when they help.

Designing User Interaction on a Globe

A globe can look impressive and still be frustrating to use. Interaction design is what turns a nice picture into a tool people trust. The main idea to follow is simple: on a globe, the user should never feel lost.

         ┌────────────────────────────┐
         │       APPLICATION UI       │  panels, search, workflows
         └──────────────┬─────────────┘
                        │
         ┌──────────────┴─────────────┐
         │     INTERACTION LAYER      │
         │                            │
         │  Navigate   Find   Inspect │
         │  camera     search hover   │
         │  limits     filters select │
         │             layers  draw   │
         └──────────────┬─────────────┘
                        │
         ┌──────────────┴─────────────┐
         │      RENDERING ENGINE      │
         └────────────────────────────┘

At SpdLoad, we group the work into three jobs: navigate (move around), find (reach what matters), and inspect (understand and act on it). Let’s go through each.

Job 1: Navigate

Camera controls

A globe adds rotation and tilt to the usual pan and zoom, which gives users more ways to get confused. My defaults:

• Keep controls consistent with what people already know from other map tools
• Offer a clear way to reset: north up, default view, or “back to my project”
• Use smooth fly-to transitions when jumping between places, so users follow where they went
• On touch devices, make sure rotation, tilt, and zoom gestures do not fight each other

Zoom boundaries

Free zoom sounds friendly, but it lets people fly into space or underground. I set limits on purpose:

Limit	Why it matters
Maximum distance	Stops users from drifting so far that the globe becomes a dot
Minimum distance	Keeps the camera above terrain and stops zooming past the detail you have
Tilt range	Prevents views that show nothing useful or break the illusion
Data-aware zoom	If your data only exists to a certain detail, don’t invite users to go further

Job 2: Find

Search

Search is the fastest way to remove the “I’m lost” feeling. People should be able to type a place, a project name, or a coordinate, and the camera should take them there. We connect search to the user’s own data as well, not only to place names. In a product, “Field 12” is often more useful than “Kyiv.”

Filters

Filters reduce what is drawn, which helps both clarity and speed. Where possible, we apply them on the server, so the browser doesn’t download data it will immediately hide.

Layer visibility

Users need control over what they see, but a list of 40 toggles is not control, it is a chore. What works better:

• Group layers by topic (for example, “Risk,” “Land use,” “Boundaries”)
• Turn on a small default set
• Show a short legend for every visible layer
• Make it obvious when a layer is loading or unavailable at this zoom level

Job 3: Inspect

Hover, click, and selection

These three actions are often mixed up. We separate them:

Action	Purpose	Good practice
Hover	Quick preview	Highlight the feature and show a very short label. Keep it light, since hover runs often
Click	Ask for more	Open details in a panel or card
Selection	Keep an item in focus	Keep the highlight and let users compare or act on it

On touch devices, hover does not exist, so every important preview must also work with a tap.

Drawing areas of interest

Many analytical products start with “draw the area you care about.” This is one of the most powerful interactions on a globe, and one of the easiest to get wrong. What we plan for:

• Simple tools: polygon, rectangle, and circle, with clear start and finish actions
• Ways to edit or delete a shape, and to undo
• Visible area size, so users know what they drew
• Limits on size or complexity, with a message that explains why
• Support for uploading coordinates or files, for people who already have their boundaries

Precision on a tilted sphere is harder than on a flat map. For drawing, we often suggest a top-down camera, so users can place points accurately.

Side panels

Panels hold the detail that doesn’t fit on the globe: attributes, charts, and actions. Keep them narrow enough that the globe remains visible, and let users collapse them. When a panel covers half the screen, the sense of place disappears.

Tooltip density

Tooltips are the first thing to turn into clutter. Our rules:

• Show 3 to 5 facts at most, the ones people need first
• Put the rest in the side panel
• Never show multiple tooltips at once on small screens
• Avoid tooltips that follow the cursor over dense data, since they flicker and distract

Performance Challenges With Large Spatial Data

Performance is the topic I get pulled into most often, usually after launch. The globe worked in the demo, then real data arrived, and now it stutters. The good news is that the causes repeat from project to project, so they can be spotted early. The better news is that most fixes are not about the renderer at all.

Challenge	What it looks like	Why it happens
Too many browser-side features	Slow start, laggy rotation	The browser must parse, store, and draw every feature it receives
Excessive geometry complexity	Low frame rate, even with few features	Detailed outlines with huge vertex counts are drawn even when they look like a dot
Massive uploads	Long waits, crashed tabs	Users upload large files, and the system tries to show them as they are
Loading invisible features	Wasted bandwidth and memory	The app requests data for areas, zoom levels, or layers nobody can see
Too many layers	Slow rendering, heavy styling	Each layer adds drawing work on every frame
Repeated API requests	Flickering, slow updates, high server cost	The same data is requested again on every pan, zoom, or click
Expensive client calculations	Freezing during filters or analysis	Heavy math runs on the user’s device and blocks the screen
GPU limitations	Dropped frames, visual glitches	Terrain, imagery, and 3D content all compete for graphics memory
Mobile devices	Works on desktop, fails on phones	Less memory, weaker GPUs, and slower networks

Mapbox’s own performance guide points to the same root causes. It advises looking for ways to reduce the number of layers, the number of sources, or the complexity of the features being rendered. It also explains why tiling helps: the renderer splits vector tilesets into tiles, so GL JS loads only the features that are visible on the map.

How the problems connect

Too much data  ──►  Heavy downloads  ──►  Slow first view
      │
      ▼
Too many features ──► Heavy rendering ──►  Low frame rate
      │
      ▼
Too many requests ──► Server load     ──►  Delays and higher cost

Most issues come from one habit: sending more than the screen needs. That is why most solutions fall into one family: send less, and send it smarter.

Solutions

Solution	What it does	Problems it solves
Tiling	Cuts data into small pieces fetched by view	Too many features, massive uploads, invisible features
Level of detail (LOD)	Uses coarse data for far views and detailed data for close ones	Geometry complexity, GPU load, mobile limits
Viewport-based filtering and pagination	Requests only what falls inside the current view, in manageable batches	Invisible features, repeated requests
Caching	Stores results in the browser and on the server so they are not recomputed or re-downloaded	Repeated API requests, server cost
CDN	Delivers tiles from servers close to the user	Slow loads in distant regions
Precomputed results	Calculates heavy analytics ahead of time and serves the answer as tiles or values	Expensive client calculations, slow analysis
Server-side processing	Runs filtering, aggregation, and spatial queries where there is more power	Client freezes, large downloads

A quick prioritization guide

If you’re not sure where to start, this is the order we usually follow:

1. Measure first. Test on a real mid-range phone and a mid-range laptop.
2. Cut what is loaded. Tile data and request only what is in view.
3. Cut what is drawn. Simplify geometry and reduce the number of layers.
4. Move work off the device. Precompute and process on the server.
5. Cache what repeats. Use browser, CDN, and server caching.
6. Add a fallback. Show a lighter view when the device or network cannot keep up.

Real-World Example: A 3D Globe for Environmental Analytics

Everything I have described so far comes together in one project we built for a cloud-based platform that supports Nature-Based Solutions (NbS). It helps organizations, local communities, and experts plan environmental projects, such as restoring land or protecting natural resources, and turns map data on land use, soil, and water into clear insights. I will focus here on the visualization side. If you want the full story, you can read the 3D geospatial platform case study.

What the user does on the globe

The public case describes a simple flow. Users can create projects by drawing areas of interest on a 3D globe map or by uploading coordinate files. The system then checks which analytical layers exist at those coordinates and generates a project with detailed analytics.

Open the globe  →  Draw an area (or upload coordinates)  →  Layers are detected
        →  Project is created  →  Analytics for the selected region

That is the interaction design principle I described earlier in action: one clear starting action, and the system does the heavy lifting afterward.

How the visualization challenges map to this article

Challenge from the project	What it meant for visualization
Massive vector and raster files with dense data such as forest density and soil composition	Raw files could not go straight to the browser. They needed custom optimization before display
Layered data across global maps, with smooth switching between country and local views	Global-to-local navigation had to stay fast as the layers stacked up
Strict data access control for many companies	Each tenant could see only its own maps and datasets
Several technologies in one product: Azure, Felt, AI analytics	The globe, the backend, and the interface had to work as one experience

Felt as the visualization layer

Felt was integrated as the primary tool for displaying geospatial data on the frontend. The system creates a separate project for each region or country, so stakeholders explore data territory by territory through the 3D globe interface. This is a good example of a managed platform doing what it does best: delivering a polished, shareable map without building a renderer from scratch.

A custom atlas built with Mapbox

Alongside Felt, we built a fully customized map interface with Mapbox, with a tailored design and a flexible control panel. It allows users to:

• overlay Felt projects on top of custom layers
• work with GeoJSON files
• draw directly on the map
• upload massive files, including files over 1 GB

I like this combination because it avoids an either-or choice. The managed platform covers the standard exploration. The custom atlas covers what is specific to the product: custom design, drawing, and heavy uploads. If you are weighing this kind of decision, our Felt vs Mapbox comparison goes into the trade-offs.

Vector and raster data, prepared for the globe

Our team built a system to process vector and raster geodata and prepare it for visualization on a global map. This data includes high-resolution layers with environmental indicators such as forest density and soil composition. It is the same principle as in the data preparation section: the globe is only as good as the pipeline behind it.

Multi-tenant access

The platform is multi-tenant. Each company or organization gets access only to a limited set of maps and datasets, depending on its permissions, and an administrator controls data sharing and availability. On a globe, this matters more than it might seem. Access rules have to apply to what is drawn, not only to what is listed in a menu.

What users get in the end

Capability	Why it matters for the user
Drawing an area on the globe	Starting a project takes seconds, not a form
Automatic detection of analytical layers	No manual hunting for the right data
Territory-by-territory exploration	Clear structure from country to local level
Custom layers on top of shared projects	Teams can add their own context
Large file uploads	Real working files, not just samples
Permission-based maps	Clients trust that their data stays private

Common 3D Globe Architecture Mistakes

After enough projects, you start to see the same mistakes repeat. They rarely come from lack of skill. They come from decisions made early, when everything still looks fine in the demo. Here are the nine we see most often, and what to do about each one.

#	Mistake	What it causes	The fix
1	Choosing 3D before defining user value	A costly globe nobody needed	Start from user tasks, then choose the view
2	Rendering raw files directly	Slow loads, crashed tabs	Prepare, simplify, and tile first
3	No LOD strategy	Heavy rendering at every zoom level	Plan detail levels from the start
4	Processing everything client-side	Frozen screens on weaker devices	Move heavy work to the server
5	Loading all layers at launch	Long first load, no clear message	Load a small default set, add the rest on demand
6	Ignoring mobile GPU limits	Works on desktop, fails on phones	Test on mid-range phones from week one
7	Excessive labels	Cluttered globe, slower drawing	Show labels by zoom and priority
8	No fallback state	Blank screen when something fails	Design lighter and error states in advance
9	Treating visualization as separate from the data pipeline	Fixes at the wrong layer	Design data and display together

3D Globe Development Checklist

If you only keep one section of this article, I would pick this one. It is the order in which we work through a globe project, from the first question to the first release. Each step builds on the one before it, so skipping ahead usually means coming back later.

Step	What to do	Question to answer	Done when
1. Define the user value	List the tasks your users need to complete and the decisions the globe should support	What can people do here that a flat map cannot offer?	You can describe the value in one sentence
2. Choose the right view	Pick between a flat map, globe projection, terrain map, or full 3D scene, and choose a rendering engine that fits	Which level do users actually need?	The choice is based on tasks, not on looks
3. Audit your data	List every dataset: format, size, update frequency, quality, and who may see it	What do we have, how big is it, and how often does it change?	Every dataset has an owner and a known size
4. Prepare and tile the data	Clean, simplify, aggregate, trim attributes, and build tiles with levels of detail	What does the screen need, and nothing more?	No raw file reaches the browser
5. Design the interaction	Plan camera limits, search, filters, layer groups, hover and selection, and area drawing	Can a new user find and select a place in under a minute?	Navigation, search, and reset paths are defined
6. Build the architecture	Set up storage, APIs, CDN, caching, and access rules, then connect the renderer	Does every layer pass lighter data to the next one?	Data flows from source to screen without manual steps
7. Test on real devices	Check frame rate, load time, and memory on a mid-range phone and a mid-range laptop, with real data volumes	Does it stay smooth where most users are?	You meet your performance budget on the reference devices
8. Monitor and improve	Track load times, errors, and slow tiles in production, and plan for dataset growth	What will break when the data doubles?	Monitoring is live and someone owns it

Conclusion

Here are the main points to take with you:

Idea	Key point
Start with value	Choose a globe because users need global context, elevation, or 3D content, not because it looks impressive
Think in layers	A globe is a pipeline from source to screen, and each layer should make the next one lighter
Prepare before you render	Raw files should never go straight to the browser. Clean, simplify, aggregate, and tile first
Load only what is seen	Tiles and level of detail keep load time tied to the view, not to the size of the dataset
Design for orientation	Users should always know where they are and how to get back
Test where your users are	A mid-range phone is a better judge than a development laptop