You open a geo dataset and it's a GeoJSON file. Feels clean, readable, modern. Then you try to render ten million points on a map and your browser freezes. What happened? That's the question Daniel sent us. Let me read what he wrote.
He says — let's talk about some of the file standards for data visualization with a geographic element, geo data visualization. One of the first formats anyone delving into the space will come across is GeoJSON, which seems appealing, but given that geo visualization is often done at massive scale, the question is, how far can this format stretch? Geographic data is often also received in formats that are natively understood by mapping tools, like KMZ and others. He wants to look at where each of these formats shines for geo data visualization, interoperability, and format conversion.
Three questions in one prompt. Where does GeoJSON break, where does KMZ still win, and what's the real cost of moving between them.
And the answer to all three starts with the same uncomfortable truth — there is no one format. GeoJSON is not the best geo format. KMZ is not obsolete. Shapefile is not dead. What you pick depends entirely on what you're doing with the data.
So today we're going to stress-test the formats themselves. Not just which one is best, but where each one breaks, and how the conversion pipeline is the real skill.
Let's start with GeoJSON's design, because its strengths and weaknesses come from the same source. RFC 7946, standardized in August 2016 — that's the spec that locked GeoJSON into a single coordinate reference system, WGS 84, which is EPSG four three two six. Every coordinate is longitude then latitude, decimal degrees. The structure is clean — you've got Feature objects, each with a geometry and properties, bundled into a FeatureCollection. It's valid JSON. Any programming language can parse it. You can open it in a text editor and read the coordinates.
And that's exactly the trap.
It is. The thing that makes GeoJSON beautiful is also what makes it collapse at scale. JSON is a text format. Every single coordinate is written out as characters — a left bracket, a number with decimal places, a comma, another number, a right bracket. For a polygon with ten thousand vertices, that's twenty thousand floating-point numbers rendered as text. The file is enormous before you've even started.
How enormous are we talking?
Interline — the transit data company — they benchmarked this. A one point five gigabyte GeoJSON file takes roughly forty-five seconds just to parse in Node.js. That's before a single point appears on screen. The browser's JavaScript engine has to deserialize the entire JSON object into memory. You can't stream it, you can't peek at a subset, you can't start rendering until the whole thing is loaded and parsed.
Forty-five seconds of blank screen. And that's assuming the browser tab doesn't crash first.
Right. The memory blowup is the real killer. JSON parsing creates a full in-memory object graph — every coordinate becomes an array, every array has overhead, the garbage collector is working overtime. A two gigabyte GeoJSON of global building footprints? That tab is gone. It's not a slow render, it's a crash.
So the format that's supposed to be web-native is actually the least web-friendly thing you can serve at scale.
And yet people keep doing it, because GeoJSON is what APIs return, it's what you get from QGIS export, it's what every tutorial uses. The format is optimized for developer ergonomics — you can read it, you can debug it, you can write a quick Python script against it. That's a real advantage. It's just not an advantage that survives contact with a ten million row dataset.
What's the workaround then? Because people aren't just abandoning GeoJSON.
The escape hatch is newline-delimited GeoJSON — GeoJSONL, or sometimes called NDJSON. Instead of one giant FeatureCollection with an opening bracket, ten million features, and a closing bracket, you write one feature per line. Each line is a complete, valid GeoJSON feature object. No outer array.
So you can read it line by line.
A streaming parser reads one line, parses one feature, hands it off to whatever needs it, and moves on. It never holds more than one feature in memory. Tools like tippecanoe — which builds vector tiles from geo data — can consume GeoJSONL directly, line by line, and never choke.
But that breaks the spec, right?
It does. RFC 7946 defines a GeoJSON document as either a single geometry, a Feature, or a FeatureCollection. A file with multiple Feature objects on separate lines with no enclosing array is not valid RFC 7946. Most GIS tools won't open it natively. QGIS will complain. ArcGIS will look at you funny. It's a convention, not a standard — but it's the convention that keeps large-scale GeoJSON workflows alive.
So the format's practical ceiling is whatever fits in memory as a single JSON object, and the workaround is to stop using it as a single JSON object.
And that's before we even talk about the coordinate redundancy tax. Every vertex in a GeoJSON polygon is stored as a full longitude-latitude array. If you've got a coastline with a hundred thousand vertices, you're storing "left bracket, number, comma, number, right bracket, comma" a hundred thousand times. In a binary format like FlatGeobuf, those same coordinates are packed as sixty-four-bit doubles — eight bytes per coordinate, no brackets, no commas, no text overhead at all.
How much smaller?
Four to eight times smaller on disk, typically. And the parser doesn't need to do text-to-float conversion — it reads the bytes directly into memory as doubles. A three hundred megabyte FlatGeobuf file parses in under two seconds. The equivalent GeoJSON would be over a gigabyte and take the forty-five seconds we talked about.
That's not a format difference, that's a completely different category of thing.
And FlatGeobuf has one more trick that GeoJSON can't touch — memory mapping. You can tell the operating system to map the file into virtual memory, and then you access only the byte ranges that correspond to the features you actually need to render. If you're zoomed into Manhattan, you don't touch the bytes for Tokyo. GeoJSON has no mechanism for that. It's all or nothing.
So we've got a format that's great for a few thousand features, readable in any text editor, and absolutely the wrong tool for anything at production scale.
Unless production scale means a handful of markers on a map. GeoJSON is perfect for that. The problem isn't the format, it's the mismatch between what people assume it can do and what it was designed to do.
Let's talk about the conversion side before we move on, because that's where a lot of this lives in practice. Nobody's just sitting with one format.
GDAL is the thing you need to know. Specifically ogr2ogr, the vector conversion tool. It supports over two hundred vector formats. You can take a GeoJSON file and convert it to FlatGeobuf, GeoPackage, MBTiles — all in one command. The GeoJSON driver in GDAL reads and writes RFC 7946 compliant GeoJSON, and it can also handle the newline-delimited variant for reading.
But conversion isn't free.
It's never free. Every conversion step is a chance to lose something. You convert from GeoJSON to FlatGeobuf and you lose... well, not much, because GeoJSON doesn't carry styling or CRS information beyond WGS 84. But convert from KMZ to GeoJSON and you lose styling, time animation data, ground overlays, three D models — all of it silently dropped. The file converts, you get geometry and properties, and you don't realize what's missing until you try to use it.
Which brings us to KMZ. Let's go there.
KMZ has been in the game longer than GeoJSON. KML — Keyhole Markup Language — was developed by Keyhole Incorporated, which Google acquired in 2004. It became the native format for Google Earth. A KMZ file is just a zipped KML file, and inside that zip you can bundle geometry, styling, raster overlays, three D models, even custom icons. It's a self-contained package.
And it does things GeoJSON simply cannot.
Four things, specifically. First, styling. KML has native elements for line color, line width, polygon fill, icon scale, label placement. GeoJSON has none of that — it relies entirely on the rendering engine to apply styles. If you open a styled KML in Google Earth, it looks the way the author intended. If you open a GeoJSON in a web map, it looks like whatever default the library gives you until you write styling code.
Second thing?
Time-aware data. KML has TimeSpan and TimeStamp elements. You can tag every feature with a time range or a single timestamp, and Google Earth will animate them natively — play, pause, scrub through time. Think earthquake epicenters appearing in sequence, or hurricane tracks evolving. GeoJSON has no equivalent. You could store timestamps in the properties object and write custom animation code, but the format itself has no concept of time.
Third?
Three D geometry. KML supports COLLADA models — you can place detailed three D buildings, bridges, terrain models directly in the file. GeoJSON is strictly two dimensional. You can fake it with elevation properties, but you can't represent a textured three D mesh.
And fourth?
Raster overlays. You can embed georeferenced imagery — a drone orthomosaic, a scanned map, a satellite image — directly into the KMZ. Ground overlays drape imagery over the terrain. Screen overlays put legends or logos in fixed screen positions. GeoJSON can't do any of that.
So KMZ sounds like the clear winner for a whole class of workflows.
And it is, if your workflow lives inside Google Earth. The moment you step outside — into QGIS, into ArcGIS Pro, into a web map built with Mapbox or Leaflet — KMZ becomes a problem. ArcGIS Pro can read KML but it strips the styling. QGIS has partial support — some styling comes through, some doesn't. Web map libraries can't consume KML directly at all. You have to convert to GeoJSON or vector tiles first, and as we just established, conversion drops everything that makes KMZ special.
So it's a walled garden format that happens to be the best tool for a specific set of jobs.
Field surveys are the canonical example. You're out with a GPS, you collect points and tracks, you want to see them in Google Earth with custom icons and labels, maybe overlay some drone imagery, maybe animate a time sequence. KMZ handles all of that in one file. You zip it up, email it to someone, they double-click it and Google Earth opens with everything exactly as you intended. That workflow has no equal in the GeoJSON world.
What about performance at scale? Because KML is XML, and XML is verbose.
It's worse than GeoJSON for raw parsing speed. XML has opening and closing tags, namespaces, attributes — the overhead per coordinate is higher than JSON's brackets. A hundred megabyte KML file might compress to thirty megabytes as KMZ, but when you unzip and parse it, you're still walking an XML tree. KML also defaults to six decimal places for coordinates — that's about eleven centimeters of precision. At high zoom levels in urban areas, you can see vertex snapping artifacts where coordinates get rounded.
Eleven centimeters is a lot when you're looking at building corners.
It's visible. And KML lets you specify more decimal places, but most export tools don't. So you get data that looks fine at city scale and falls apart when you zoom into a single block.
Let's round out the landscape. We've talked about GeoJSON and KMZ. What else is in the toolbox?
Shapefile is the one everyone loves to declare dead, and it's still everywhere. Developed by Esri in the nineteen nineties, it's been the lingua franca of GIS for thirty years. Government agencies still require Shapefile delivery. GDAL still defaults to Shapefile for many operations.
And it's a terrible format.
It's a format with... let's call them accumulated quirks. Attribute column names are truncated to ten characters. You cannot store null values — a missing number becomes zero, which is a completely different thing. There's a two gigabyte file size cap per component file. And a Shapefile isn't one file — it's at minimum three files, the dot shp for geometry, dot shx for the spatial index, dot dbf for attributes. Plus optional sidecars for projection, spatial reference, metadata. You send someone a Shapefile and you're actually sending them a folder.
Ten character column names. So "population_density_2024" becomes "population".
Or "populatio_" if you're unlucky. And if you have two columns that start with the same ten characters, one gets silently renamed. It's the kind of thing that causes bugs that take an afternoon to track down.
What's the replacement?
GeoPackage is the one the Open Geospatial Consortium is pushing. It's a single SQLite file — one file, not a folder of sidecars. It can store vector data, raster data, and tiles all in the same database. It supports spatial indexing via R-tree, which means spatial queries are fast. No column name limits, proper null support, no size cap beyond what your file system can handle. It's genuinely good.
And adoption?
Growing, but slow. Shapefile has thirty years of institutional momentum. Every piece of GIS software ever written can read Shapefile. GeoPackage support is good in QGIS and GDAL, decent in ArcGIS, and nonexistent in a lot of legacy government systems. The format is better, but the ecosystem hasn't fully shifted.
You mentioned FlatGeobuf earlier. Where does that fit?
FlatGeobuf is the performance option. It's built on Google's FlatBuffers serialization library, which means it's binary, it's designed for zero-copy deserialization, and it supports streaming and memory mapping natively. You can read a subset of features from a massive file without touching the rest. For web map serving at scale, it's competing with vector tiles rather than with GeoJSON.
And MBTiles?
MBTiles is also SQLite-based, but it's specifically a tile archive. You pre-generate map tiles at multiple zoom levels, store them in a single file, and serve them directly. It's the standard for offline maps — you download an MBTiles file, point a tile server at it, and you've got a full map without an internet connection. Mapbox and TileServer GL both support it natively.
So the landscape is basically — GeoJSON for small, readable, web-friendly data. KMZ for Google Earth workflows with styling and time. Shapefile because institutions demand it. GeoPackage for modern single-file archival. FlatGeobuf for streaming performance. MBTiles for offline tile serving.
And the real world doesn't let you pick one and stick with it. You move between them constantly, and that's where the conversion pipeline becomes the actual skill.
Walk me through a typical chain.
Let's take a real example. The USGS earthquake feed. It publishes KML — time-stamped earthquake epicenters, color-coded by magnitude, with custom icons for different event types. You want to put this on a web map.
So you can't use the KML directly.
Not in a web map, no. So you convert. KML to GeoJSON via ogr2ogr. That step drops the color coding, the icon scaling, the time stamps as native time animation — all of it. You get points with magnitude and time stored as plain properties. Then you convert that GeoJSON to Mapbox vector tiles using tippecanoe. Then you have to re-apply the styling in Mapbox Studio — re-create the magnitude-based color scale, re-create the icon choices. The conversion chain is KML to GeoJSON to MBTiles, and the styling has to be rebuilt from scratch at the end.
So the data survives, but the presentation doesn't.
The presentation was half the value of the original file. The person who published that KML made deliberate choices about how the data should look. Those choices are encoded in the format. Conversion strips them.
What are the other things that get lost silently?
Coordinate reference system is the big one. GeoJSON is always WGS 84 — that's baked into the RFC. If your source data is in a projected coordinate system, like UTM or State Plane, ogr2ogr will reproject it to WGS 84 during conversion. Usually that's fine, but if you don't know it happened, you might wonder why your coordinates changed. Null values are another — Shapefile can't represent null, so a missing temperature reading becomes zero degrees. That's not a format quirk, that's a data corruption waiting to happen.
Zero degrees is a real temperature. You can't tell the difference between "no reading" and "it was freezing."
Attribute precision — some formats store integers as thirty-two-bit, some as sixty-four-bit. Converting between them can truncate large ID values. These are the bugs that show up six months later when someone notices that half the building IDs in the database are wrong.
What's the practical decision framework? If someone's starting a project tomorrow, how do they pick?
Four rules of thumb. One — if you need human readability and the dataset is under five hundred megabytes, use GeoJSON. You can inspect it, debug it, version-control it. Two — if you need Google Earth compatibility, time animation, or embedded raster overlays, use KMZ. Nothing else does what it does in that ecosystem. Three — if you need to serve data on a web map at scale, use FlatGeobuf for the data pipeline and MBTiles for the tile serving. Four — if you need a single-file, self-contained archive for long-term storage or sharing, use GeoPackage.
And Shapefile?
Use Shapefile when the government agency you're delivering to requires it. That's the only reason.
What about the conversion pipeline itself? What should people actually learn?
ogr2ogr is the Swiss Army knife, and the flags are where the power is. The dash t underscore srs flag reprojects during conversion — you can go from a local projection to WGS 84 in the same command. The dash clip flag lets you crop to a bounding box so you're not converting an entire global dataset when you only need one city. The dash lco and dash dsco flags control layer creation options and dataset creation options — things like coordinate precision, spatial index creation, geometry type enforcement.
And tippecanoe?
tippecanoe builds vector tiles from geo data, and its flags control the entire output. The dash z and dash Z flags set the min and max zoom levels. The dash l flag specifies the layer name. The dash pf and dash pk flags control whether features are dropped or kept when they conflict at low zoom levels. Most geo visualization failures at scale are not format failures — they're tippecanoe misconfigurations where someone didn't set the zoom range correctly and wondered why their data disappeared at zoom level fourteen.
The tool knowledge is as important as the format knowledge.
More important. The format is just the container. The pipeline is what gets the data from the container to the screen.
One thing you said earlier stuck with me — GeoJSON is not a bad format, it's a format optimized for developer ergonomics, not rendering performance. Using it for ten million points is a misuse, not a format flaw.
The same goes for KMZ. It's not outdated. It's purpose-built for the Google Earth ecosystem, and in that ecosystem it's still the best option. The frustration people feel with these formats usually comes from using them for things they weren't designed to do.
Which circles back to the conversion problem. Every format was designed for a specific workflow. Moving between them means leaving behind the assumptions that made the original format good at its job.
The way to catch that is validation. After every conversion, run ogrinfo with the dash al and dash so flags. That gives you a summary — feature count, geometry type, attribute schema, spatial extent. Check that the feature count matches. Check that the geometry type didn't change — a conversion that turns polygons into multipolygons can break downstream tools that expect simple polygons. Check that your attributes survived with the right names and types.
Silent data loss is the recurring theme here.
It's the thing that separates someone who's been burned from someone who hasn't been burned yet. Everyone who works with geo data long enough has a story about discovering, six months into a project, that a conversion dropped something critical. Styling, null values, CRS, column names — it's always one of those four.
We've seen where each format shines and where it breaks. What does that mean for the next project someone starts?
It means start with the question "what am I actually doing with this data" before you think about what format it's in. Are you building a web map that needs to render fast? Are you sharing field survey results with a team that uses Google Earth? Are you archiving data for a government agency? The format follows the workflow, not the other way around.
If you don't know what workflow you'll need in the future?
Then store it in GeoPackage. It's the most versatile archival format — single file, self-contained, supports both raster and vector, spatial indexing built in. You can convert from GeoPackage to anything else later. It's the least-lossy starting point.
But the landscape isn't static. Where are these formats heading?
The direction is clear — toward streaming, tiled, binary formats. The Open Geospatial Consortium's Three D Tiles standard and GeoPose are pushing toward GPU-ready data delivery. WebGL 2.0 and WebGPU are making browser-based rendering fast enough that the bottleneck is now entirely in the data pipeline. If your format can't stream and can't be memory-mapped, it's going to feel increasingly archaic for large-scale visualization.
Does GeoJSON have a future in that world?
There's work on a GeoJSON Binary encoding — essentially a binary representation of GeoJSON structures that would be parseable without text deserialization. But it's not standardized yet, and FlatGeobuf already exists and works. The era of the single-file, human-readable geo format may be ending for large-scale visualization. Not because human readability is bad, but because the datasets have outgrown it.
A two gigabyte text file was never a good idea. We just pretended it was because we liked being able to open it in Notepad.
Now we know better. The conversion pipeline is where the real work happens. The format is just the starting point.
If you enjoyed this episode, leave a review — it helps other geo-curious listeners find us. And send us your weirdest geo data format horror story. We know you have one.
Thanks to our producer Hilbert Flumingtop. This has been My Weird Prompts.
We'll be back soon.
