Hi folks.

I set up the importer and connected it to our elasticsearch cluster, the index was created, the mapping was configured to use the pelias-analyzer, all worked well. Now I tried a first import using the liechtenstein pbf from geofabrik. But even after 15 minutes, all I see is this:
2015-03-24T08:50:45.059Z - verbose: [admin-lookup:master] alpha3=0, population=0, popularity=0, admin0=0, admin1=0, admin2=0, local_admin=0, locality=0, neighborhood=0, timeTaken=0

Any pointers of what I could be missing highly appreciated.

Ensure we are handing 'semi-colon value separators' correctly.

http://wiki.openstreetmap.org/wiki/Talk:Semi-colon_value_separator

It seems some house numbers are actually lists of house numbers.

In this case it might be best to create multiple records for these entries due to the suggester being anchored on the left side of the input.

These records may also include interpolation information, which is worth looking in to.

ref: http://wiki.openstreetmap.org/wiki/Addresses#Multiple_buildings_for_one_housenumber
"Some mappers use addr:interpolation=* on a single object to indicate that its addr:housenumber=* is to be treated as a range rather than an atomic label (discussed above). There is not a consensus on whether this is appropriate."

eg: http://pelias.mapzen.com/doc?id=osmway:poi-address-way-236566013

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
          -1.456305,
          50.919062
        ]
      },
      "properties": {
        "name": "1;2;3;4;5;6;7;8;9;10 Pennine Road",
        "alpha3": "GBR",
        "admin0": "United Kingdom",
        "admin1": "City Of Southampton",
        "admin2": "Hampshire",
        "locality": "Southampton",
        "neighborhood": "Wimpson",
        "text": "1;2;3;4;5;6;7;8;9;10 Pennine Road, Wimpson, City Of Southampton"
      }
    }
  ],
  "date": 1414495445297
}

This importer still uses the old, elasticsearch-based administrative hierarchy lookup. Migrate it to the new admin-lookup for hopefully significant speed improvements. Note that, since it's not clear whether parsing is still the bottleneck (after the introduction of the fast pbf2json OSM parser), I'm not sure how much we should expect.

openstreetmap should create address objects as pelias-model Documents, like most of the other importers, because it'll allow us to use it with any of the Document-dependent streams (eg, address-deduplicator, admin-lookup).

Each point we import belongs to one of these features. It would be nice if we used all the tags that each of these osm nodes contain and add it to the pelias model document.

Obviously we need to change the schema to add a field called tags thats a hash or an array of all tags.

We could have another file weighted_tags.yml in a different repo where we can define what weight each tag value corresponds to.

   airport: 10
   railway: 10
   restaurant: 5
   tourism: 15
   ...

error constructing document model Error: invalid property
    at Document.setter [as setName] (/mnt/pelias/pelias-osm/releases/20150318110004/node_modules/pelias-model/util/model.js:54:24)
    at DestroyableTransform._transform (/mnt/pelias/pelias-osm/releases/20150318110004/stream/tag_mapper.js:34:17)
    at DestroyableTransform.Transform._read (/mnt/pelias/pelias-osm/releases/20150318110004/node_modules/through2/node_modules/readable-stream/lib/_stream_transform.js:184:10)
    at DestroyableTransform.Transform._write (/mnt/pelias/pelias-osm/releases/20150318110004/node_modules/through2/node_modules/readable-stream/lib/_stream_transform.js:172:12)
    at doWrite (/mnt/pelias/pelias-osm/releases/20150318110004/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:237:10)
    at writeOrBuffer (/mnt/pelias/pelias-osm/releases/20150318110004/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:227:5)
    at DestroyableTransform.Writable.write (/mnt/pelias/pelias-osm/releases/20150318110004/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:194:11)
    at write (/mnt/pelias/pelias-osm/releases/20150318110004/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:623:24)
    at flow (/mnt/pelias/pelias-osm/releases/20150318110004/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:632:7)
    at DestroyableTransform.pipeOnReadable (/mnt/pelias/pelias-osm/releases/20150318110004/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:664:5)
    at DestroyableTransform.emit (events.js:92:17)
    at emitReadable_ (/mnt/pelias/pelias-osm/releases/20150318110004/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:448:10)
    at emitReadable (/mnt/pelias/pelias-osm/releases/20150318110004/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:444:5)

