OpenAddresses Download and Formats: Global Address Data for GIS and Geocoding
OpenAddresses is an open geospatial data project that collects references to address, cadastral parcel, building-footprint, and street-centerline sources from around the world, then processes those sources into downloadable geographic data. Its strongest and most mature use case is address data: records commonly include house numbers, street names, units, cities, regions, postal codes, identifiers, accuracy fields, and geographic coordinates. OpenAddresses is not one uniformly authoritative global address database. It is an aggregation and processing system whose coverage, attributes, precision, licensing, and freshness depend on the underlying source published by each government agency or other data provider.
For GIS analysts, geocoders, mapmakers, and location-data engineers, OpenAddresses is best understood as a practical bridge between many local address datasets and a common global workflow. The project maintains source definitions that describe where data comes from, how it should be downloaded, and how its fields should be mapped into a shared output structure. The processed results can then be downloaded by country or region, inspected on a map, or used as an input to address search, spatial joins, service-area analysis, and geographic data integration. The important qualification is that OpenAddresses standardizes access and processing more than it standardizes the underlying truth: a city, county, or country may publish highly complete address points, while another source may be partial, old, approximate, restricted, or missing important fields.
How EDK fits
For: This page is for GIS professionals, geocoding and search developers, civic-data teams, researchers, cartographers, and analysts who need downloadable address data or want to understand the structure and limitations of the OpenAddresses ecosystem.
OpenAddresses relates directly to the problem of finding and computing about the physical world because an address is a human-readable reference to a physical location. It can provide the address-point layer needed to connect names and postal descriptions to coordinates, buildings, roads, parcels, public assets, environmental features, and other geographic objects. In a broader world-model workflow, OpenAddresses is most useful as one source layer among many: it can help establish where a place is, while other datasets supply the surrounding road network, building geometry, land use, infrastructure, imagery, or observed conditions. The main editorial lesson is that address data improves geographic search and spatial computation only when its source geography, coordinate quality, vintage, licensing, and field semantics are preserved.
- •Address-to-feature linking: use OpenAddresses records as candidate locations for connecting street addresses to nearby buildings, roads, parcels, transit stops, public facilities, utility assets, environmental features, or other physical-world data.
- •Geographic coverage and quality analysis: compare address-point coverage by city, region, or source, measure missing or poorly geocoded records, and rank areas where additional authoritative location data would improve search or spatial analysis.
- •Spatial computation around addresses: filter, aggregate, and calculate proximity or accessibility measures around address points, such as counting nearby services, identifying addresses near roads or waterways, or summarizing properties within administrative or environmental regions.
Dataset profile
Formats
GeoJSON for processed public geographic data and map-oriented access.
CSV for documented export workflows and tabular processing.
ESRI Shapefile for documented export workflows and compatibility with traditional GIS software.
Source and ingestion formats may include CSV, GeoJSON, Shapefile, XML, File Geodatabase, GeoPackage, ZIP archives, and ArcGIS Feature Services.
Source definitions and API metadata use JSON.
Access methods
Download regional or collection data through batch.openaddresses.io.
Use the documented batch API to inspect data, collections, map features, exports, and processing metadata.
Browse source definitions and field mappings in the OpenAddresses GitHub repository.
Process individual sources locally with OpenAddresses batch-machine, preferably in the project-supported Docker environment.
Use regional downloads or source-level processing when a global collection is too large for a desktop GIS workflow.
Quality and limits
Coverage is not uniform globally and may be incomplete even where a country or region has a published collection.
Underlying sources may differ in positional accuracy, field completeness, coordinate reference systems, naming conventions, duplicate behavior, and publication dates.
A weekly OpenAddresses processing run does not imply weekly upstream updates.
Some source portals may change URLs, schemas, authentication rules, or service behavior, causing processing failures or stale outputs.
Validated output checks documented by the project are focused on address data; equivalent validation should not be assumed for parcels, buildings, or centerlines.
The dataset is not automatically an authoritative postal register, cadastral record, property-ownership database, or complete inventory of buildings.
License and attribution obligations must be reviewed at the source level before redistribution or commercial use.
Analysis workflows
Download a regional GeoJSON collection, inspect metadata and properties, validate geometry, and load it into QGIS, ArcGIS Pro, PostGIS, DuckDB, or another spatial analysis environment.
Preserve source identifiers and provenance while normalizing house numbers, street names, unit fields, postal codes, and administrative names.
Create spatial indexes and partition large collections by country, region, source, or administrative boundary before running joins or proximity calculations.
Deduplicate overlapping records from adjacent or hierarchical sources using source IDs, normalized address keys, coordinate distance, and jurisdiction rules.
Join address points to building footprints, parcels, roads, transit stops, public facilities, environmental layers, or administrative boundaries.
Evaluate coverage by measuring address counts, null-field rates, duplicate rates, geometry validity, coordinate outliers, and records outside expected source extents.
Use address points as candidates for geocoding search while retaining confidence, source, and uncertainty metadata rather than presenting every coordinate as equally authoritative.
For reproducibility, record the download date, OpenAddresses processing run, source definition, upstream vintage, transformation steps, and applicable licenses.
Value inside EDK
What OpenAddresses contains
The OpenAddresses project describes itself as a global collection of address, cadastral parcel, building-footprint, and street-centerline data sources. Its main repository is a catalog of references and processing instructions rather than a single raw database. Each source definition identifies a geographic area, a download or service endpoint, the source format, and the rules needed to map source fields into a common OpenAddresses structure. (github.com)
For address layers, the normalized schema can include fields such as house number, street, unit, city, district, region, postal code, identifier, and accuracy. The precise fields available in a given output depend on what the upstream provider publishes and how the source is configured. Some records may be points, while other source geometries or attributes may be absent, generalized, or transformed during processing.
- •Primary subject: address records connected to geographic coordinates.
- •Broader repository scope: address, parcel, building-footprint, and street-centerline source references.
- •Typical normalized address attributes: number, street, unit, city, district, region, postcode, identifier, and accuracy.
- •Coverage is source-dependent and may vary substantially between neighboring jurisdictions.
Geography, temporal coverage, and update cadence
OpenAddresses is intended for worldwide coverage, but its practical geography is assembled source by source. The repository organizes source definitions by country and region, with examples including U.S. counties and cities as well as national sources in other countries. A country collection may therefore contain a mixture of municipal, county, state, national, or specialized address providers rather than one consistent national register. (github.com)
The project documentation describes a recurring production pipeline: source jobs are run on Friday, successful outputs are collected into country and regional archives on Sunday, and a later map-building step creates tiled products. This means the processing system has a weekly cadence, but it does not mean that every underlying source is updated weekly. A source may itself be refreshed daily, annually, irregularly, or only when a contributor updates its definition or the upstream provider changes its data. (github.com)
- •Geographic scope: global in ambition, uneven in source coverage.
- •Processing cadence documented by the project: weekly source processing and weekly collection aggregation.
- •Underlying freshness: variable and controlled by the original data provider.
- •Recommended metadata: source name, jurisdiction, processing run, download date, upstream vintage, and license.
Download options, formats, and access methods
The public download workflow is centered on batch.openaddresses.io and its associated API. The current project documentation identifies GeoJSON as a freely downloadable processed format for users, while CSV and Shapefile exports are supported through the batch system’s export functionality. Collection downloads are generally organized by geographic area, such as country or region, and the API exposes endpoints for current data, collections, map features, exports, and processing metadata. (github.com)
OpenAddresses source definitions can point to direct HTTP or FTP downloads, ZIP archives, CSV files, Shapefiles, GeoJSON, geodatabases, GeoPackages, or ArcGIS Feature Services. The processing software supports source conform formats including Shapefile, GeoJSON, CSV, XML, GDB, and GPKG. These are input and ingestion formats; they should not be confused with the normalized public output formats available for every collection. (github.com)
- •Public processed output: GeoJSON.
- •Documented export formats: CSV and Shapefile, subject to the batch service’s access model.
- •Supported source or ingestion formats: CSV, GeoJSON, Shapefile, XML, GDB, GPKG, ZIP, and ArcGIS services.
- •Access methods: batch.openaddresses.io downloads, API endpoints, GitHub source definitions, and local batch-machine processing.
License, attribution, and data-governance considerations
There is no single blanket license that automatically applies to every processed OpenAddresses record. The project states that its pipeline does not relicense the original source data and that individual sources retain their own licensing conditions. The source-definition repository itself is released under CC0, while other repository code uses separate software licenses. Users must inspect the source metadata and included license information for the particular jurisdiction or collection they intend to use. (github.com)
This distinction matters for redistribution, commercial use, attribution, derivative databases, and combining records from multiple jurisdictions. A collection assembled from many sources may carry multiple attribution requirements or restrictions. A defensible workflow preserves source-level provenance instead of treating the combined download as license-free simply because the project is open.
- •OpenAddresses source definitions: CC0 according to the repository documentation.
- •Original source data: governed by the original provider’s license or terms.
- •Attribution: may differ by source and jurisdiction.
- •Commercial redistribution: requires source-by-source license review.
Suitable GIS workflows and interpretation cautions
A straightforward GIS workflow is to download a regional GeoJSON collection, inspect its coordinate reference system and properties, validate geometries, and load it into a spatial database or desktop GIS. Analysts can then index the point geometry, normalize text fields, deduplicate overlapping jurisdictions, and join addresses to administrative boundaries, parcels, buildings, roads, transit stops, or service locations. For large collections, process by region or source rather than loading the entire global output into memory.
For geocoding, OpenAddresses can serve as a candidate address-point corpus or an input to a larger search index. It should not automatically be treated as a complete postal authority. Address strings may use local conventions, abbreviated street names, inconsistent unit notation, or different interpretations of city and district fields. A production geocoder should preserve the original values, record source provenance, and expose uncertainty rather than silently presenting every coordinate as equally precise.
- •Good uses: address search, geocoding indexes, map display, spatial joins, coverage analysis, and proximity calculations.
- •Recommended preparation: preserve source IDs, retain provenance, validate coordinates, normalize text carefully, and deduplicate by jurisdiction.
- •For large data: use regional collections, streaming GeoJSON, spatial indexes, or a database such as PostGIS.
- •Do not infer equal accuracy, completeness, or freshness across all records.
Questions teams ask
Is OpenAddresses one global address database?
No. It is an aggregation and processing ecosystem built from many local and regional sources. The project creates common outputs, but the underlying data remains dependent on the coverage, quality, update schedule, and license of each contributing source.
What format should I download for a GIS project?
GeoJSON is the most directly documented public processed format and is convenient for inspection, web mapping, and loading into many GIS tools. CSV can be useful for tabular or database workflows, while Shapefile may fit older desktop GIS environments. For large datasets, consider streaming GeoJSON, converting to GeoParquet, or loading regional files into PostGIS after checking the source metadata.
Can I use OpenAddresses data commercially?
The answer depends on the underlying source. OpenAddresses states that it does not relicense original source data and that individual sources have their own licenses. Review the license and attribution information for every source or collection used before commercial redistribution or incorporation into a product. (github.com)
How current is OpenAddresses?
The production pipeline is documented as weekly, but upstream sources do not all update on the same schedule. A record may reflect a recent municipal publication, an older government extract, or a source that has not changed for some time. Retain the processing run and source metadata when freshness matters.
Does OpenAddresses include parcels and building footprints?
The broader project repository contains references to address, cadastral parcel, building-footprint, and street-centerline sources. However, the documented validated-output workflow currently applies to address sources, so users should not assume that parcel, building, or centerline data has the same normalization or quality controls. (github.com)
Keep exploring
geonames download and formats
GeoNames provides a complementary global place-name and gazetteer layer for connecting names, feature classes, coordinates, and administrative relationships to address-based workflows.
gtfs analysis workflow
GTFS can be joined to address points to analyze transit access, stop proximity, service coverage, and geographic accessibility.
natural earth download and formats
Natural Earth supplies generalized global reference layers that can provide cartographic and regional context around address coverage, although it is not a street-level address dataset.
Sources
OpenAddresses repository and project README
Authoritative project description, repository scope, source-data licensing explanation, and links to the download ecosystem.
Open sourceOpenAddresses Development Guide
Documents source definitions, supported upstream data types, normalized address fields, and the weekly production pipeline.
Open sourceOpenAddresses Batch API documentation
Documents processed output formats, export formats, validated address data, and API access conditions.
Open sourceOpenAddresses API reference
Documents current API endpoints for data, collections, GeoJSON map features, exports, and downloadable collection files.
Open sourceOpenAddresses batch-machine
Documents local processing, supported input formats, supported layer types, and the recommended processing environment.
Open source