OpenAddresses: Open Address Data for Geocoding, GIS, and Location Analysis
OpenAddresses is an open geospatial data project that collects references to address, parcel, building-footprint, and street-centerline sources, then processes many of those sources into a consistent address-oriented output. Its standardized address fields can include house number, street, unit, city, district, region, postcode, identifier, and accuracy, with point geometry supplied by the underlying source. OpenAddresses is useful for geocoding, reverse geocoding, address search, map production, spatial joins, and location-based analysis, but it is not one uniform global address register: coverage, completeness, positional accuracy, licensing, and freshness vary by source and jurisdiction.
Addresses are one of the most practical ways to connect a digital record to a physical place. OpenAddresses exists to make that connection easier to obtain and reuse by cataloging open address sources from governments and other publishers, documenting how each source can be downloaded, and transforming heterogeneous inputs into a more consistent structure. The result is best understood as an aggregation and processing ecosystem rather than a single surveyed database. It can provide valuable location evidence for cities, roads, buildings, parcels, services, and infrastructure, while still requiring source-level validation before operational or authoritative use.
How EDK fits
For: GIS analysts, geocoding and search developers, civic-technology teams, mapping organizations, researchers, data engineers, and anyone building location-aware applications from openly available address data.
OpenAddresses is directly relevant to the problem of finding and understanding the physical world because an address is a human-readable reference to a location on Earth. Its role is narrower than a complete world model: it focuses primarily on address records and the upstream datasets that describe them, rather than providing a universal representation of every road, building, utility, environmental feature, or public asset. The important connection is the bridge between names and places. Address fields, coordinates, locality names, postal codes, identifiers, and source metadata can help locate a physical feature, connect it to nearby roads or buildings, and organize other geographic observations around a common place reference. In an E2-style world model, OpenAddresses data can serve as one address-oriented evidence layer among many. The practical value comes from combining address points with roads, building footprints, parcels, transit, imagery, environmental layers, public records, and other geographic features, then measuring proximity, aggregating records by area, comparing coverage, or resolving entities across datasets. OpenAddresses should therefore be treated as a useful input to geographic search and computation—not as a substitute for source validation or a guarantee that every address in every place is present and current.
- •Use OpenAddresses records as an address-reference layer when connecting permits, service requests, incidents, businesses, buildings, or infrastructure observations to physical locations. A geographic system can normalize address components, compare coordinates with nearby roads and building footprints, flag records that fall far from expected features, and aggregate results by neighborhood, city, or other analysis region.
- •Use source-level coverage and address points to evaluate how well a location-data system represents a city or region. Analysts can compare address density with building or road layers, identify areas with sparse or missing address coverage, measure proximity to public assets, and prioritize additional authoritative data collection or review.
Dataset profile
Formats
Line-delimited GeoJSON processed output
CSV
Shapefile
GeoJSON
GeoPackage
ESRI File Geodatabase
GML
ZIP archives
ESRI feature services
Access methods
Browse source definitions in the official OpenAddresses GitHub repository.
Use the official Batch API to list collections and retrieve processed data where access is available.
Use documented S3 requester-pays links when appropriate and authorized.
Process individual sources locally with the OpenAddresses processing tools and Docker-based workflow.
Inspect source-specific publisher portals for the original data, metadata, and license terms.
Quality and limits
No universal global completeness, accuracy, or freshness guarantee is provided.
Upstream sources differ in address definitions, coordinate placement, field completeness, spatial precision, and publication practices.
Multiple sources may overlap, creating duplicate or near-duplicate address records.
An address point may not represent a building entrance, parcel centroid, postal delivery point, or legal site boundary consistently across jurisdictions.
Source licenses and attribution requirements vary; processed output should not be assumed to have one project-wide redistribution license.
A successful processing result does not prove that the upstream data is authoritative, current, or error-free.
Analysis workflows
Select the jurisdiction and source definition, then record the upstream publisher, source URL, license, date, and processing version.
Download a targeted collection or source rather than assuming that a global extract is necessary.
Load line-delimited GeoJSON into a spatial database or GIS and build indexes on geometry and normalized address components.
Validate coordinate reference systems, geometry validity, missing address components, duplicate identifiers, and extreme spatial outliers.
Use address points in geocoding, reverse geocoding, administrative joins, parcel and building joins, service-area analysis, and infrastructure proximity studies.
Compare address coverage with roads, buildings, parcels, population, or other geographic layers to identify gaps and source mismatches.
Retain provenance when deduplicating or merging records, and report counts by source and jurisdiction rather than treating all records as one homogeneous inventory.
For high-consequence or operational applications, verify results against the authoritative local publisher and document the acceptance criteria.
Value inside EDK
What OpenAddresses contains
OpenAddresses describes itself as a global collection of address, cadastral parcel, building-footprint, and street-centerline data sources. The project repository primarily stores source definitions: structured files that identify an upstream dataset, explain how to access it, and map its attributes into a common processing model. Address sources are organized by country and region, which reflects the project’s underlying design: the available data is assembled jurisdiction by jurisdiction rather than generated from one global authoritative register. (github.com)
For address layers, the standardized output can include number, street, unit, city, district, region, postcode, identifier, and accuracy fields. The geometry is inherited from the source and may represent an address point, parcel-related point, building-related point, or another publisher-defined location. Because the original sources differ, an identical field name in the processed output does not necessarily mean identical semantics or precision everywhere. (github.com)
- •Common address attributes: number, street, unit, city, district, region, postcode, id, and accuracy.
- •Potential related layers: cadastral parcels, building footprints, and street centerlines.
- •Coverage is assembled from individual national, regional, county, municipal, and other public sources.
- •Coordinates and attribute meaning remain dependent on the upstream publisher and its data model.
Geography, temporal coverage, and update cadence
OpenAddresses is intended to have global reach, but “global” describes the scope of the collection rather than guaranteed complete coverage. A country may have several regional sources, a single national source, or no suitable open source represented in the project. Even within one jurisdiction, address points may cover only certain address classes, publication areas, or update vintages. Users should inspect the individual source definition and publisher documentation before treating a region as complete. (github.com)
There is no single universal observation date or freshness value for the entire dataset. The project documentation describes a weekly production pipeline for processing sources, but that is not the same as every upstream source being updated weekly. A source may be refreshed by its publisher daily, annually, irregularly, or not at all. The correct temporal description is therefore source-specific: record the upstream publication date, the OpenAddresses processing date when available, and the date on which the data was downloaded for analysis. (github.com)
- •Geographic scope: potentially worldwide, with uneven jurisdiction-level coverage.
- •Update cadence: the processing system has been documented as weekly, but upstream source freshness varies.
- •Temporal metadata must be checked per source and per download.
- •No evidence establishes a single global completeness percentage or universal currentness guarantee.
Formats and access methods
The OpenAddresses source catalog can point to direct downloads such as ZIP archives, CSV files, Shapefiles, GeoJSON, File Geodatabases, and GeoPackages. It can also reference ESRI feature services. The processing system uses GDAL/OGR-based workflows to read source formats and apply a source-specific conform mapping. (github.com)
Processed address results are commonly written as line-delimited GeoJSON, with a standardized property structure. The processing workflow may also produce a preview image, PMTiles map preview, processing log, and machine-readable state summary. These auxiliary files are useful for checking extent, feature counts, processing problems, and visual plausibility before loading the data into a production pipeline. (github.com)
- •Source inputs: CSV, ZIP archives, Shapefile, GeoJSON, GeoPackage, File Geodatabase, GML, and ESRI services.
- •Standardized processed output: line-delimited GeoJSON.
- •Additional artifacts may include logs, previews, PMTiles, and state summaries.
- •Access routes include the source repository, batch collections, processed downloads, and local processing tools.
Suitable GIS and spatial-analysis workflows
The most direct use is address search and geocoding preparation. Load the standardized output into a spatial database or GIS, preserve the original source and processing metadata, normalize text fields for search, and index both address components and geometry. For reverse geocoding, spatially index the points and compare a query coordinate with nearby records, while returning a confidence or source-quality indicator rather than implying that the nearest point is always the correct address.
OpenAddresses is also useful for spatial joins. Analysts can join addresses to administrative boundaries, census areas, parcels, building footprints, roads, transit stops, service areas, flood zones, or environmental observations. Before joining, check coordinate reference systems, geometry validity, duplicate records, multipart or stacked addresses, and whether the address point is positioned at a parcel centroid, building entrance, driveway, or another local convention.
- •Geocoding and address search: index normalized address components and point geometry.
- •Reverse geocoding: search nearby points while retaining source and accuracy context.
- •Spatial joins: connect addresses to parcels, buildings, roads, administrative areas, hazards, and public assets.
- •Coverage analysis: compare address density with building, road, or population layers.
- •Quality control: inspect duplicates, missing components, invalid geometries, outliers, and source-vintage differences.
License, strengths, and tradeoffs
OpenAddresses does not apply one universal license to all processed geographic data. The project states that data produced by its processing pipeline is not relicensed from the original sources, and that individual sources retain their own licenses. The source-definition files in the repository are dedicated to the public domain under CC0, while the repository’s other code is separately licensed. Users must therefore review the license and attribution requirements for each upstream source before redistribution or commercial use. (github.com)
Its principal strength is aggregation: a developer or analyst can discover many otherwise scattered address sources through one catalog and work with a more consistent field structure. Its principal tradeoff is that standardization does not eliminate upstream differences. The same field may have different completeness, positional meaning, update age, or legal conditions in different places.
- •Strength: broad discovery of open address and related geospatial sources.
- •Strength: standardized address-oriented fields simplify cross-source GIS workflows.
- •Strength: supports both bulk data use and source-level local processing.
- •Tradeoff: coverage is uneven and cannot be assumed complete for every country or city.
- •Tradeoff: source licenses and attribution obligations remain jurisdiction- and dataset-specific.
- •Tradeoff: freshness, accuracy, duplication, and positional conventions vary across publishers.
Questions teams ask
Is OpenAddresses a complete global database of every address?
No. OpenAddresses has global scope as a collection, but coverage is assembled from individual sources and varies by country, region, publisher, address type, and data vintage. The project does not establish that every address is present or current. Treat it as a source discovery and processing ecosystem, then validate important results against authoritative local data. (github.com)
What format should I use for GIS analysis?
Processed results are commonly available as line-delimited GeoJSON, which can be loaded into GIS software, spatial databases, and data-processing libraries. Source inputs may use CSV, Shapefile, GeoJSON, GeoPackage, File Geodatabase, GML, ZIP archives, or ESRI services. Choose the processed file for convenient standardized use, or work from the original source when you need publisher-specific fields and provenance. (github.com)
Can I use OpenAddresses data commercially?
There is no single answer for the entire project. OpenAddresses states that processed data is not relicensed from the original sources and that individual sources have their own licenses. Review the license and attribution requirements attached to each source before commercial use, redistribution, or incorporation into a product. (github.com)
How often is OpenAddresses updated?
The project documentation describes a weekly production pipeline, but that should not be interpreted as weekly freshness for every address record. Upstream publishers control their own release schedules, and some sources may be updated irregularly. Record the source publication date and processing or download date for any analysis where freshness matters. (github.com)
Keep exploring
geonames
GeoNames complements address data with global place names, feature classifications, administrative relationships, and gazetteer search workflows.
google open buildings
Google Open Buildings provides machine-detected building footprints that can be compared with or joined to address points for settlement and coverage analysis.
gtfs analysis workflow
GTFS adds transit stops, routes, schedules, and service geography that can be analyzed around address locations.
Sources
OpenAddresses GitHub repository README
Official project overview, scope, source catalog description, and licensing distinction between source data, source definitions, and code.
Open sourceOpenAddresses Development Guide
Official technical documentation for source definitions, supported input formats, standardized fields, processing behavior, outputs, and pipeline context.
Open sourceOpenAddresses Batch API documentation
Official API documentation for collections, processed downloads, authentication, and requester-pays access.
Open sourceOpenAddresses Dedupe repository
Official project code and documentation illustrating address matching and deduplication workflows.
Open source