reported by @heffergm

The current name trimming function is removing the trailing ) from the following name:

http://www.openstreetmap.org/node/1860663376

I've been running a series of benchmarks on this importer, and it seems like stream/osm_types can be re-architected for a significant speed improvement. The stream currently accepts a raw OSM record stream and forwards individual records into one of three sinks (node, way, and relation). It accomplishes that by creating three Transform streams, each of which has a separate filter function, and records are sent into each of these. Those filter streams then pipe() into their respective sink.

                          -> node filter -> node sink
                        /
raw osm records -> fork -> way filter -> way sink
                        \
                          -> relation filter -> relation sink

I tried an alternative approach, where the raw OSM stream first pipes into a node stream, which unpipe()s on the first way and pipes the OSM stream into the way stream, which then unpipes on the first relation and pipes the OSM stream into the relation stream. Looks like this:

var nodeStream = through.obj( function write( data, _, next ){
  if( data.type === 'way' ){
    this.emit( 'ways' );
  }
  this.push( data );
  next();
});
nodeStream.on( 'ways', function (  ){
  console.log( 'ways' );
  parser.unpipe( nodeStream );
  parser.pipe( wayStream );
});
nodeStream.pipe( osmFilter() ).pipe( devnull );

var wayStream = through.obj( function write( data, _, next ){
  if( data.type === 'relation' ){
    this.emit( 'relations' );
  }
  this.push( data );
  next();
});
wayStream.on( 'relations', function (  ){
  console.log( 'relations' );
  parser.unpipe( wayStream );
  parser.pipe( relationStream );
});
wayStream.pipe( osmFilter() ).pipe( devnull );

var relationStream = through.obj( function write( data, _, next ){
  this.push( data );
  next();
});
relationStream.pipe( devnull );
parser.pipe( nodeStream );

Importing the full planet with only osm_filter (ie no osm_mapper, no elasticsearch sink, etc) took 61326 seconds (17 hours) with the old version, and 32246 seconds (9 hours) with the above version. Granted, that's all relative, but worth looking into.

cc @missinglink

Since the admin-lookup requires some additional setup (namely, downloading Quattroshapes, which is pretty formidable at ~540mb, and putting it in the right location), it should be made optional as a form of advanced usage so that the importer will just work with minimum setup. This would conform to the way that pelias/openaddresses handles it.

There are some errors in openstreetmap which should be ignored to avoid odd results because the name field is a number and the record doesn't contain address info.

Eg. https://www.openstreetmap.org/way/107577194#map=18/1.33583/103.72467&layers=TN

These can be filtered by simply checking if !isNaN(name)

OSM has 3 data types:

• Nodes (points)
• Ways (very british shapes)
• Rels (Bags of metadata that can be used to group nodes + ways)

We do not import rels at all. Rels are very important and useful. They have data applied to aggregate complex geometries, or networks, and have their own schema definitions to define the magic powers that each kind of rel can confer.

Do we really need this?

Autocomplete:

Search:

Yes.

Since the landing of pelias/api#61 and all the work @sevko has done on the address data it makes sense to move the OSM address data to address types.

Currently the address records which are extracted from the tags of nodes/ways end up in the pelias/osmnode or pelias/osmway types relatively.

There are hangings references to lots of old, merged branches. They should be removed.

When loading the planet, node does not exit when data processing has completed.

The link to your pre-processed quattroshapes seems to be broken: http://data.mapzen.com/quattroshapes/quattroshapes-simplified.tar.gz

Node process continues to run and output to stderr, but by all appearances no counters are incremented in the log, leaving the impression that there's no data left to process.

Sample extract where I've seen this: https://s3.amazonaws.com/metro-extracts.mapzen.com/rome_italy.osm.pbf

I am running the command "$ PELIAS_CONFIG=<path_to_config_json> npm start" from openstreetmap directory. Getting this error.

wordster@vpc-dev-es-02:~/sanket/openstreetmap$ PELIAS_CONFIG=pelias.json npm start

[email protected] start /home/wordster/sanket/openstreetmap
node index.js

