Locator Style for Apt or Units

11082
48
03-21-2011 11:34 AM
DaleSimper
New Contributor III
I was wondering if anyone has an ArcGIS 10 locator style file that will geocode house addresses with Apt or Unit #'s.  I have gone through Appendix G of the Customizing Locators document, which is suppose to allow this, but still after customizing my style file as the document instructs I'm not able to geocode Apt or unit #'s.  So I was wondering if anyone has had any success in customizing a style file to allow this and are willing to share.  Thanks.
Tags (2)
0 Kudos
48 Replies
PeterHanmore
New Contributor III

Brian Oevermann

Thanks for your quick reply.

I did a bit more digging through the xml file and think I've found the solution.

I noticed that the MultiLineAddress section differed slightly from the NormalAddress - it was missing the OptionalFraction element (<elt ref="OptionalFraction" weight="40"/> ).  I added that in and reloaded my locator and it seems to be working better now.  Not sure why is worked okay with alpha suffixes like 'A' or 'B' but if it works, who am I to argue.

Peter.

0 Kudos
EmilyLee
Occasional Contributor II
Thank you, Brian for uploading the locator style again. And yes, it works in ArcGIS 10.2.

But I don't know if it's only my problem or other people have similar issue. It seems to geocode only addresses with a unit number, if not, it might not geocode?  As an example, I've attached a file geodatabase here that contains the reference layer (AddressPoints), address table and the results of both Single House locator and Address With Unit locator. If you have time and don't mind, you can take a look?

Thank you very much for your time here.

Emily
0 Kudos
BrianOevermann
Occasional Contributor III
Emily,

That is strange, as I have no issues locating addresses that do not have a unit/suite associated.  I'll compare your data schema with mine--maybe there's a slight difference?

I'll work in a test for you but likely won't have a chance until tomorrow.
0 Kudos
EmilyLee
Occasional Contributor II
Brian,

No problem. Take your time. Thank you for looking into it. The AddressWithUnit locator did geocode some addresses even though there wasn't a unit/apt #, but for some reasons it didn't geocode for some others (the unmatched ones I took out as samples) while the regular SingleHouse locator did geocode instead.

Emily
0 Kudos
EmilyLee
Occasional Contributor II
I know I'm asking much, but just wondering if there's a way to add the "Unit/Apt" field in the Address Input Field dialog when geocoding. In case the unit/apt # is in a separate field/column from the customer table.  If not, I can just concatenate the Street Address and Unit fields/columns as well.

Thank you again,
Emily
0 Kudos
BrianOevermann
Occasional Contributor III
Emily,

I will answer your latest question and then comment on the testing I have done with your data...

Re: batch geocoding with a table that contains the unit in a separate column from the address - To my knowledge the entire address to be matched must be in a single column.  I don't batch geocode often, but I seem to recall only being able to specify one field/column that contains the address to be matched.  Someone please correct me if I am misinformed!

Re: testing [apologies for the length]
So... I added your data to a new ArcMap project, then added your locator built with the style file I uploaded to the forum to ArcMap via the Geocoding toolbar.  I used your AddressTable table to inform me of sample addresses and typed an address containing a unit as well as an address without a unit and got the same results you indicated--those addresses without units were not found.

I closed ArcMap and then created a brand new locator against your address point data.  My thought was maybe the upload got corrupted somehow and using the locator style that is on my system (that I successfully create locators with) could confirm that possibility.  After loading the new locator into ArcMap in the same way described above, my results were still the same.

I next took a closer look at your data.  Within the unit field, if an address does not have a unit associated with it, the field is populated with a 'space'.  In the unique values list within the 'select by attributes' dialog it looks like: ' '
.  A space as a value is not the same as a NULL value, and I suspect that might be the reason for the failed address match.  In an attempt to confirm that, I edited your data to null the unit field.  The most that would do is change the value in the unique values list to: ''
.  That also is not the same as NULL.  Typically the result of nulling the field is an entry of NULL, so I started looking at your feature class schema.


