Leave search ambiguous when parse is ambiguous between street & place

[blackmad]

This change was based on a suggestion by @missinglink to fix "wrigley field" - since field can be both a street suffix and a place suffix, perhaps we should not boost either place or street matches if the parser is unsure.

This change attempts to do that by checking if the top two parses are entirely tagged as a street and entirely tagged as a place, and if so, doesn't accept either parse and instead does a general subject search.

In reality, I had a hard time figuring out if a parse tagged the entire query - in the case of ', wrigley field ,' I couldn't figure out what signal code be used to understand that every token in the query had been tagged. So, as a proxy, this just checks that the top two parses annotated the same parts of the query as street and venue.

This has the nice benefit of helping phoenix airport - that is the only acceptance-test change from this patch (wrigley field works in both master & in this change after adding 'field' to place_names in parser).

(base) ➜  acceptance-tests git:(master) ✗ diff head.txt dev.txt 
1326,1330c1326
<   ✘ [9.2] "/v1/search?focus.point.lat=33.44155&focus.point.lon=-112.09721&text=Phoenix sky harbor": score 5 out of 6
<   diff:
<     name
<       expected: Phoenix Sky Harbor International Airport
<       actual:   Phoenix Sky Harbor International Airport Terminal 3
---
>   ✔ improvement [9.2] "/v1/search?focus.point.lat=33.44155&focus.point.lon=-112.09721&text=Phoenix sky harbor"
1767,1768c1763,1764
< Improvements: 5
< Fail: 115
---
> Improvements: 6
> Fail: 114
1771,1772c1767,1768
< Took 93360ms
< Test success rate 95.42%
---
> Took 107718ms
> Test success rate 95.41%

[blackmad]

this has some unit test failures I missed yesterday. closing for now.

[orangejulius]

I just stumbled upon this PR, I must have missed it when it was originally made.

While I can't comment on the technical approach (@missinglink , what do you think?), this does at least attempt to solve a legitimate scoring issue, which is that the API, when told by the Pelias parser an input is possibly subject or street, will construct a query that boosts streets far too much.

Even with substantial popularity boosts for Wrigley Field (from pelias/openstreetmap#531), the street still comes up first in results for this reason.

Maybe we re-visit this soon and figure out a way to finish it off? We would be looking pretty good on the Wrigley Field test if we can make progress on that last character: