The reason for this switch is that special case logic is needed to determine the US state name to display. All other fields can be looked up by name.
The burden of fallback functionality is now in `helper/labelSchema` so the burden of unit testing is now in `test/unit/helper/labelSchema.js`
Instead of checking if the source/layer combination for geonames is
valid, always use the geoname type if the source is set to geonames,
regardless of which layer is in the gid.
This helps us better handle the case where people directly take gids
from our API responses.
Note: this functionality shouldn't be permanent and should be removed
once our new source/layer mapping system is in.
The parameter in clean.types being set by `helpers/text_parser.js` was
"from_address_parsing", but the code in `helper/types.js` was expecting
"from_address_parser". This commit makes both use "from_address_parser"
and adds a test.
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.
Quite a few of our tests simply had old error messages as expectations,
or expected output in an array that was correct but in the wrong order.
Those are all fixed.
We can't distinguish between geonames of different layers due to an
ambiguity in our Elasticsearch schema that we unfortunately won't be
able to fix for a few weeks.
So, while it's technically true that there are countries, cities, etc
contained in the geonames dataset, it's still better for now to remove
geonames from these layers. We have good coverage of most coarse layers
from quattroshapes alone, so the impact isn't too bad.
This simply reuses the focus:point:{lat|lon} variables, but sets them
using the centerpoint of the viewport. Eventually we should calculate a
radius and use that here.