There is no longer any ambiguity in the source field and the layer
(which is stored as _type), so a lot of logic to compute them can simply
read from the elasticsearch document. Hooray!
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`
Primarily as a performance optimization, but also to attempt to return
more relevant results, only admin and POI layers were queried when the
text input consisted of only one or two tokens, and there weren't any
numbers. However as shown in #194 that is a bit too optimistic, mostly
in contries other than the USA.
Fixes#194
This is just in a unit test, so it technically passes, but geonames is
not a valid layer option (geoname, singular, is used instead), so it's
best to correct.
The address parser currently does two things:
1.) make some intelligent guesses as to possible admin regions to
explicitly search against to improve the quality of results returned
2.) make some intelligent guesses as to when no part of the query needs
to search against anything other than admin regions. This somewhat
improves the quality of results returned but mostly improves the speed
of the Elasticsearch query since it's searching significantly fewer
recoords.
These two concerns are now split into two separate methods within the
query_parser helper module. They are mostly independent today, but don't
have to be in the future.
This code doesn't seem like it will be triggered very often (due to it
comapring space delimited words with comma delimited words from the text
field), and also has the potential to cause quite a bit of weird
behavior.