OpenAddresses Analysis Workflow: Global Address and Location Data for GIS
OpenAddresses is a community-maintained collection and processing system for openly available address, parcel, building-footprint, and street-centerline sources from around the world. It does not create one uniform global address database with a single license or guaranteed level of freshness. Instead, it catalogs source data, maps local fields into a common schema, processes the sources through a recurring batch pipeline, and publishes downloadable regional, country, and source-level outputs. A sound OpenAddresses analysis workflow therefore treats the project as both a discovery layer and a normalization pipeline: identify the relevant source, inspect its provenance and license, obtain the processed output or original source, validate its geometry and attributes, and then join it to the other geographic data needed for the analysis.
OpenAddresses is useful when a GIS project needs address points or related location data across jurisdictions that publish information in different formats and schemas. Its repository contains source definitions organized by country and region. Each definition identifies where the source can be downloaded, what protocol or file format it uses, and how its attributes should be mapped into OpenAddresses fields. The processing system supports address data as well as parcel boundaries, building footprints, and street centerlines. The result is a practical bridge between fragmented local data portals and reproducible geographic analysis—but it is not a substitute for checking the originating authority, vintage, completeness, or legal terms of each dataset.
How EDK fits
For: GIS analysts, geocoding and location-data engineers, civic-data teams, researchers, cartographers, and developers who need open address or place-location data across multiple jurisdictions.
OpenAddresses is relevant to the physical-world problem because addresses provide a human-readable link between geographic coordinates and real places: buildings, parcels, roads, facilities, and neighborhoods. Its main contribution is not a universal world model, but a structured way to discover and normalize many local sources that describe those places. In an E2-style world-model workflow, OpenAddresses can serve as one input for locating named or numbered places, resolving address attributes to physical coordinates, and connecting address records to other geographic features such as roads, buildings, infrastructure, public assets, environmental layers, or administrative regions. The important distinction is that OpenAddresses supplies selected source-derived location records; the broader task of understanding and computing over the physical world still requires combining those records with additional spatial data and validating how well each source represents the place at the time of analysis.
- •Address-to-feature linkage: use OpenAddresses points or normalized address attributes as one input for connecting human-readable locations to buildings, parcels, roads, public assets, service requests, infrastructure, or environmental features in a broader geographic analysis.
- •Coverage and proximity analysis: combine address records with geographic computation such as nearest-feature searches, counts by region, distance bands, service-area analysis, or spatial aggregation. The OpenAddresses layer supplies the locations; the surrounding world model supplies the contextual features and computation.
- •Source-aware place discovery: use the project’s country and regional organization to find candidate address sources before comparing them with other geographic references such as gazetteers, census boundaries, street networks, or imagery. The result should be treated as a documented evidence chain rather than an assumption that every address is current or complete.
Dataset profile
Formats
GeoJSON, including compressed GeoJSON downloads
ZIP archives for regional and collection-level distribution
CSV and Shapefile custom exports described by the API documentation
Source inputs including Shapefile, GeoJSON, CSV, XML, Esri File Geodatabase, and GeoPackage
Access methods
Browse collections and individual sources through the official OpenAddresses Batch data service.
Use the documented Batch API for data metadata, job history, exports, and downloads.
Inspect GitHub source-definition JSON files to identify upstream URLs, protocols, coverage, and field mappings.
Download and process individual source data when source-level provenance or a more current upstream release is required.
Use authenticated downloads or requester-pays cloud access where required by the service.
Quality and limits
No uniform global completeness standard; a jurisdiction may have partial, missing, or outdated coverage.
Source schemas and address semantics differ across countries and agencies.
Processing and normalization do not guarantee correct geometry, current attributes, or consistent positional meaning.
Some source licenses restrict redistribution, commercial use, derivative databases, or required attribution.
Pipeline dates are not necessarily the same as the observation or publication dates of the underlying sources.
Some records may contain nulls, duplicates, invalid geometries, malformed addresses, or uncertain unit and location semantics.
The dataset should not be assumed to represent legal property boundaries, ownership, postal deliverability, or a complete routable transportation network.
Analysis workflows
Select the relevant layer and jurisdiction, then inspect the source definition and originating authority.
Record source URL, authority, license, collection date, source vintage, coordinate reference system, and processing version.
Download GeoJSON or an appropriate collection archive, or retrieve the original source for source-specific validation.
Load the data into a GIS or spatial database while preserving raw attributes and provenance fields.
Validate geometry, coordinate reference systems, duplicates, null coordinates, identifiers, street names, house numbers, postal codes, and expected geographic extent.
Normalize only required fields while retaining original values and source identifiers for auditability.
Join address points to buildings, parcels, roads, administrative boundaries, imagery, transit stops, infrastructure, or environmental layers.
Use spatial tolerances and confidence rules when matching points to polygons or networks.
Aggregate counts, densities, proximity measures, or service areas only after checking coverage bias and source vintage.
Sample results against independent authoritative maps or local data and document exclusions, corrections, and uncertainty.
Value inside EDK
What the OpenAddresses analysis workflow contains
OpenAddresses is best understood as a catalog, schema-mapping system, and processing pipeline rather than a single homogeneous dataset. The project’s source definitions describe individual geographic data sources and map local fields into a common output structure. For address layers, the normalized fields can include house number, street, unit, city, district, region, postal code, identifier, and accuracy. The broader system also recognizes parcels, buildings, and centerlines.
The project’s current data service describes collections assembled from authoritative sources worldwide and exposes four supported layer categories: addresses, buildings, parcels, and centerlines. This makes OpenAddresses useful for more than geocoding. An analyst may use address points to locate properties, parcels to represent land units, building polygons to estimate structures, or centerlines to connect places to a transportation framework. The exact attributes and completeness still vary by source and layer.
- •Source definitions are organized by country and region and include download locations, protocols, formats, and field-conformance rules.
- •The processing code supports common inputs such as Shapefile, GeoJSON, CSV, XML, Esri File Geodatabase, and GeoPackage.
- •The output is normalized enough to support cross-source workflows, but normalization does not make local definitions, positional accuracy, or update history identical.
- •The project’s current service lists global and regional collections, including U.S. regional collections and a global collection, alongside individual source records.
Geography, temporal coverage, and update cadence
OpenAddresses has global ambition and sources from many countries, but its geographic coverage is not uniform. Some areas have national or statewide address sources; others have only selected municipalities, counties, cities, or specialized layers. A missing location in the collection does not prove that no local address data exists, and presence in the collection does not prove that all addresses in the jurisdiction are represented.
The batch project documents a weekly production schedule: source processing is scheduled on Friday, collection aggregation on Sunday, and map fabrication later on Sunday. The public data page observed during research listed collection updates dated July 26–27, 2026. Those dates describe the published collection build, not necessarily the vintage of every underlying source. Each contributing authority may publish on a daily, monthly, annual, irregular, or unknown schedule, and a source can remain unchanged while the overall OpenAddresses pipeline continues to run.
- •Geographic scope: worldwide in project scope, uneven by country and subnational jurisdiction.
- •Pipeline cadence: documented as weekly for the production pipeline.
- •Source cadence: varies by originating authority and is often not standardized across the collection.
- •Temporal interpretation: a newly processed file may still contain old or undated source data.
Formats, access methods, and licensing
The primary public access route is the OpenAddresses batch data service, which provides collection-level and individual-source information. The project documentation also describes API endpoints for data, job history, exports, and downloads. The API documentation states that GeoJSON downloads remain free for users, while CSV and Shapefile custom exports are associated with backer access. Some downloads require authentication, and direct cloud-storage access can involve requester-pays charges for sponsors or users who choose that route.
For local or reproducible processing, users can work from the source-definition repository. Each JSON source definition identifies the upstream data location and the conformance instructions used by the processing machinery. This is valuable when an analyst needs to inspect provenance, reproduce a source-specific workflow, or bypass a pre-aggregated collection in favor of the original authority’s release.
- •Common published output: GeoJSON, including compressed GeoJSON downloads at the job level.
- •Collection packaging: regional and country collections are distributed as downloadable archives.
- •Custom formats: API documentation identifies CSV and Shapefile export options under specified access conditions.
- •Source inputs: Shapefile, GeoJSON, CSV, XML, GDB, and GPKG are among the supported input formats.
- •License: source-specific; do not assume one universal OpenAddresses license for all data records.
A defensible GIS and spatial-analysis workflow
Start with the geographic question, not the download. Decide whether the project needs address points, parcels, building polygons, centerlines, or a combination. Then identify the smallest relevant source or collection and inspect its source metadata. Confirm the geographic extent, source authority, original publication date, coordinate reference system, field meanings, and license before importing the data into a spatial database.
Next, download the processed GeoJSON or obtain the original source when source-level detail is important. Validate geometry, coordinate reference system, duplicate identifiers, null coordinates, postal-code structure, street-name fields, and house-number fields. Do not infer that a point represents a building centroid, parcel centroid, entrance, or mailing location unless the source documentation says so. Address-point semantics differ substantially between jurisdictions.
- •Discovery: select the layer type, jurisdiction, source, vintage, and license.
- •Ingestion: preserve raw files and source metadata before transformation.
- •Validation: test geometry, coordinate systems, identifiers, duplicates, nulls, and attribute semantics.
- •Integration: join addresses to parcels, buildings, roads, administrative units, imagery, or other physical-world layers.
- •Quality control: sample records spatially and compare expected coverage with independent authoritative evidence.
- •Documentation: retain collection date, source date, source URL, processing version, transformations, and license notes.
Suitable GIS workflows and interpretation cautions
OpenAddresses is well suited to address-point mapping, address-density summaries, geocoding-support datasets, municipal coverage comparisons, parcel or building linkage, service-area studies, and place-based joins. It can also help identify where a project needs a local source that is not yet represented in a global location-data workflow.
It is less suitable as the sole foundation for legal cadastral work, emergency dispatch without verification, authoritative postal validation, current property ownership, complete global routing, or high-stakes decisions about whether a physical structure exists. A record can be absent because the local source is incomplete, the source definition failed, the jurisdiction does not publish the data openly, or the source has not been added. A record can also be present but stale, duplicated, mislocated, or semantically different from a similar record elsewhere.
- •Good fit: address visualization, geographic joins, coverage audits, place lookup, and regional aggregation.
- •Use caution: currentness, completeness, positional accuracy, unit-level interpretation, and cross-country comparability.
- •Not a substitute for: local cadastral authority, postal authority, legal parcel records, or a complete routable network.
Questions teams ask
Is OpenAddresses one global address database with one license?
No. It is a collection and processing system built from many local and national sources. The project states that processed data is not relicensed from the original sources, so each source’s license and attribution requirements must be reviewed separately.
How often is OpenAddresses updated?
The batch project documents a weekly production pipeline, with source processing and collection aggregation scheduled on recurring weekly jobs. That does not mean every address source changes weekly. The underlying authority may update daily, irregularly, rarely, or without a published schedule.
What file formats can I use with OpenAddresses?
The processing documentation identifies Shapefile, GeoJSON, CSV, XML, Esri File Geodatabase, and GeoPackage among supported source inputs. Public outputs commonly use GeoJSON, including compressed GeoJSON downloads, while the API documentation also describes CSV and Shapefile custom exports under specified access conditions.
Can OpenAddresses be used for geocoding?
It can provide address points and normalized address attributes that support geocoding or address-to-coordinate workflows, but it is not a universal geocoding service. Coverage, address semantics, freshness, and positional meaning vary by source, so results should be validated against the originating authority and the requirements of the application.
Does OpenAddresses include only addresses?
No. The current batch service lists addresses, building footprints, parcel boundaries, and street centerlines as supported layers. The availability and quality of each layer depend on the contributing sources.
Keep exploring
geonames analysis workflow
GeoNames provides a complementary global gazetteer and place-name reference layer for comparing named places, coordinates, administrative relationships, and address-oriented geographic records.
gtfs analysis workflow
GTFS can be joined with address points, buildings, and centerlines to analyze transit access, stop proximity, service coverage, and the geography of reachable places.
nhgis analysis workflow
NHGIS provides U.S. census geographies and historical statistics that can be joined to OpenAddresses records for demographic, housing, and place-based analysis.
Sources
OpenAddresses repository README
Authoritative project description, supported source types, repository structure, and explanation that processed data retains the licenses of original sources.
Open sourceOpenAddresses Development Guide
Documents source definitions, supported input patterns, field conformance, the weekly production schedule, collection generation, and processing architecture.
Open sourceOpenAddresses Batch data service
Official public data catalog listing supported layers, individual sources, and dated regional and global collections.
Open sourceOpenAddresses Batch API documentation
Documents data, export, job, and download endpoints, authentication requirements, GeoJSON availability, and custom export behavior.
Open sourceOpenAddresses Batch Machine
Authoritative processing documentation describing supported layers and source input formats such as Shapefile, GeoJSON, CSV, XML, GDB, and GPKG.
Open source