4adf4b3dd7
renamed some queries to be quite a bit more informative, however it
wasn't obvious that these query names were used elsewhere in the code.
With those changes, no confidence score middleware was running, which
this should help fix.
In cases where several conditions are met, it is possible for results to
be returned from the API that are not sorted as they were intended.
These conditions are:
* over 10 results total were returned from Elasticsearch
* the interpolation middleware was called
* not all street results end up with possible interpolated address
matches, and some of those streets come before other interpolated
address records, necessitating a re-sorting of the results in the
interpolation middleware
In these cases, the ordering of streets as defined by Elasticsearch,
such as by linguistic match or distance from a focus point, will no
longer be respected in the results.
This is because Node.js's `Array.prototype.sort` uses an
[*un*stable QuickSort for arrays of size 11 or greater](https://github.com/nodejs/node/blob/master/deps/v8/src/js/array.js#L670).
The solution is to switch to a sorting algorithm that is always stable.
This ensures that whatever ordering was specified in the Elasticsearch
queries is observed, without any of that logic having to be duplicated,
and then possibly conflict.
Stable sorting is provided by the [stable](http://npmjs.com/stable) NPM
package.
because we have to treat the `city` value as a possible `borough` when not supplied, both `borough` and `locality` results must be preserved when no `borough` is explicitly supplied. For example, `city=Manhattan` must preserve both the borough of Manhattan in New York and the locality of Manhattan in Kansas.
- created `/component` route
- broke out trimByGranularityComponent but could conceivably be combined with existing
- added `address` support to text_parser
- added `component` sanitizer wrapper