nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Finde mehr Beiträge mit dem Tag

Accepted answers

TracySchloss

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.

All comments

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

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.

TracySchloss

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

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

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

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?

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.

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 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.

RRubalcava

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.

Nimm an der Unterhaltung teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.