How the isometric map of Mexico City was made
This is the honest record of how CDMX Isométrica was built: what data was used, how it was turned into a drawing, and what went wrong along the way. It is not a tutorial — it is the log of a project that took months and keeps changing.
From day one to today
The map did not appear overnight. It started in July 2026 as a test with a few blocks of the historic center and has changed almost every day since. These are the main stages:
| When | What happened |
|---|---|
| July 2026 | First test: a few blocks of the historic center. That same month the map switches to real OpenStreetMap data and the first version goes online |
| July 26 | 36 zones of the city and 110 thousand elements downloaded |
| Early August | 47 zones and more than 12 thousand baked images |
| August 10 | Its own domain, cdmxisometrico.com, and neighborhood and borough names on the map |
| August | Night mode with windows and street lights, Metro lines in their colors and guided tours |
| August 24 | The whole urban city is covered, from Azcapotzalco to Xochimilco |
| September | First articles about the city |
| October | Weekly articles with figures taken from the map itself, and an English version |
| November | Roof colors measured with satellite imagery and updated data: 128,882 buildings |
Where the data comes from
The whole map is drawn from OpenStreetMap, the free map maintained by volunteers around the world. No one on this project measured a single street: what you see is the accumulated work of thousands of people who recorded the city, building by building, over many years.
The data is requested through Overpass, a service that lets you ask the world map questions like "give me every building and street inside this rectangle". The city is downloaded by zones —the historic center, Coyoacán, Xochimilco, Azcapotzalco and about fifty more— because asking for all of it at once makes the server cut the connection halfway.
Three things matter for each building: its outline, its height and what it is. Height is the fragile part: many buildings in OpenStreetMap don't have it, so it is deduced from the number of floors. When there are no floors either, a typical height for that type of building is used. That is why some areas have houses that all look the same height: they are not identical, it is just that nobody has recorded their height yet.
What "isometric" means here
Isometric projection is the one used by nineties video games: the camera looks at the city from above and from the side, always at the same angle, with no perspective. A thirty-meter building looks exactly as tall in the historic center as in Santa Fe.
That has a nice consequence and an awkward one. The nice one is that you can travel across the city without anything getting distorted. The awkward one is that tall buildings hide what is behind them, and you have to decide in what order everything is drawn so the city reads well. The rule that stuck: first the ground, then the water, then the streets, and finally the buildings from back to front, like stacking cards.
Baking: 500 km² turned into images
A map like this is not drawn when someone opens it. That would be impossible: there are more than a hundred thousand buildings and no computer can draw them all in time. Instead, the city is drawn once, in advance, and cut into small squares that are then served as pictures. We call that process baking.
The five levels exist because the detail that works from far away doesn't work up close. In the full-city view there is no point drawing every tree; at street level there is. When someone zooms in, the viewer switches to the finer level without it being noticeable.
There is one detail that took a while to understand: because the map is pixel art, enlarging an image looks better than shrinking it. When enlarging, smoothing turns off and the edges stay hard and clean, which is exactly the style; when shrinking, the browser averages the pixels and everything turns to mush. It is the opposite of what you would do with a photograph.
What the map draws and where it gets it
| What you see | Where it comes from |
|---|---|
| Buildings with their height | OpenStreetMap outlines and heights |
| Streets, avenues and bridges | OpenStreetMap road network |
| Street trees | Planted along the streets, only where there are buildings nearby |
| Cars | Placed on the asphalt, turned to the real angle of each street |
| Metro lines | The track layout, colored by line |
| Neighborhoods and boroughs | Named points from OpenStreetMap |
| Roof colors | Measured with a Sentinel-2 satellite image (contains modified Copernicus Sentinel data 2026) |
| Night lights | Calculated: windows of the tall buildings and street lights along the avenues |
Trees and cars do not exist one by one in OpenStreetMap. They are planted by rules: a tree every so often along the sidewalk, as long as there is a building less than 45 meters away, and never on the asphalt. That last condition was one of the hardest: for weeks there were trees growing in the middle of Insurgentes.
The mistakes that cost the most
One wrong character
For a long time trees appeared in perfect squares where there should be none, and at the same time trees were rejected "for falling in the water" in forests without a single pond. Both symptoms came from the same function: the one that decides whether a point is inside a polygon. It said "is inside" where it should have said "switches state". The correct test counts how many times a ray crosses the edge: if it crosses an odd number of times, the point is inside. One misplaced character turned every park into an endless strip running west.
The cut lake
The Xochimilco lake appeared split by a perfectly vertical line. The clue was in the shape of the cut: a perfectly vertical edge on screen cannot be geographic, because in isometric view everything real comes out diagonal. It was a seam between two baked squares: the clipping only checked two points of the polygon and threw away the rest of the water.
The domes that came and went on their own
The Palacio de Bellas Artes lost its domes overnight without anyone touching the code. The cause was outside: someone in OpenStreetMap added the building's 3D parts, and the program is built so that, when real data exists, the hand-drawn decorations are turned off. The data got better and the drawing got worse, because the code didn't recognize one of the roof types they used.
The night
Night mode is not a dark filter over the map. If everything were just darkened, the windows would be as unlit as the walls. For them to light up you need to know where every window is, and that information doesn't exist anywhere: it is recalculated from the size of each building and exported as a list of points.
Street lights were harder than windows, for a reason that is not technical but about observation: at first they were drawn as round dots of light, and they looked like fireflies. A lit street is not separate spots — the cones of light overlap and form a continuous band of bright asphalt. Once it was drawn that way, the city at night started to look like a city.
What is missing and why
The map covers about 500 km² of the urban area. Milpa Alta, Tláhuac and much of Cuajimalpa and Magdalena Contreras are left out: they are mostly rural, forested or ravines, and the cost in images is not justified by how little there would be to draw.
There are urban areas where the map looks empty even though they are not. It is not a drawing error: nobody has recorded those buildings in OpenStreetMap yet. Santa Martha Acatitla, for example, is dense in reality and almost transparent in the data. Anyone can fix that: OpenStreetMap can be edited freely, and whatever is added there will show up here in the next bake.
Current version of the map: viewer 9.45 and baker 18.44, November 2026. The viewer is the page that shows the map; the baker is the program that draws it. Each number is a round of changes tested before being published.