Default postprocessors on EsriWGS are too strict.

[lliss]

Be default, if doing a gazetteer style search, the defautl postprocessors filter out everything.

To test:

Set up and run a new geocoder with EsriWSG:

pq = PlaceQuery(query='the white house', country='US')
result = geocoder.geocode(pq)

You should get a few responses from the raw response:

[<White House (-77.036428, 38.897928) EsriWGS>, <The White House (-122.633387, 45.57894) EsriWGS>]

But they get filtered out in /services/base.py

except Exception as e:
            upstream_response_info.set_success(False)
            upstream_response_info.errors.append(format_exc())
            return [], upstream_response_info
        if len(candidates) > 0:
            for p in self._postprocessors: # apply universal candidate postprocessing
                candidates = p.process(candidates) # merge lists
        return candidates, upstream_response_info

[KlaasH]

I ran into this again, trying to geocode localities and wondering why it doesn't return anything for e.g. "Philadelphia, PA". Seems preferable to me to have the default postprocessors be permissive and let users refine them if necessary. As it is, it's easy to assume that the underlying service is failing in cases where it's actually doing exactly what's desired but the results are getting dropped by the postprocessors.

The list of possibilities is here, but I'm not sure it makes sense to pick a subset to allow by default. Dropping the AttrFilter on locator_type from DEFAULT_POSTPROCESSORS altogether might make more sense.