`/place` queries have been executing in a way where only the ID, but not
the layer, has been considered when returning records from
Elasticsearch.
It turns out this bug was introduced almost a year and a half ago in
https://github.com/pelias/api/pull/407. A little, relatively unimportant
bit of code was looking for a property called `layers`:
```
const cmd = req.clean.ids.map( function(id) {
return {
_index: apiConfig.indexName,
_type: id.layers,
_id: id.id
};
});
```
The correct property was `layer`, so no filtering on layer was done in
the resulting [mget](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-multi-get.html) query.
There was never an acceptance test for these sorts of queries, but there
is now one in https://github.com/pelias/acceptance-tests/pull/446. The
unit tests were enforcing the incorrect behavior.
Fixes https://github.com/pelias/pelias/issues/643
It turns out the _type parameter to the Elasticsearch
[multiget](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-multi-get.html)
API does not allow an array of possible values. We were depending on its
ability to search multiple types to allow searching for OSM nodes and
ways.
But, since this doesn't work we essentially have to do it ourselves.
There is also the problem that OSM nodes and ways share an ID space. So
a gid such as `osm:venue:5` could in theory correspond to 2 records.
It seems like the only nice thing to do in that case is return both
results.
This PR "unrolls" such queries. For example, in the case of
`osm:venue:5`, the sanitisers will return the following array of objects
to be turned into multiget queries:
```
[{
id: 5,
types: ["osmway", "osmnode"]
}]
```
Before, this would turn into a multiget query with only one entry, like
this:
```
{
"docs": [
{
"_index": "pelias",
"_type": [
" osmnode",
"osmway"
],
"_id": 5
}
]
}
```
now it would look like this:
{
"docs": [
{
"_index": "pelias",
"_type": "osmnode",
"_id": 5
},
{
"_index": "pelias",
"_type": "osmnode",
"_id": 5
}
]
}
TLDR you might get back more records from /place than the number of ids
you specified, but at least you will definitely get back what you are
looking for.
Refactor search and doc controllers to allow for post-processing middleware
to handle geojson and response sending. Allows for a much more flexible routing scheme.