Portland, OR Bldg import

From OpenStreetMap Wiki
Jump to navigation Jump to search


Please do not attempt to import any features without first consulting the main contacts below.

The goal of this import is to add building and associated address data from publicly available datasets in the Portland, OR USA, metropolitan region. This region includes not only the city of Portland but 24 other cities in Clackamas, Multnomah, and Washington counties.

The Github repository for all code is here: https://github.com/pdxosgeo/pdxbldgimport, as well as issues and project tasks.

The scripts and code for creating the data are intended to generate OSM files that will be validated and imported on a quarter-section by quarter-section basis.

A data sample can be found here: https://github.com/pdxosgeo/pdxbldgimport/blob/master/sample_osm_files/1n2e34d.osm

Pdxbldgimport-josm.png Sample data in JOSM.


Main contributors/organizers of this project:

  2. Darrell Fuhriman : User page
  3. Rafa Gutierrez: User page
  4. TC Haddad : User page
  5. Mele Sax-Barnett : Wiki page - User page

Though PDX-OSGEO is organizing the import, the import is a joint effort with MaptimePDX, City of Portland staff, Metro GIS staff, TriMet, and other local OSM contributors.

How can I help?

We need technical help with validation and script updates as necessary and documentation help.

Technical help

  1. Data processing
  2. Importing. OpenStreetMap account required (Create one here)

Documentation help

  1. Help update this project page; OpenStreetMap Wiki account required (Create one here)
  2. Write docs about importing
    • Working with the building and address data
    • Setting up and using JOSM
    • Setting up and using OSMLY
    • In-person training
    • Anything else users need to know

Source data


Data is provided by Metro. The datasets:

  1. Building Footprints: http://rlisdiscovery.oregonmetro.gov/?action=viewDetail&layerID=2406
  2. Address points: http://rlisdiscovery.oregonmetro.gov/?action=viewDetail&layerID=656

The Building Footprints dataset will be referred to as "bldgs". The Address Points dataset will be referred to as "addrs".

The addrs data set will be used to get address components without having to parse the address field in the bldgs data.


These Metro (RLIS) datasets are made available under ODbL, see: http://www.oregonmetro.gov/sites/default/files/Open_Database_and_Content_Licenses.pdf . Moreover, one of the reasons why Metro staff chose this license was to help make it compatible with OSM imports.


The general process for importing data is described below.

Data processing

  1. Import building and address data into PostGIS
  2. Convert address data to OSM format (expanded abbreviations, etc.)
  3. Import existing OSM buildings (building=*) into the database
  4. Any new building footprints which intersect existing buildings will, for now, be ignored
  5. Tags will be created for each building as below

Tag Mappings

tag source
addr:housenumber addrs.house
addr:street addrs.str_predir_code + addrs.street_name + addrs.street_type_code + addrs.str_postdir_code
addr:postcode addrs.zip_code
addr:city addrs.city
building:levels bldgs.num_story
building See discussion below
ele bldgs.surf_elev converted to meters, rounded to cm)
height bldgs.max_height

Building Types

The bldgs dataset contains a column representing the use of the building "BLDG_TYPE". The corresponding building= tag will be set as follows (based on http://wiki.openstreetmap.org/wiki/Key:building):

source value final value
House detached
Garage garage
RES, Res residential
Duplex, Apartment Complex, Multiplex, Residential Condominiums apartments
Dormitories dormitory
Everything else (the vast majority) yes


Addresses are connected to a building through a taxlot id. In the vast majority of cases, this is a 1:1 mapping, however there are some cases where there are many addresses associated to a property containing many buildings.

Some buildings have multiple addresses associated with them. Where this is the case, the addresses will be assigned to nodes inside the building polygon. No addresses will be assigned to the building, since there is no way to determine which, if any, of them is the "primary" address.

In the case where there are multiple buildings and multiple addresses, with no way to distinguish, then a site boundary will be generated, and nodes will be created inside that polygon, but not on any given building. If for some reason that is not possible, then no addresses will be assigned at that time.

Import Plan

Phase 0: Preparation

  1. Contributors/importers will create separate accounts followed by their normal usernames + "_pdxbuildings" for import purposes.
  2. We will hold a training and provide documentation for people who want to contribute
  3. Buildings will be extracted into consolidated quarter-sections (of at least 500 buildings each, at most 1400) and converted into .osm format, with three outputs:
    • Only those that DO NOT overlap with existing OSM data and have a single address
    • Only those that overlap with existing OSM data or have multiple addresses (to use in Phase 2)
    • All buildings

Phase 1: The easy stuff

  1. This phase will only deal with buildings that do not overlap with other features in OSM and have one (or no) address, or simple one building on one taxlot with multiple addresses
  1. Contributors will download a section of buildings, and a section of address nodes and validate it in JOSM, verify them with local knowledge & against the most recent imagery available; likely NAIP imagery with Bing as a fallback.

Please note: satellite imagery can have significant positioning errors versus more accurate surveys. Much of the building data is generated from high accuracy LIDAR surveys, so take care when considering changing the position of a building based on imagery.

  1. After validation, the changeset for that section will be uploaded by the contributor with a commit message that indicates it is part of this project
  2. Contributors will adhere to a strict limit of features edited per hour to be determined with consultation of the OSM Imports-us group.

Phase 2: Reconciliation with existing buildings/addresses

This phase will involve conflating data to be added to buildings that already exist in OSM and dealing with any complex addressing issues.

A draft of the code for this is available in the github repository. It finds OSM buildings with no addresses, then looks up the appropriate address in the addr data using a spatial query, then commits it to OSM. This is done with 50 addrs in one change set, all located nearby each other. As of 2014-11-14, there are ~4000 addresses included.

The current draft of code only handle 1:1 building to addresses.

Phase 3: Handling multiple addresses on multiple buildings

We will make additional proposals and obtain approval from the OSM Imports-us group and OSM Data Working Group for any further work before proceeding. We are planning on having contributors use OSMLY for this phase.

Maintenance Plan

Contributors to this project are (and should be) Portland-area community members with an interest in keeping the data up to date. We have an active mapping community where some of this upkeep can be done: