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?

[ReneRubalcava]

I've had some issues with the Geocoder as well.

My observations in testing

USA.PointAddress/USA.StreetAddress - Scores can very based on address, such as direction missing or not. These results seem to be acceptable.

USA.StreetName - Score is only based on the Street name of address, number is ignored, scores are pretty useless here. For example, if the street name was a perfect match, score is 100, address number ignored.

USA.Postal - Same as StreetName, if zip is a match, 100 score returned, Address number and Street name ignored.

So I would actually check the Loc_name field to see what part of the composite locator provided the result and try to filter that way. Otherwise the scores will amost always be 100 and the Status will almost always be a Match, regardless if the address was actually found.

I was actually thinking about posting this to the geocoder forum. I have a local composite locator we use in-house, but recently decided to use the Esri geocoder as a fallback for unmatched addresses and these issues came up. It has me rethinking of even using the Esri Geocoder in my apps because of the overhead of error checking.

Technically, that Locator, such as the Postal would find a match at 100%, since that's what it's designed for, but it's up to you to filter out the locators. I am unsure if there is a way to tell the service to only use certain locators in a composite locator.

[TracySchloss]

I always used to use score as a good place to start as to whether or not I think the match should be considered.  Often I got away with taking the first candidate that met a minimum score and that turned out to work pretty well.   I'm going to have to scrap that idea, based on my own experience and now your feedback.

I put in some comments/feedback into the North American Locator (or whatever was the most prominent 2-3 years ago), complaining then that some of the candidates getting returned had no business ever being there.  It seemed like it was better for a while.  Now I'm back to seeing places that aren't even a wide spot in the road coming back scored the same as towns.  I admit that many of the towns in Missouri are pretty small!  But they do have people looking for them compared to literally a cow pasture that I can see with the same name.  

If I come up with anything clever, I will post it.

[JohnGravois]

i definitely agree with Rene here.  if you only think of street-level matches as appropriate for display in your application, you should be disregarding the candidates returned by more coarse grained locators entirely.

[TracySchloss]

I'm not just using it for street level matching.  I'm using it for searching for a city as well as ZIP code.  I've been successful using ESRI's geocoding for this type of matching in the past.  I'm going to look harder at the locator names returned to see if that helps me sort through this.

[TracySchloss]

Update:

I did find that I could specify a search extent as an optional parameter to my locator.  I also added a filter to the returned candidates that just took me to my state.  This helps.  But there is what I would call 'bad data' in the locator, so I'm still getting one candidate that is the right one and one that is junk.

function locate() {
  map.graphics.clear();
    var address = {
    "SingleLine": dom.byId("txtAddress").value
  };
  locator.outSpatialReference = map.spatialReference;
  var options = {
    address: address,
    outFields: ["*"],
    searchExtent: startExtent
  };
  locator.addressToLocations(options);
}

Then in my results handler, I first filtered to my state, which took me down to just two candidates w/o too many lines of code.

         var MOcandidates = arrayUtil.filter(evt.addresses, function(candidate){
          return candidate.attributes.Region == "Missouri";
    });

I think I need to give feedback to whoever maintains the geocoding service.  Or maybe I'm supposed to be using the higher paid subscription in order to get better results?

[JohnGravois]

perhaps you could just share the request here and what you expect to be returned?

http://geocode.arcgis.com/arcgis/rest/services/World/GeocodeServer/find?text=Washington&f=pjson

[TracySchloss]

What's making me nuts on this is the inconsistency in the order of what is getting returned.  Sometimes it will find what I think is the top candidate first, and sometimes not.  This makes no sense to me.  I am searching for Salem, MO and Liberty, MO.  I would expect the incorporated towns by these names to come up as the first candidates.  Yesterday over multiple tries these incorporated places came up as the 2nd in the list of candidates.  Today they are first.  I used to think it was me not paying attention, but I've tried multiple times over different days and I can see the order is not consistent.  Is the ranking that supposedly determines the order generated on the fly?

Using the URL the way you have it is not the same way I've been going about it.  I'm using the addressToLocations method on the Locator, which generally returns multiple candidates, not just the one JSON formatted response.  Am I likely to get different results?

[JohnGravois]

tracy,
its hard to speak intelligently about what's happening in your application without seeing the request.  please consider using either fiddler or the network tab in your browser developer tools to isolate the request to the geocoding service and forward it along.

[TracySchloss · Accepted solution]

I decided there was something wrong with my logic or maybe my understanding on what was happening as I stepped through the returned candidates.  The way I looked at it, I assumed it would use the first candidate, assuming it matched my criteria of 'score > 80'.  Since all the scores seem to be 100 anymore, I eliminated that part of the code.

I also realized that I wasn't ending up with the 1st candidate, I was consistently getting the 2nd one. I changed my code to define my candidate as the first one in my filtered array and seems to be doing the trick.  Either that, or the service is returning something different today than it was earlier in the week!  It could be either or both.