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.
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.