The Data and City Boundary Problem
Cities are the economic engines of the world. They generate more than 80% of global GDP and are home to over half the world's population.[1][2]
Effective cities are humanity's only path to an abundant future. We need rapid progress on congestion, pollution, crime, housing affordability, and other urban challenges.
Research on cities is too thin, especially in the Global South. There is not enough data on cities — on how they are performing, what decisions they are making, and what policies are working.
The first step in comparative research on cities is getting the boundaries right. Surprisingly, there isn't an off-the-shelf set of open city boundaries that reflects economic realities and works throughout the Global South, so we created one.
You can see the problem in the exhibit below. Official administrative boundaries are out of date and don't correspond to economic reality. Dhaka's official boundaries encompass a lot of farmland, while missing a lot of dense urban land that is de facto part of the city. If you live in Noida, you're not officially in Delhi, but you directly benefit (or suffer) from Delhi's policies on congestion, pollution, and economic activity. Further, admin boundaries mean something different in every country in the world.
Administrative boundaries don’t match urban economic reality
The answer to "where does this city end?" depends on what you want to measure. We use an economic definition. Cities exist because of agglomeration economies: people are more productive when there are a lot of other people around[8][9]. We want to measure the urban agglomeration: the contiguous built-up area in which people directly benefit from being connected to the city center. This is a fuzzy boundary; there won't be an exact answer. But to make progress, we need a boundary that is good enough, and means approximately the same thing in different places around the world.
The canonical dataset on economic boundaries of cities is the Urban Centre Database (UCDB), part of the Global Human Settlement Layer (GHSL).[3][4] The UCDB uses a complex algorithm to detect city boundaries from satellite data and works pretty well in a lot of countries.[5]
But it doesn't work well enough, especially in low-income countries with high rural population densities. This is a structural problem: UCDB uses a fixed global population density threshold, which cleanly separates urban and rural areas in Europe and North America, but swallows entire dense rural regions in the Global South. The map below shows UCDB's definition of Hajipur in Bihar—the boundary spans a vast rural district, because Bihar is so densely populated. UCDB puts Noakhali and Dhaka into the same city, but they're four hours away by car and nine by bus, with vast rural areas between. A useful definition of a city should keep places like these separated.
The UCDB defines cities using a fixed global threshold: places with population density above 1,500 people/km² or built-up area share per cell equal or greater than 0.23, and at least 50,000 total population. We found that in South Asia, sub-Saharan Africa, and much of the Global South where rural areas routinely exceed 1,500 people/km², city boundaries balloon to extreme sizes.
GHSL Urban Centre Database doesn't work well in many parts of the world
Our aim is to produce boundaries that can be plugged directly into other urban datasets without further processing. We therefore merge each city's multi-polygons into a single unit and label it. We also calibrate our thresholds country by country (see below) — even an accurate global algorithm still needs this local fine-tuning to separate cities from dense rural hinterlands.
Our Approach
We set out to build new urban boundaries that meet five criteria:
- Global scale - computationally inexpensive using open data
- Work everywhere - algorithm produces sensible results in rich and poor countries
- Reflects economic access - approximate the area from which people regularly commute to a city's core
- Matches local intuition - correspond to how residents understand their own cities
- Supports comparative analysis - consistent enough to compare cities across countries and regions
Our working definition of a city's economic footprint is the region whose residents have direct access to a city's productivity and consumption advantages. Just defining this is non-trivial, as agglomeration benefits are diffuse and can extend beyond commuting range. Some urban agglomerations defy classification entirely, like the Shenzhen-Dongguan-Hong Kong corridor, where goods flow freely across boundaries that restrict labor movement. We describe edge cases like these in the methodology paper, which is forthcoming.
Three Satellite Datasets
We combined three satellite-derived datasets, each capturing a different signature of urbanization: population density[6], built-up area, and night-time luminosity[7]. Any one of these alone produces too many false positives; we found that requiring agreement between at least two yields much more reliable boundaries. Play with the sliders below; there is no one-dimensional measure that works in many places.
Population density comes from WorldPop high-resolution estimates. Built-up area comes from the GHSL built-up surface layer. Night lights come from VIIRS monthly composites.
Population Density, Night Lights, and Built-up Area — three different signatures of urbanization
Adaptive Thresholds
While it would be nice to have a single global numeric definition that works everywhere, the reality is that the same population density or night-light intensity means different things in different places. To address this, our algorithm instead starts with baseline thresholds and then calibrates them to local context. We stick with GHSL's population density constant of 1,500 people/km², but made the other two measures flexible. We took the densest population cells in each country, and measured how bright they were in the night lights data; that gives us a dynamic measure for how bright cities are in that place, and suggests a night light threshold value. We did something similar for built-up area. With these thresholds in place, we classified any cell that meets at least 2 of the three thresholds as urban.
This means our method automatically adjusts to the global context — the same algorithm handles Manhattan and rural Bangladesh without swallowing farmland in one or missing sprawl in the other. Figure 4 shows the calibrated night-light and built-up area thresholds for 186 countries.
In formal terms: Urban = (Night Lights ≥ Tlight AND Population ≥ Tpop) OR (Population ≥ Tpop AND Built-up ≥ Tbuilt) OR (Night Lights ≥ Tlight AND Built-up ≥ Tbuilt). Default thresholds were set globally, then fine-tuned in countries where the algorithm was clearly capturing too much rural territory or missing large parts of known cities. We describe the full calibration procedure in the methodology paper, which is forthcoming.
Country-level calibration of night-light and built-up-area thresholds
In a handful of cases, this approach was still clearly off, so we manually tweaked the country-level thresholds. While this means our approach isn’t purely algorithmic, our goal is to have city boundaries that are accurate and consistent. If features of the environment like building types or green belts make the city look different from outer space, we want our boundaries to stay focused on the economic city.
Results
Our boundaries capture the economic footprint of cities very well across a wide range of contexts: dense megacities in South Asia, sprawling metro areas in the U.S., and compact European cities alike. You can explore them interactively and compare them to UCDB using our Urban Agglomerations Explorer - and please report to us if anything looks wrong. Unlike the algorithmic city boundaries like UCDB, we can revise and update on a city by city level.
DDL Urban Boundaries
How are these boundaries used?
A lot of data on cities these days comes from global sources outside the city, like satellites or app platforms. We need functional urban boundaries to aggregate these data at the city level. National surveys also use administrative definitions which mean different things in every country; when these are geocoded, mapping them to consistent urban boundaries improves comparability across cities and countries. For data that is collected and reported by cities (such as murder rates), we’re stuck with the administrative boundaries that they use while collecting it.
Limitations
Currently our boundaries are a single snapshot in time. For comparing changes across cities, this is usually what we want! If we want to measure urban population growth, we want to distinguish between more people living in a place, and a city expanding its boundaries so that more people are counted even if their numbers haven’t changed. If we want to measure how green space in a city has changed, we don’t want to credit a city for expanding its boundaries into a green zone, which doesn’t change what residents actually experience.
Our algorithm isn’t fully automated. This sounds like a disadvantage, but it isn’t. We want to represent the reality of urban spaces even when they don’t look the same from outer space. This said, we haven’t fine-tuned every last city in the 5000-city sample, so there may still be errors. But we think our default settings outperform the standard product out there, and we expect to find and fix errors over time and release updates that are even more accurate.
If someone does come up with an algorithm that works for everything—and there are some good ideas out there[10][11][12][13][18]—we'll happily adopt it! If you're working on urban boundaries, for the love of science, please post a boundary file if you want us or anyone else to use your work!
Explore Further
Frequently Asked Questions
If you want the economic definition of a city, why not just use commuting data?
This is an interesting idea! Commuting data tells you the places from which people actually do and don't travel to the urban center, which is a good proxy for the reach of the city. Unfortunately there's no high quality granular commuting data that's available globally. Commuting survey samples are much too small to describe all the boundary regions of cities.
Big data companies like Google Maps and Uber could probably calculate these, but they haven't released the global data that would make it possible. Facebook released a dataset of commuting zones, but they tend to extend way beyond cities as we normally understand them. There's ongoing work here[14][15][16][17] and we'll adopt it as soon as it outperforms our current boundaries.
How do you handle mass agglomerations of many cities?
This problem arises all over the place: how should we split Shenzhen / Dongguan, or San Diego / Tijuana or San Francisco / San Jose or Delhi / Gurgaon? Often, there are no physical features that could define these boundaries, and our algorithm defines them as single mega-agglomerations.
For some applications, the mega-agglomeration may be what you want. But sometimes the individual cities have policies or data tracking that you want to keep separate. Our primary product therefore divides megacities by their official administrative boundaries, but still uses the economic definitions for their outskirts. We store and release both versions of the agglomeration, e.g. (i) Delhi; (ii) Gurgaon; (iii) Delhi mega-agglomeration, so you can pull the data at the level of aggregation that suits your question.
What about Meta's Global Urban Areas?
Meta's Global Urban Areas database[19] similarly defines cities as contiguous blocks of built-up area. Its boundaries are derived from the European Space Agency's WorldCover product[20] — 10-meter land-cover rasters built from Sentinel-1 and Sentinel-2 imagery collected in 2020. Meta's boundaries do not suffer from the failure modes of GHSL noted above: they are comparable to ours in rich countries, and are drawn at higher spatial resolution, capturing fine detail at urban fringes. They sometimes outperform us at incorporating low-density suburbs of major cities.
We like Meta's boundary algorithm, but their cities are anonymous and often fragmented into dozens of small, discontinuous, unlabeled polygons; our algorithm stitches these together into single labor markets. The differences show up most clearly in low- and middle-income countries, where our algorithm identifies roughly 20% more small towns (population 50,000–100,000) that are absent from Meta's data. You could certainly geoname and process Meta's data into a boundary dataset like ours and the quality would be similar. Ours works off the shelf and it easily linkable to other city-level products. (And we're working on making these links even more smooth and seamless.) Explore DDL and Meta boundary comparison page.