address_search_using_ids: point-based geometry issue

This issue came through via email so I thought I'd write it up, although I think the best course of action is to simply wait until the spatial service matures, then this issue will likely be resolved by buffering point-based geometries.

The example given in the email was 1 Tara Rd, Ennismore, ON.

Looking at the WOF data I can see that Ennismore exists but it's a point-based geometry.

This leads to unexpected behaviour in Pelias, what's happening here is that Placeholder is returning one match for 'Ennismore, ON', which in turn adds the following query clause to the address_search_using_ids query:

{
  "minimum_should_match": 1,
  "should": [
    {
      "terms": {
        "parent.locality_id": [
          "1125901201"
        ]
      }
    }
  ]
}

However, while Placeholder supports point-based geometries PIP does not!
As a result, the following query will never match anything because the ID 1125901201 could never be returned by PIP during indexing.

We could fix this fairly easily now by using the bbox property to determine if a Placeholder result is a point or not, but this would require us to choose between two strategies:

• continue the search but exclude the point-based IDs, this means that even though we know there is another place which could match, we will never return results from it
• abort the search, we would say that the ID parsing is problematic and so we would fall back to another type of query to resolve the search (this is the current strategy and so we're currently returning the Placeholder results)

I think that neither of these strategies are ideal, it would be much better if we were able to buffer point-based geometries inside the PIP service like this, albeit a wider radius to solve this specific issue.

The new Spatial service will allow us to return nearest-matches as well as a list of potential aliases for admin areas, we can also buffer point geometries so that this is no longer an issue.

No repository file or test is named. Start by tracing the address_search_using_ids query and the Placeholder/PIP interaction for the Ennismore ID 1125901201; done would require an agreed strategy for point-based geometries, likely involving the spatial service's buffering behavior.