Locator Style for Apt or Units

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,

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?

DanMcCoy

Russell Provost:
However, if an address is being matched without an apartment number (123 Main Street), but the reference data contains unit information for this address (123 Main Street, Apt. 1 or 123 Main Street, Apt.2) the matching algorithm will return a score of 100 for each instance in the reference data with the same primary address. I cannot solve this behavior in my locator either. Ideally the scoring would be slightly penalized for the matches with unit information. Any suggestions?

Has anyone resolved this issue or know if it's been resolved at 10.3?

Thanks,

Dan

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

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

inspections_attributerules.zip

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

Mosaic1.jpg.zip

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

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

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

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.

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

Geo ref_settings.JPG

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

Chart3.PNG

PatrickLockwitz

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

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.

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.

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.

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

Roberto,

Are you asking if a style using units or apartments is available out-of-the-box at 10.1? The answer is no. But the style I contributed in this thread, as well as Brad's, are usable in 10.1.

There is a GIS Idea requesting such a style be part of the core list of styles that you can vote your support for. The link has been put in this (response #8) and other companion threads on this same subject.

RobertoFigueroa

Is there any update for an address style using Apt or Units for ArcGIS 10.1?
Thanks
Roberto-

Also wanted to add we are having a problem with scoring incoming records with matches against units. If an incoming record does not contain the unit value and the candidate does this should not be a 100% score in my opinion. I believe this was mentioned in some previous posts how do we add a rank to the unit so the score is reduced for the incoming record. It sounds like there were some suggestions but no enough documentation for me to follow or even attempt to modify.

Attached is a screen shot
[ATTACH=CONFIG]30129[/ATTACH]

geocd_match_score.PNG

features3857.zip

Thanks to everyone on this thread for some explanations and help with customizing locators for units. One problem we are having with this locator is in the candidate match it seeds in a # even though the incoming address did not contain a unit. Is there any way to remove the # in the event of a match without a unit?

The locator returns # characters in the match even if no unit supplied or returned in the candidates.
[ATTACH=CONFIG]30128[/ATTACH]

Thanks for any help in advance. ESRI it is time to fully document the new locator styles and scoring rules it has almost been 3 software versions since they were introduced in 10.0!!!

geocd_matches_#.PNG

image003.png

Steve,

It is unclear which locator style you are referring to when you say "this one". The included quote seems to imply my version but to be clear since there are two different unit-based locator styles circulating on this thread:

- Brad (esri) created a style that includes units, and...
- I created a style that includes units and also has a separate field for fractional portions of an address (my style was tweaked by Brad due to lack of info in the white paper)

Depending on the thread response (and link within), it can get a bit confusing which is which. The telling indicator is the inclusion of the fractional field in the style properties. Brad's will do fractionals but only if the fraction is part of the house number field. Our data is set up with the pieces separated, making the different style necessary.

While I cannot definitively say (since I don't use that version) that Brad's locator style will work with mixed alpha and numeric units, it should have no problem doing so. I CAN definitively say that my version does work with mixed alpha and numeric because our data contains such units (i.e. A-3, B101, 2-C, etc.) and matches them with no issues.

SteveGay3

My apologies the custom locator for units is working in 10.2, after I completely removed it and recreated my locator tools. I think my problem was due to model builder keeping the names of the Locator Styles and not truely refreshing them based on the environment. Creating a new model to Rebuild the indexes seemed to resolve the issue.

Still I am tired of dealing with these customization's on 100+ workstations and server environments after every upgrade or installation.Please vote to make this a core locator style, it is time.

Also please update the locator whitepaper from 10.0 it is missing many important aspects that are important for Local Government use cases.

Do you know if this one will also support units with a mixed alpha and numeric? IE 2a or 3c?

Bloper_0-1783362896194.jpeg

RussellProvost

I have attached a locator style that fixes the issues that you are seeing.

Brad,

Thank you for your continued persistence with developing locators that will match at the subaddress level. I noticed that your locatorstyle can differentiate between apartment numbers. However, if an address is being matched without an apartment number (123 Main Street), but the reference data contains unit information for this address (123 Main Street, Apt. 1 or 123 Main Street, Apt.2) the matching algorithm will return a score of 100 for each instance in the reference data with the same primary address. I cannot solve this behavior in my locator either. Ideally the scoring would be slightly penalized for the matches with unit information. Any suggestions?

I've noticed the "equal successful match" scoring as well. I think it is because the locator successfully matched all of the portions of the address you entered. All of individual units are technically 100% successful matches because you didn't differentiate the address with a unit.

I'm willing to bet that there is a technique to "float" the non-unit address to the top and "penalize" the matches that include a unit, as you describe. Unfortunately, the white paper is sorely lacking, and I have had no success digging anything up in online help (though I haven't tried lately, so maybe things have changed in that regard). I think Brad or another esri employee "in the know" might be able to provide more info.

RussellProvost

Bill,

I'm not sure why my attachment is not working correctly. Post #35 in the link below should be the same file after Brad from ESRI made some tweaks. There is a lot that the white paper fails to cover...

http://forums.arcgis.com/threads/28535-Geocoding-Addresses-with-Apartment-Units?p=128250&viewfull=1#post128250

I "re-zipped" the file and I am attaching it yet again, but I am guessing that it is a problem with the system and not the file specifically.

Brian

Brian,

Thanks so much for sharing your locator. I too have taken the leap into the black box of customizing address locators for address units. I noticed that your locator style can differentiate between apartment numbers. However, if an address is being matched without an apartment number (123 Main Street), but the reference data contains unit information for this address (123 Main Street, Apt. 1 or 123 Main Street, Apt.2) the matching algorithm will return a score of 100 for each instance in the reference data with the same primary address. I cannot solve this behavior in my locator either. Ideally the scoring would be slightly penalized for the matches with unit information. Any suggestions?

Thanks for the follow-up regarding 10.2. And also thanks for the Model Builder comment. I imagine I would be pulling my hair out over that one.

My apologies the custom locator for units is working in 10.2, after I completely removed it and recreated my locator tools. I think my problem was due to model builder keeping the names of the Locator Styles and not truely refreshing them based on the environment. Creating a new model to Rebuild the indexes seemed to resolve the issue.

Still I am tired of dealing with these customization's on 100+ workstations and server environments after every upgrade or installation.Please vote to make this a core locator style, it is time.

Also please update the locator whitepaper from 10.0 it is missing many important aspects that are important for Local Government use cases.

@Bill,

I got really busy with other stuff and failed to respond to your post from June. I suspect you are getting similar standardization issues as the other style because they are mostly the same style "under the hood". As I have mentioned in this and/or other similar posts, I simply modified esri's existing style to add fractionals and units (with some additional tweaking by Brad from esri because the white paper doesn't go into enough detail). So the modified style is just taking into account additional fields and retains whatever issues might exist in the original style from which it was based.