/home/wordster/sanket/openstreetmap/stream/adminLookup.js:18
ipResolver = adminLookup.createWofPipResolver(config.imports.adminLookup.url);
^
TypeError: Cannot read property 'url' of undefined
at Object.createStream as adminLookup
at Object.streams.import (/home/wordster/sanket/openstreetmap/index.js:37:20)
at Object. (/home/wordster/sanket/openstreetmap/index.js:50:17)
at Module._compile (module.js:460:26)
at Object.Module._extensions..js (module.js:478:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Function.Module.runMain (module.js:501:10)
at startup (node.js:129:16)
at node.js:814:3

npm ERR! Linux 3.13.0-29-generic
npm ERR! argv "node" "/usr/local/bin/npm" "start"
npm ERR! node v0.12.7
npm ERR! npm v2.14.2
npm ERR! code ELIFECYCLE
npm ERR! [email protected] start: node index.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] start script 'node index.js'.
npm ERR! This is most likely a problem with the pelias-openstreetmap package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node index.js
npm ERR! You can get their info via:
npm ERR! npm owner ls pelias-openstreetmap
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR! /home/wordster/sanket/openstreetmap/npm-debug.log

http://www.openstreetmap.org/way/210679250
Urban Outfitters returns with neighborhood "Gold Cost" but it should say "Gold Coast". The search query for the Pelias API I used was http://pelias.mapzen.com/search?input=urban%20remains&lat=41.809148&lon=-87.618538&bbox=-88.30,41.430,-87.47,42.198&layers=poi,address

How much HDD space is required to export the whole planet osm file?

Currently the name is always formatted as street number + name, which is done here. However, many european countries have the number and street name swapped and we should be able to support this, preferably by a configuration switch.

some street addresses don't seem to be searchable:

eg: 130 dean street
google maps

[number 130] http://pelias.mapzen.com/suggest?input=130%20dean&lat=40.686386&lon=-73.988258
[number 134] http://pelias.mapzen.com/suggest?input=134%20dean&lat=40.686386&lon=-73.988258

Hi there,

I got a :
response: '{"error":{"root_cause":[{"type":"mapper_parsing_exception","reason":"analyzer on field [neighbourhood_id] must be set when search_analyzer is set"}],"type":"mapper_parsing_exception","reason":"Failed to parse mapping [_default_]: analyzer on field [neighbourhood_id] must be set when search_analyzer is set","caused_by":{"type":"mapper_parsing_exception","reason":"analyzer on field [neighbourhood_id] must be set when search_analyzer is set"}},"status":400}'

when creating the index, looks like the analyzer "keywords" set to neighbourhood_id is not known. Did I miss something there ? I'm on ES 2.2.0 by the way

Thank you

include tiger-specific postcode tags:

tiger:zip_left  60624
tiger:zip_right 60624

as per:

http://www.openstreetmap.org/way/24107355

In some cases the osm record is incorrectly tagged with the address data in the name field instead of in addr:housenumber & addr:street.

An example is this:
https://pelias.mapzen.com/doc?id=osmway:232045378
http://www.openstreetmap.org/way/232045378

The record above should ideally be in the osmaddress layer.

If we can upstream these fixes back to the openstreetmap database we should.

reported in: pelias/pelias#60

some docs have a prefix/suffix which indicates the venue has ceased business and closed down, we should discard these.

cases:
http://www.openstreetmap.org/node/3477294760
http://www.openstreetmap.org/way/24577106
http://www.openstreetmap.org/way/235975311
http://www.openstreetmap.org/way/302590301

.. there are likely more and more weird combinations of prefix/suffix lower/uppercase and with/without brackets

some OSM edits contain odd names such as Paris/Bosquet/81, is there anything we can do about these?

http://www.openstreetmap.org/node/3520025509

Relatively early in the ingestion process of planet.osm.pbf, the process fails with the following error:

FATAL ERROR: JS Allocation failed - process out of memory

This was the case using both osmium and osm-pbf-parser.

Some POIs have decent admin info, in such a case we can use the OSM tag info instead of quattroshapes.

eg. http://nominatim.openstreetmap.org/details.php?place_id=5993065191

index.js should be used strictly for exporting your package and shouldn't be directly executed. There should be an additional app.js / server.js file that requires the index.js and executes. That entry point then also serves as an example of usage for clients. I think this is the common expectation when looking at a node project and is based on the following. index.js is the default file used when requireing a directory, hence index.js makes sense as the main export point for a module. npm start will default to node server.js if a server.js file is found in the package root. So that means a separate entry point for execution is expected.)

