Locate Addresses with Units

[BryanLynn1]

I have created a locator using the Point Address Role. The locator works but it will not locate or provide candidates for addresses that contain units. For example: 606 Main St will work but 606 Main St Suite 150 will not. This is a big problem when all of the addresses on a parcel have unit addresses. For example: 10001 Kingston Pike only exists with units (e.g. Suite 100 - 150) and since all the address points have unit values it will not show up in the candidates list.

[ShanaBritt]

We've added an option to allow subaddress suggestions before the entire unit value has been entered.  Typing in the unit type, such as Apt, Unit, Suite, # is also optional. The locator will need to be created in Pro 2.9 and published to ArcGIS Enterprise 10.9.1. This new option, Suggestions for partial subaddresses, is disabled by default but can be enabled, as well as configure the number of suggestions returned, in the Locator Properties Dialog. If you are part of the Early Adopter Community or have access to ArcGIS Pro 2.9 Beta1  you can test out the functionality and provide any feedback.

[JoeBorgione]

The locator will need to be created in Pro 2.9 and published to ArcGIS Enterprise 10.9.1. 

Anticipated release dates for these^^ ?

[BradNiemand]

You are probably looking at some time in November.

Brad

[MattFancher1]

I tested the "suggestions for partial subadresses" option in Pro 2.9 beta. It works exactly as its name implies. It is definitely an improvement, but also not quite what I anticipated. You must enter some part of the unit number in order to get a suggestion with a unit number. That means you can enter the full base address for an apartment building (e.g. "123 Main St"), but you still won't see any subaddress suggestions until you enter the first character of a unit number. In my ideal world, if I entered "123 Main" into the search, I would like to see a list of suggestions like the below. As is, I only see the first suggestion on the list.

• 123 Main St
• 123 Main St Unit 1A
• 123 Main St Unit 1B
• 123 Main St Unit 2A
• 123 Main St Unit 2B

[ScottFedak2085]

I would agree w/ @MattFancher1. I'm approaching much of this subaddress discussion in relation to locators from a public safety perspective. As localities shift to more precise address point placement to facilitate NG911, Z data could eventually be a part of this too, it would be beneficial for public safety personnel to quickly and accurately be informed of related subaddress information associated with an address, parcel, POI, etc when trying to locate a callers position.

It's probably asking too much at this point, but address # suffix suggestions would be great to add to the mix too. Staying with the user entry of the base123 Main St address example, the following results would populate too if an address suffix existed:

• 123 Main St
• 123 Main St Unit 1A
• 123 Main St Unit 1B
• 123 A Main St
• 123 A Main St Unit 1A
• 123 A Main St Unit 1B

[BradNiemand]

What do you mean by "address # suffix suggestions"?  It is not clear to me what you are asking for.

Brad

[ScottFedak2085]

Hey Brad,

No problem, and thanks for responding. I don't think it would be unique to our community, but our addressing authority often utilizes an address # suffix to denote two separate addresses on the same parcel of land. This is often utilized for duplexes, could be utilized to address a second building on the property, or could be for some other unusual reason. For example, you may have a front building that has the main address 123 Main St, but then you have a second building in the back that is 123 B Main St....The suffix (B) could potentially be mapped to some unit or building in a locator, but I don't think that would be utilizing those fields for their intended function; it also would return the address in a format (123 Main St, Bldg B) that differs from how it is normally utilized (i.e. 123 B Main St).

I believe ESRI stopped supporting address # prefixes and suffixes in 10.5 (https://community.esri.com/t5/data-management-questions/geocoding-address-prefix-suffix-elements/td-...) to improve locator performance, and started recommending to concatenate prefixes and suffixes into one field with the address #.  This works to provide valid candidates if a users knows the candidate exists and types it in, but does not appear to be supported in suggestions in anyway.

