Import pipeline for OSM in to Pelias
Clone or download
orangejulius Merge pull request #468 from pelias/greenkeeper/through2-3.0.0
Update through2 to the latest version 🚀
Latest commit ab1b56f Nov 7, 2018

This repository is part of the Pelias project. Pelias is an open-source, open-data geocoder originally sponsored by Mapzen. Our official user documentation is here.

Pelias OpenStreetMap importer


The OpenStreetMap importer handles importing data from OpenStreetMap into Elasticsearch for use by Pelias.

It includes logic for filtering to select only data relevant for geocoding, transforming it to match the Pelias data model, and augmenting the data as required.


See Pelias software requirements

Clone and Install dependencies

For instructions on setting up Pelias as a whole, see our getting started guide. Further instructions here pertain to the OSM importer only

$ git clone && cd openstreetmap;
$ npm install

Download data

The importer will accept any valid pbf extract you have, such as a full planet file (39GB+) from or You can use the included download script to obtain the desired pbf files as follows. In the configuration file you can specify which files are to be downloaded. They will all be downloaded to the imports.openstreetmap.datapath directory.

If no download sources are specified in the configuration, the entire planet file will be downloaded. Keep in mind this file is quite large.

$ PELIAS_CONFIG=<path-to-config> npm run download


In order to tell the importer the location of your downloads, temp space and environmental settings you will first need to create a ~/pelias.json file.

See the config documentation for details on the structure of this file. Your relevant config info for the openstreetmap module might look something like this:

  "imports": {
    "openstreetmap": {
      "download": [{
        "sourceURL": ""
      "datapath": "/mnt/pelias/openstreetmap",
      "leveldbpath": "/tmp",
      "import": [{
        "filename": "portland_oregon.osm.pbf"

The importer has the possibility to download or not the OSM venues. This ability is managed by the parameter "importVenues" as described below:

| key | required | default | description | | imports.openstreetmap.importVenues | no | true | set to true to include venues in the data download and import process |

Environment Settings

  • imports.openstreetmap.datapath - this is the directory which you downloaded the pbf file to
  •[0].sourceURL - this is the source URL of the pbf file to be downloaded
  • imports.openstreetmap.import[0].filename - this is the name of the pbf file you downloaded
  • imports.openstreetmap.leveldbpath - this is the directory where temporary files will be stored in order to denormalize osm ways, in the case of a planet import it is best to have 100GB free so you don't run out of disk.

PRO-TIP: If your paths point to an SSD rather than a HDD then you will get a significant speed boost, although this is not required.

Administrative Hierarchy Lookup

OSM records often do not contain information about which city, state (or other region like province), or country that they belong to. Pelias has the ability to compute these values from Who's on First data. For more info on how admin lookup works, see the documentation for pelias/wof-admin-lookup. By default, adminLookup is enabled. To disable, set imports.adminLookup.enabled to false in Pelias config.

Note: Admin lookup requires loading around 5GB of data into memory.

Running an import

This will start the import process, it will take around 30 seconds to prime it's in-memory data and then you should see regular debugging output in the terminal.

$ PELIAS_CONFIG=<path_to_config_json> npm start

How long does it take?

Ingestion time varies from machine-to-machine but as a general guide it takes about 7 minutes to import 125,000 points-of-interest & 140,000 street addresses covering the city of London on a quad-core 2.x GHZ machine with an SSD.

These counts are of records containing valid location names to search on, data which is not directly searchable by the end user is not imported.

If you are looking to run a planet-wide cluster like the one we provide for please see our documentation on full planet builds.


If you have any issues getting set up or the documentation is missing something, please open an issue here:


Please fork and pull request against upstream master on a feature branch.

Pretty please; provide unit tests and script fixtures in the test directory.

Code Linting

A .jshintrc file is provided which contains a linting config, usually your text editor will understand this config and give you inline hints on code style and readability.

These settings are strictly enforced when you do a git commit, you can execute git commit at any time to run the linter against your code.

Running Unit Tests

$ npm test

Running End-to-End Tests

These tests run the entire pipeline against a small PBF extract to assert that the individual units work as expected when wired together.

$ npm run end-to-end

Code Coverage

$ npm run coverage

Continuous Integration

Travis tests every change against all supported Node.js versions.

Travis CI Status


We rely on semantic-release and Greenkeeper to maintain our module and dependency versions.

Greenkeeper badge