We currently have this features whitelist which can be a little too inclusive sometimes.

eg. Taxiway 'U' at JFK, I doubt anyone will ever want to search this:
http://www.openstreetmap.org/way/5784731#map=17/40.65536/-73.78819
[edit] probably best to disable some of the aeroway tags but not all of them https://gist.github.com/missinglink/c74dc7a2ba34bfc4bdcb

This ticket is to revisit the whitelist from the 'old pelias' and give it a second look/ refresh.

My import pipeline for OSM runs smoothly until I reach the command to run an import.

$ node index.js

When that command is entered I receive this error:

vagrant@pelias:~/openstreetmap$ node index.js /home/vagrant/openstreetmap/node_modules/pelias-dbclient/node_modules/elasticsearch/src/lib/utils.js:356 throw new TypeError(err); ^ TypeError: Invalid apiVersion "1.7", expected a function or one of master, 1.x, 1.3, 1.2, 1.1, 1.0, 0.90 at Object._.funcEnum (/home/vagrant/openstreetmap/node_modules/pelias-dbclient/node_modules/elasticsearch/src/lib/utils.js:356:11) at new Client (/home/vagrant/openstreetmap/node_modules/pelias-dbclient/node_modules/elasticsearch/src/lib/client.js:66:29) at module.exports (/home/vagrant/openstreetmap/node_modules/pelias-dbclient/src/client.js:11:17) at streamFactory (/home/vagrant/openstreetmap/node_modules/pelias-dbclient/src/sink.js:8:56) at Object.osm.import (/home/vagrant/openstreetmap/index.js:37:12) at Object.<anonymous> (/home/vagrant/openstreetmap/index.js:42:13) at Module._compile (module.js:460:26) at Object.Module._extensions..js (module.js:478:10) at Module.load (module.js:355:32) at Function.Module._load (module.js:310:12)

Any help would be appreciated!

Thank you.

Railway:station
network:xyz (Ex: network:caltrain)
operator:xyz (Ex: operator: nymta)

at the time of import, if we know its a railway:station then add an alt name
name + ‘ station’ or 22nd street station

or use ‘network’ or 'operator' as well?

22nd street caltrain station 22nd street mta station

http://www.openstreetmap.org/node/2160213364

fixes pelias/acceptance-tests#66

such as this:
http://www.openstreetmap.org/relation/957239

they will need their own 'type' and can be used for hierarchy lookups

I use Pelias as a geocoder for people searching for addresses on Chicago Cityscape.
I constantly add new addresses to OpenStreetMap in the hope that they make it into Pelias quickly and can then be reflected in future searches on Chicago Cityscape.

Can you make a status page that shows when the last time Pelias's OSM planet was updated?

I know that you want to make changes happen more quickly, but it would make me feel better that I know an address change I made on X date will have appeared on Pelias because your status page would show that it updated the planet on a date after X.

Sorry if cross-posting here, I thought this would be addressed better here than in whosonfirst rep.

I successfully downloaded and imported whosonfirst data by:

npm run download -- --admin-only
npm start

When importing osm with "adminLookup": true , however, I see some errors:

2016-12-14T22:19:52.367Z - error: [wof-pip-service:loadJSON] exception occured parsing /home/pelias/data/whosonfirst//data/110/869/4417/1108694417.geojson: Error: ENOENT: no such file or directory, open '/home/pelias/data/whosonfirst//data/110/869/4417/1108694417.geojson'

This is just an example line, the error appears for a huge number of apparently wrong pathes.
What I observed is that the above path in deed does not exist, but an almost identical path with the last sub directory 4417 splitted in 2 sub directories. So the following path exists:

/home/pelias/data/whosonfirst//data/110/869/441/7/1108694417.geojson

so the file exists actually.

Nevertheless, OSM data gets apparently imported. Shall I ignore the error?

Once the schema is stable enough we can consider doing partial updates to the index instead of importing the whole OSM planet every time.

ref: http://planet.openstreetmap.org/replication/

Note: some investigation needs to be done about how these diffs work, for example:

• are only new tags shown, are deletions notated?
• how to handle node/way/relation deletions?
• are records complete? ie. do they contain a snapshot of the record or only a diff of the changes?
• etc..

ref: http://wiki.openstreetmap.org/wiki/OsmChange

