This middleware looks at the list of types that will be sent to
Elasticsearch, if it's an empty array, it sends an error response before
Elasticsearch is even quieried, because Elasticsearch interprets an
empty type array as "search anything" rather than the intended "don't
search anything".
After refactoring, this flag is no longer needed, as all areas of the
code that care about layers do so by setting a key within clean.types,
and then the types helper intelligently combines those together later.
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 moves the list of types created by sanitising the layer API
parameter from clean.layers to clean.types.from_layers. In subsequent
commits, types created from address parsing, and the
yet-to-be-implemented source parameter will also live in the clean.types
object.
This will allow moving logic to set cmd.type out of controllers, and
into separate logic that can be a littler smarter. Also, it will no
longer require the clean.default_layers_set flag to be passed all around
like a nasty global variable.
This middleware looks at the list of types that will be sent to
Elasticsearch, if it's an empty array, it sends an error response before
Elasticsearch is even quieried, because Elasticsearch interprets an
empty type array as "search anything" rather than the intended "don't
search anything".
After refactoring, this flag is no longer needed, as all areas of the
code that care about layers do so by setting a key within clean.types,
and then the types helper intelligently combines those together later.
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 moves the list of types created by sanitising the layer API
parameter from clean.layers to clean.types.from_layers. In subsequent
commits, types created from address parsing, and the
yet-to-be-implemented source parameter will also live in the clean.types
object.
This will allow moving logic to set cmd.type out of controllers, and
into separate logic that can be a littler smarter. Also, it will no
longer require the clean.default_layers_set flag to be passed all around
like a nasty global variable.
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.
sanitiser/_geo.js
-Remove the code that verified `longitude` validity, to allow
longitude values outside of the value's real range, [-180, 180].
elasticsearch appears to handle them gracefully, so this
resolves#56.