Filtering address candidates to my state, incoporated places using the ESRI geocoding

[TracySchloss]

I'm using single address input to the World geocoding service, and I'm having a hard time filtering the candidates to what seems like the most likely.  I see there is a field called "region", so I worked out how to reject a candidate that isn't in my state.  Then I realized there were some place names that were getting returned more than once.  There are both incorporated and unincorporated locations getting returned.  Each has as score of 100.  One looks like it might have come from an old quad.  It's completely in the middle of nowhere and to me it has no business at all even showing up as a match.

Then I see there is also a city attribute.  Only the incorporated town has a value in the city attribute.  Ok, so maybe there is something work with there, but it's turning into a lot of filtering!

Before I write a chunk of code to filter for everything I obviously need to account for, has some got something written for processing geocoding results that handles this scenario?

[JonathanUihlein]

I don't have much to add to this thread other than I too have experienced frustration at the seemingly random order of potential candidates returned by the Geocoder service.

They are returned in the order that the Geocoder deems 'most likely' which can often be completely wrong for a multitude of reasons (I am not on the Geocoding team or I would go into more detail).

PointAddress is supposed to be the 'most accurate' category, followed by StreetAddress.

As you noticed, two results can appear to be exactly the same but differ in this specific category.
Ideally, a PointAddress suggestion is returned first.

[JeffRogers]

Thanks to all who have contributed to this thread.  It looks like there is interest in better methods for filtering geocoding results.  Much of this thread is tied to the Esri geocoding fallback strategy.  If an address such as 380 New York Street Redlands California isn't matched at the point address or street address level then there is an interest in identifying this and ignoring the fallback results which might land at a postal code or city match. In these cases (postal code or city) the Esri geocoder provides a 100% match score for the postal or city part of the match, but not an overall confidence for the full address match relative to what it matched to. 

So, two things the Geocoding team are working on to help "address" these challenges. 

First we're developing a new parameter for the World Geocoding Service API.  The "Category" parameter will support service side filtering of results.  You'll be able to make a fine grained request to return a street address match or a city or postal code match, or any combination of address levels.  The parameter will be supported by a detailed set of categories for filtering across address, place and POI searches.  This should help reduce post filtering in your applications. 

One other area we are looking at is developing an overall confidence score for a match.  If the input is 380 New York Street Redlands CA, and the match is to Redlands CA, we could return a an overall confidence confidence score scale such as 47%.  So we would be (100%) confident that we matched to the city of Redlands but less confident 47% that we matched to the full input address.

We're interested if you think this would help with your current challenges or if there are any other ways you think we could improve filtering of results.

Esri Geocoding Team