tomtaylor
commented
4 years ago OK, so I've inspected the geojson in the sqlite database more thoroughly and it looks like the places that haven't been imported have is_alt set true:
# Holme Valley, works fine
sqlite> SELECT id, source, is_alt FROM geojson WHERE id = 1360754629;
1360754629|quattroshapes|0
# Huddersfield, doesn't
sqlite> SELECT id, source, is_alt FROM geojson WHERE id = 101750573;
101750573|quattroshapes|1
101750573|quattroshapes_pg|1
# Nuneaton, doesn't
sqlite> SELECT id, source, is_alt FROM geojson WHERE id = 101750471;
101750471|quattroshapes_pg|1
101750471|whosonfirst|1
# Sittingbourne, doesn't
sqlite> SELECT id, source, is_alt FROM geojson WHERE id = 101853501;
101853501|quattroshapes|1
101853501|quattroshapes_pg|1
101853501|whosonfirst|1
# Hackney, works fine
sqlite> SELECT id, source, is_alt FROM geojson WHERE id = 1158857273;
1158857273|gbr-datalondon|0It looks like this is expected behaviour with the whosonfirst importer.
I'm now thinking this might be an issue with how the SQLite distribution is generated... @missinglink it looks like you might be working on something related?
missinglink
I've just set up a test Pelias installation locally using Docker. I'm using this
pelias.jsonto load in the whole of the UK, and running the following commands:(I don't need street/address geocoding.)
Most of the places I'd expect to be present have loaded in fine, but I'm missing some places that should be present. For example: Nuneaton, Huddersfield, Sittingbourne. They all exist in my local WOF sqlite database, but aren't present in the ElasticSearch index. They work fine on the geocode.earth online tool.
Take Huddersfield. It's not in the ElasticSearch index:
While a sibling locality, Holme Valley, has loaded just fine:
I've run the
pelias import wofmultiple times, with no errors produced. And I've tried to flush the index too.Is there a way of debugging why they might not be getting loaded?