We also need to come up with a strategy for elasticsearch as it does not support partial updates to documents (without scripting enabled) so we will most likely need to GET the record, modify it and PUT it back; which has potential to cause problems related to idempotency/atomicity/race-conditions.

Eg.

var osmium = require('osmium');
var file = new osmium.File("/tmp/209.osc.gz");
var reader = new osmium.Reader(file, { node: true, way: false });

var handler = new osmium.Handler();
handler.on('node', function(object) {
  console.log( JSON.stringify({
    type: 'node',
    id: object.id,
    lat: object.lat,
    lon: object.lon,
    tags: object.tags()
  }, null, 2));
});

osmium.apply(reader, handler);

As per the discussion in #52 and #53, this code should use Document getter methods if the doc variable is itself a Document instead of accessing properties directly (so, doc.getAlpha3() instead of doc.alpha3).

Change all logging throughout the code to use pelias-logger module.

This name contains leading characters that need to be removed:

name: {
  default: "'Round Midnight Jazz and Blues Bar"
}

Openstreetmap contains entities marked as place: city which are not imported in to Pelias because that tag is not listed in the features whitelist.

The following osm:node for Munich contains loads of great meta data. such as population info and translations.

Would it be worth importing these entities or linking them to the relevant Geonames or WOF records?

http://www.openstreetmap.org/node/1700534808

note: this description was updated and so the first 2 comments make less sense in context.

I have a .osm.pbf file in my $HOME/pelias/openstreetmap/data directory and my ~/pelias.json file also says the same directory... although when I npm start I get the pbf2json file missing error.

I have never seen this one before.

Rushendon Furlong (way:34243335)

http://pelias.mapzen.com/search?input=Rushendon%20Furlong&lat=51.8347677&lon=-0.6360745
http://pelias.mapzen.com/reverse?lat=51.8347677&lon=-0.6360745&size=40

http://www.openstreetmap.org/way/34243335

most likely not being imported due to tagged as "highway: residential" which is not in the feature list.

originally reported by @loomsen in #46

currently the pelias/config structure implies that a consumer can specify multiple pbf files to be imported; however the import script does not currently support this.

Thanks, all seems to be working fine now. However, I wonder if it's possible to import multiple pbf files?
I've tried adding another one into the json array file, but it doesn't seem to be imported. Only the first entry seems to be processed. If I import it afterwards, data from both show up, so this would work. Would be nicer to configure an array though.

      "import": [{
        "type": { "node": "osmnode", "way": "osmway" },
        "filename": "germany-latest.osm.pbf"
      },
      {  
        "type": { "node": "osmnode", "way": "osmway" },
        "filename": "liechtenstein-latest.osm.pbf"
      }]

we should not import railways as the centroid is not necessarily anywhere near a station!

eg. http://www.openstreetmap.org/way/46340228

this gives the impression you can find a station at the centroid, which is not true.

    {
      "type": "Feature",
      "properties": {
        "marker-color": "#00ff00",
        "id": "46340228",
        "layer": "osmway",
        "name": "BMT Broadway Line",
        "alpha3": "USA",
        "admin0": "United States",
        "admin1": "New York",
        "admin1_abbr": "NY",
        "admin2": "New York County",
        "local_admin": "Manhattan",
        "locality": "New York",
        "neighborhood": "Flatiron District",
        "category": [
          "transport",
          "transport:rail"
        ],
        "address": {},
        "text": "BMT Broadway Line, Manhattan, NY"
      },
      "geometry": {
        "type": "Point",
        "coordinates": [
          -73.990444,
          40.743142
        ]
      }
    },

Right now this is enabled whenever the info log level is set, however that feels like too much for regular info output. Maybe can be in debug, maybe it needs a separate setting in pelias-config like pelias/wof-admin-lookup#22

hi,

I trying to import osm data for mys city (pbf file) in ES.

i have a custom config file with only OSM.

when i execute "node index.js" i catch the following error.

2016-01-15T18:06:01.105Z - info: [admin-lookup:master] Initializing workers.
2016-01-15T18:06:01.259Z - info: [admin-lookup:worker:admin1] Loading `admin1`.
ShapeFileStream { [Error: ENOENT, open '/mnt/pelias/quattroshapes/qs_adm1.dbf']
  errno: -2,
  code: 'ENOENT',
  path: '/mnt/pelias/quattroshapes/qs_adm1.dbf' }