Since it's kind of on topic, I did notice that suggest via the REST endpoint of a locator that uses a street address role, will return a false suggestion if an address # suffix is added to the end of an address # with no space (i.e. 123A Main St) will return 123A Main St as a suggestion even though it does not exist. It looks like it just recognizes the alpha character as part of the address #.

Although I often see similar performance both natively in PRO and via a REST endpoint, I just wanted to clarify that my end goal is often to use the locator via a REST endpoint.

Thanks!

[BradNiemand]

Thanks for the feedback. I would like to ask some additional questions that might help clarify the workflow that you are trying to accomplish.

1. What benefit does providing a list of arbitrary units at a base address provide to the user who is typing in the address?  It would seem to me that if the user didn't know the unit that they would like to find, providing a list of units at the base address provides little benefit to the user but maybe some clarity on how this is beneficial to the user would help with this.

2. What order should the results be in if we were to support this workflow?  Should they just be the first 5, 10, 15 units at the location (depending on the max suggestions setting)?  If so, it would seem that the user would only start getting suggestions they cared about after entering in some information to whittle down the suggestions to something more applicable.

3. If the user was to set the max suggestion setting to something quite large, I would argue that they may spend more time scrolling through the suggestions to find the unit that they are looking for instead of just entering a character or two to get suggestions that were more applicable.

I look forward to additional feedback related to this workflow.

Brad

[MattFancher1]

@BradNiemand I think other responders have discussed some of this above, but I can offer my take.

Regarding your first question, I don't think the list would be arbitrary all the time.  We have vastly more small apartment buildings, with say eight or fewer units, than large apartment buildings with dozens or hundreds of units. For those smaller buildings a reasonable number of suggestions would display all the subaddresses.

For large apartment buildings, I think the subaddress suggestions are still helpful (even if they're the wrong ones), because they alert the end user that subaddresses exist at that location and they should keep typing to get to the correct one. Otherwise the end user may pick the base address (with no unit) assuming that is good enough.

For #2, alphabetical works for me.

For #3, possible, but I'm not advocating to set the max suggestions high. 

[ScottFedak2085]

My responses are below in BOLD.

1. What benefit does providing a list of arbitrary units at a base address provide to the user who is typing in the address?  It would seem to me that if the user didn't know the unit that they would like to find, providing a list of units at the base address provides little benefit to the user but maybe some clarity on how this is beneficial to the user would help with this.

To @MattFancher1s point, alerting a user that subaddresses exist at this location is they key thing we'd be looking for. Subaddress information is not always that widely known or easy to find outside of people very familiar to a property. There are business workflows out there where just the mere suggestion that subaddresses exist could change a users approach.

In a public safety sense, lets say a dispatcher is on the phone with someone and they say they are at 123 Main St, type it in, and now the dispatcher sees subaddress unit suggestions showing up; it could then prompt the dispatcher to ask "what unit are you in" and potentially narrow down to a more accurate location for the caller. Customer service may send a bill to the base address 123 Main St, and be completely unaware there are subaddresses that exist and now they sent that bill to the wrong person.

2. What order should the results be in if we were to support this workflow?  Should they just be the first 5, 10, 15 units at the location (depending on the max suggestions setting)?  If so, it would seem that the user would only start getting suggestions they cared about after entering in some information to whittle down the suggestions to something more applicable.

Just the mere presence of subaddress suggestions is probably enough and the order doesn't probably matter that much, it would likely be more specific workflow dependent at that point that I think would be difficult for you to account for. With stacked Address Points that have subaddres information, I do think Reverse Geocododing will actually spin out a response of 123 Main St, Unit 1 - Unit 300, or something like that, so even that could be an alternative to listing everything??

3. If the user was to set the max suggestion setting to something quite large, I would argue that they may spend more time scrolling through the suggestions to find the unit that they are looking for instead of just entering a character or two to get suggestions that were more applicable.

Again, it's largely just the mere suggestion that subaddresses exist at this base address is what a lot of us are asking for. Now that a user knows subaddresses exist, they can start typing 1 or 2 or 5 or A or B to narrow down the suggestions at that point.