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

Locator Style for Apt or Units

DaleSimper

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.

Find more posts tagged with

Accepted answers

All comments

AnjoletteSpradling

I'm trying to create a locator with USSingleHouseUnits using an alternate name table (with 10.2). It works fine with just the address points, but when I try to add the table I get this error:

[INDENT]ERROR 000042: Failed to create the address locator.
The table was not found. [AddressUnit_Alt_lox]
An invalid SQL statement was used. [SELECT AddressPoints.Shape, AddressPoints.OBJECTID, AddressPoints.Address_Num, AddressPoints.Unit, AddressPoints.ZIPCODE FROM AddressPoints, ADDPTIDAltNames WHERE (AddressPoints.ADDPNTID = ADDPTIDAltNames.ADDPNTID) AND (   <> '' AND
             <> ' ' AND
          UPPER( ) <> 'UNNAMED' AND
          UPPER( ) <> 'UNNAMED STREET'
        )][/INDENT]

The error 000042 isn't much help. I haven't worked with the details of locators much so I'm not sure what it's looking for in the SQL statement. Any suggestions?

Thanks,
Anjolette

BrianOevermann

Anjolette,

I am afraid I will not be of much help, as we currently do not use alternate name tables nor are we on 10.2 yet. But I would be interested in the solution because I have been contemplating adding alternate names into our locators.

Hopefully Brad from esri or someone else has an answer or suggestion(s) for you.

EmilyLee

Hello. Just want to see if anyone has created a locator for Unit # yet for 10.2. Thank you!
And yes, I've already voted for the address unit locator to be in the core product.

BrianOevermann

Emily,
I can confirm that the style I've uploaded--that contains a field for the fractional portion of the address--works at 10.2. I would expect that the style that Brad from esri has uploaded also works, but I cannot confirm that since I don't use that style.

Were you having trouble getting either to work? You should be able to find the links/files in earlier thread messages and even in one or two other threads if you haven't already downloaded either of them.

PatrickLockwitz

Brian, can you re-post the latest locator? I'm working in 10.2. Thanks in advance.

BrianOevermann

Patrick,

My version of the style hasn't changed, so the file available on other threads is still valid. Regardless, it is attached for your convenience. At this writing my organization is using 10.2.

USAddressWithUnit.lot.zip

EmilyLee

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

Samples.gdb.zip

BrianOevermann

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.

EmilyLee

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

EmilyLee

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

BrianOevermann

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

EmilyLee

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

Sample2.gdb.zip

BrianOevermann

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.

null.JPG

EmilyLee

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

PeterHanmore

Brian Oevermann,

This thread is a bit old, but I was testing your locator style (we're using 10.2.2) and noticed that fractions in the house number don't seem to be recognized when using multi-line input. Multi-line works fine with other suffixes, like A,B or C - just not with fractions. I tried using 1/2 (i.e. 3 ascii characters) and ½ (ascii ½ ) - neither works. Single line input DOES recognize fractions and returns the correct results.

Have you tested your style with fractions on multi-line inputs?

BrianOevermann

Peter,

We don't use multi-line input--only single-line--so I've never noticed an issue and of course never bothered to test it with multi-line input. And you have confirmed that single-line works correctly. So I don't believe I can be of much help.

Have you tried the version that Brad Niemand (Esri) created to see if it has similar issues? I really only added fractionals and units to an existing locator--and Brad actually tweaked it under the hood to fix some remaining issues because the available documentation isn't extensive enough for me to know/understand what those changes should be.

PeterHanmore

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.

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.