For your UNIT field (and for your DIR field as well) you have the field set to NOT allow NULL values, which is why I was not able to completely NULL the field.  You likely have a sound business reason for disallowing NULL values on these fields, but general best practices are that you only disallow NULLs when you absolutely require something to be filled in that field.  For street directionals and units, you may or may not have a value.  That is why I found spaces as values--a user must put something in the field.  And while a space is not equal to NULL, it IS a valid value that satisfies the field not being NULL (and the field otherwise looks blank).

All of that said, I think that if you recreate your feature class and set the DIR and UNIT fields to allow NULLs, you will find success with the address matching.  If your business rules require those fields to not have NULLs then you are likely stuck.  You may want to test it so that you can make a sound business case to change the rules accordingly.

You should be able to import your fields from the existing layer and make the required changes before completing the creation of the new feature class, then use the simple data loader to load all of your features from the old to the new.  You will need to then NULL those two fields where a value does not exist.  At that point, re-create your locator--you could try rebuilding the existing one but why take the chance--and attempt your address match again.

I hope this all makes sense...
0 Kudos
EmilyLee
Occasional Contributor II
Hi Brian,

Thank you very much for your throughout explanation. Thank you for catching that DIR and UNIT fields should be allowing NULL values. I've recreated the AddressPoints' schema, reloaded the data into it, edited the data to make sure no empty spaces, and recreated the AddressWithUnit locator. But it still doesn't seem to work (though, it geocoded beautifully with the ones with unit #).  Am I still missing something here? I've attached my samples here (only if you have time).

Thank you very much again,
Emily
0 Kudos
BrianOevermann
Occasional Contributor III
Emily,

Your unit (and dir) fields are still not truly null--you have just eliminated the spaces.  If they are truly null they will look like the attached screenshot.  There are multiple ways you can accomplish this, but if there is only a space (or a "blank") I have found that I need to add some actual characters (i.e. asdf), commit them, then select that new value and hit delete on the keyboard.  This is via the attributes window when editing.  Hopefully I have described it well enough for you to get the idea.

That said, when I did actually null your unit field, I was still unable to get the locator to properly find a match.  I didn't exhaust all of the possible reasons/causes because I simply don't have time to do that level of troubleshooting for you.  I still think it has something to do with how your data is formatted but I am unsure exactly what that might be.  Your data does not have all of the same fields as mine, but when you set up the locator and specify the fields to be used it should be using only those fields for matching (from what I understand about the process).

You are the first person that seems to have this issue with the locator, or at least the first person to raise the question.  Maybe others have simply abandoned it without saying anything.  Regardless, I can tell you that my locator finds single family addresses as well as those with units.  My users wouldn't be happy with me otherwise!

You can see it actually working via our current 'placeholder' (until I can build more focused viewers) public viewer on our website at:
http://products.issaquahwa.gov/GISviewer/index.html

Sample addresses are:
130 e sunset way = our main City Hall, but equivalent to a single-family address without a unit
360 nw dogwood st unit r201 = address with unit. For matching purposes you can even leave off the 'unit' and only type the 'r201'

Full disclosure: the viewer is actually running a composite locator made up of: single house with unit, US Address (streets), and single-field input, in that order. If you type in a proper address it should locate it to the site address point using the single house with unit locator. Also note that capitalization is not necessary.

You might try digging up Brad's (from esri) version of a unit-based locator and see if you have better luck.  You mentioned in a previous post that the "regular" SingleHouse locator worked.  That is to be expected because the way that locator is built ignores information regarding units--it knows nothing about them.  So I would expect that the locator would work well with addresses without units as well as those with units. But for those with units, the locator is only matching the base address.
EmilyLee
Occasional Contributor II

Hi Brian,

Thank you very much again for all your time. I really appreciate it.

Actually Brad's 'US Single House Unit' locator works, except that it creates a '#' character on the 'Match_addr' field, but that's ok. I really don't know why the other one wouldn't work even though I re-created all the null fields/values from scratch.  Anyway, for now it's been solved and hopefully Esri will have an 'Address with Unit' locator in the core product on their next release.

Thank you!

Emily

0 Kudos