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; } } }

Address does not match but then it does in rematching

JoeBorgione

Using ArcGIS Pro 2.7.2 and a composite locator.

I'm seeing what I feel is odd behavior when geocoding. (See image below). This address 9113 W MAGNA MAIN ST initially shows as unmatched, but there are two 100% match options available to me. What's up with that? I sure would hate to plow through 3500 'unmatched' records just to find out they really are valid...

@BradNiemand

This problem I've mentioned in the past has reared it's ugly head again, where you adjust an address in the Single Line Input field, only to be bounced back to record #1. The strangest thing about this is yesterday I didn't get this problem, and today, using the same locator but a different file of addresses I am...

and towards the end of the day...

Notice the address 3215 S Valley St went unmatched yet I can use the find tool with the locator I used (CityWorks2) and it hits on an address point...I have the locators set to Match With No Zones = YES....

Find more posts tagged with

Analysis

Content Management

Desktop

Accepted answers

All comments

JoeBorgione

@ShanaBritt I knew I had mentioned it more than once, but I'm at a loss as to how to search for posts I start.

Shana Britt

@JoeBorgione Just tying up ends here since you mentioned the jumping back to #1 in the Rematch Addresses Pane here, which is in our plans to address and can be tracked with BUG-000141513.

JoeBorgione

@ShanaBritt :

I am unable to replicate the problem now. The rematch process works just fine. I cannot explain it but I did do a re-install of ArcGIS Pro 2.7.2 because I encountered some problems after installing 2.8. Maybe I had a bad install? Stranger things have happened.

Some good news though: I believe I have isolated the problem when rematching and it returns you to the first record after you make an edit to the Single Line Input Just now I tried to rematch a selected set of records, and I was bounced back to #1 when ever I made an edit. If I clear the selection, I can adjust the Single Line Input and continue along.

The data I am trying to geocode has tons of records where the ADDRESS field is Null. If I first geocode the entire table I get something like 3500 unmatched records. I then select where ADDRESS is not Null and that leaves me with only 270 to rematch. That's manageable, but not so much if I'm constantly getting bounced back to #1.

JoeBorgione

Dusting this off @ShanaBritt ...

...then geocode the table of addresses using Single Field for the input address fields.

I misunderstood what you are suggesting here, thinking that I should create a locator with a single field of reference. When ever I geocode a table, that table has one field: ADDRESS and all the values are in the form of:

1234 S MAIN ST

4576 S MAIN ST # 101

I may have Null values here and there, but they typically are all filled correctly:

JoeBorgione

Hey @ShanaBritt - sorry, been going other things but I’ll give it a try sometime!

Shana Britt

@JoeBorgione Any luck with a locator built without city, state, or zip and geocoding with a single field?

JoeBorgione

@ShanaBritt ...geocode the table of addresses using Single Field for the input address fields. Ah ha. I see what you mean now. Single field, and not parsed address fields. I can do that.

...the recommended workflow when your input addresses don't have zones. I didn't know that; is that documented somewhere?

I'm just shutting things down for the week, but I'll try to do some testing next week and let you know.

Shana Britt

@JoeBorgione What I'm suggesting is that you build a locator w/o any zones (city, jurisdiction, zip), then geocode the table of addresses using Single Field for the input address fields. This is the recommended workflow when your input addresses don't have zones. There have been improvements to the locators built with the Create Locator tool since you could first build them in Pro 2.3. Below are my results where all 84 were matched.

If your input addresses have zones or an address could fall inside of multiple zones, it is best to build the locator with zones and batch geocode the address with zones or input the partial address and select the suggestion.

JoeBorgione

@ShanaBritt If I build a locator that requires some sort of zone, be it a city, county, zip, whatever and pass addresses to it without zones, I'm pretty sure I won't get any matches. That's what I discovered early on with the new style locators.

Shana Britt

@JoeBorgione If there is one and one only 1234 S Main S in the reference data used to build the locator, then building the locator w/o zones would be the suggested workflow. I'd be curious to see what your results are if you build a locator w/o zones and geocoded your table of addresses to see if you get different results than with the locator that was built with zones.

JoeBorgione

@ShanaBritt -

It looks like your input addresses have no zone info, but the locator was built with zones and the match with no zone setting set to 'Yes'. In my area of operation, I am blessed with a single address grid which means no address is repeated across zones. There is one and one only 1234 S Main S for example. Consequently, my M.O. for geocoding has always been to simply geocode the address and forget about jurisdiction or other zone. So it's only logical that when I create a locator the match with no zones setting = Yes. Brad and I have arm wrestled over this multiple times, and while I would like to see that property exposed to arcpy I don't anticipate that happening, at least between now and December 24, my anticipated retirement date. (Merry Christmas to me...)

I brought this up here in forum more or less as an FYI, and to see if anyone else has experienced it. I'll probably start a support case and I'll let you and Brad know when I do.

Shana Britt

@JoeBorgione It looks like your input addresses have no zone info, but the locator was built with zones and the match with no zone setting set to 'Yes'. I'm wondering if you would get different results if you built the locator w/o zones and geocode the addresses. When the locator is built w/o zones the "match with no zone" property is set to 'Yes' by default. Is the city info required for the match candidate? To fully investigate and determine why this unmatched behavior is happening we would need the reference data, locators, and sample of just the addresses w/o any identifying info. If you want to reach out to me with this info or log a new case with Support is up to you.

JoeBorgione

@ShanaBritt It doesn't appear to have any effect on them:

Stepping through them I see a few addresses that have unit numbers that are listed as unmatched but resolve:

and others that are unmatched, but show up with a good score and IMHO should have matched to begin with:

I have the locator properties to match without zones and a min match score of 85.

Shana Britt

@JoeBorgione When on the Unmatched tab in the Rematch Addresses pane, does clicking the Auto Rematch button match the unmatched addresses?

JoeBorgione

@ShanaBritt ; I can replicate the unmatched while geocoding but shows up during rematching with just a multirole locator only, not a composite:

JoeBorgione

@ShanaBritt - I will do a little more testing for you, but the initial problem was exposed in a composite locator.

The jumping problem is very weird; when I first re-matched the addresses, everything worked fine. Then I closed down for the day and when I picked up where I left off the next day, the problem manifested. As a test, I created a new Pro Project and ran the same addresses against the same locators, and rematching worked just fine.

Then I got the great idea to upgrade from 2.7.2 to 2.8 and that opened up a whole new can of worms for me, unrelated to geocoding. I'll need to straighten that mojo out before I get back to geocoding.

Shana Britt

Do you only see this behavior with composite locators? Do you see the behavior with multirole locators?

The jumping behavior is something we are looking into for a future release of ArcGIS Pro.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

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