events.js:85
      throw er; // Unhandled 'error' event
            ^
Error: ENOENT, open '/mnt/pelias/quattroshapes/qs_adm1.dbf'
    at Error (native)
2016-01-15T18:06:01.290Z - info: [admin-lookup:worker:locality] Loading `locality`.
2016-01-15T18:06:01.296Z - info: [admin-lookup:worker:local_admin] Loading `local_admin`.
ShapeFileStream { [Error: ENOENT, open '/mnt/pelias/quattroshapes/qs_localities.dbf']
  errno: -2,
  code: 'ENOENT',
  path: '/mnt/pelias/quattroshapes/qs_localities.dbf' }
events.js:85
      throw er; // Unhandled 'error' event
            ^
Error: ENOENT, open '/mnt/pelias/quattroshapes/qs_localities.dbf'
    at Error (native)
ShapeFileStream { [Error: ENOENT, open '/mnt/pelias/quattroshapes/qs_localadmin.dbf']
  errno: -2,
  code: 'ENOENT',
  path: '/mnt/pelias/quattroshapes/qs_localadmin.dbf' }
events.js:85
      throw er; // Unhandled 'error' event
            ^
Error: ENOENT, open '/mnt/pelias/quattroshapes/qs_localadmin.dbf'
    at Error (native)
2016-01-15T18:06:01.317Z - info: [admin-lookup:worker:admin2] Loading `admin2`.
ShapeFileStream { [Error: ENOENT, open '/mnt/pelias/quattroshapes/qs_adm2.dbf']
  errno: -2,
  code: 'ENOENT',
  path: '/mnt/pelias/quattroshapes/qs_adm2.dbf' }
events.js:85
      throw er; // Unhandled 'error' event
            ^
Error: ENOENT, open '/mnt/pelias/quattroshapes/qs_adm2.dbf'
    at Error (native)
2016-01-15T18:06:01.343Z - info: [admin-lookup:worker:neighborhood] Loading `neighborhood`.
ShapeFileStream { [Error: ENOENT, open '/mnt/pelias/quattroshapes/qs_neighborhoods.dbf']
  errno: -2,
  code: 'ENOENT',
  path: '/mnt/pelias/quattroshapes/qs_neighborhoods.dbf' }
events.js:85
      throw er; // Unhandled 'error' event
            ^
Error: ENOENT, open '/mnt/pelias/quattroshapes/qs_neighborhoods.dbf'
    at Error (native)

Do you have seen this error before ?
And could you help me to solve them ?

thanks a lots for your great works.

harksin.

if( !val ){ throw new Error( 'invalid value' ); }
                ^
Error: invalid value
    at Document.setter (/mnt/pelias/pelias-osm/releases/20150317234057/node_modules/pelias-model/util/model.js:56:23)
    at Document.setLat (/mnt/pelias/pelias-osm/releases/20150317234057/node_modules/pelias-model/Document.js:136:16)
    at Document.setCentroid (/mnt/pelias/pelias-osm/releases/20150317234057/node_modules/pelias-model/Document.js:146:15)
    at DestroyableTransform._transform (/mnt/pelias/pelias-osm/releases/20150317234057/stream/document_constructor.js:18:11)
    at DestroyableTransform.Transform._read (/mnt/pelias/pelias-osm/releases/20150317234057/node_modules/through2/node_modules/readable-stream/lib/_stream_transform.js:184:10)
    at DestroyableTransform.Readable.read (/mnt/pelias/pelias-osm/releases/20150317234057/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:362:10)
    at flow (/mnt/pelias/pelias-osm/releases/20150317234057/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:629:52)
    at DestroyableTransform.<anonymous> (/mnt/pelias/pelias-osm/releases/20150317234057/node_modules/through2/node_modules/readable-stream/lib/_stream_readable.js:613:7)
    at DestroyableTransform.emit (events.js:92:17)
    at onwriteDrain (/mnt/pelias/pelias-osm/releases/20150317234057/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:300:12)
    at afterWrite (/mnt/pelias/pelias-osm/releases/20150317234057/node_modules/through2/node_modules/readable-stream/lib/_stream_writable.js:288:5)

reported by @heffergm

Relates to pelias/pelias#22