@Ronnie,
I haven't upgraded to 10.2 yet, so I have no idea if I will experience the same issue nor do I have any way to test. That the 10.1 locators do not work in 10.2 is very unsettling.

@All,
If you even remotely agree that these styles belong in the style list by default, please vote for the idea that is linked in response #8. It is likely the only way esri will listen to our pleas.

This is an old thread but 10.2 does not seem to support any of the locators provided here. Does anyone have a 10.2 version that supports units. How many more years are we going to have to chase these down in forum threads instead of this being a core locator in the product?

Thanks in advance for any help!

BillRose

I see many of the same parsing issues with this locator that Roy Jackson describes here: http://forums.arcgis.com/threads/28535-Geocoding-Addresses-with-Apartment-Units?p=208831&viewfull=1#post208831. For example, "999 Little Knoll Lane" is standardized as HN: "999", SN: "Little", ST: "Knl", UN: "Lane".

Bill,

...Let me know how it works (if it works) for you.

Brian

Bill,

I'm not sure what was wrong with the original zip file but I am glad it now works! Let me know how it works (if it works) for you.

Brian

BillRose

That did it. Thanks!

Bill,

I'm not sure why my attachment is not working correctly. Post #35 in the link below should be the same file after Brad from ESRI made some tweaks. There is a lot that the white paper fails to cover...

http://forums.arcgis.com/threads/28535-Geocoding-Addresses-with-Apartment-Units?p=128250&viewfull=1#post128250

I "re-zipped" the file and I am attaching it yet again, but I am guessing that it is a problem with the system and not the file specifically.

Brian