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.
ah, gotcha.... makes sense. thanks 🙂
Dan,
What I mean by "adding an address at build time" was potentially adding a checkbox to the Create Locator tool to allow for the point address to be added when building the locator. As mentioned above, there are some challenges with that approach that could cause unexpected or even erroneous geocoding results.
Brad
Thanks for the info Brad. It's kinda hard to wrap my head around until I see it in action, I guess.... Also, I'm going to have to read up on what's meant by adding an address at build time.
Thanks for the feedback. There is no requirement (although it is recommended) to have a base address when using partial subaddress suggestions or even when requiring the entire subaddress to be entered in order for the suggestion to be given. This is also true for searching without suggestions. The base address is only required for the new features that show a list of subaddress suggestions or the subaddress info.
The reason that the base address is required for showing a summary of the units at a base address or a list of the subaddresses at a base address is because the base address is what triggers this functionality. The base address must exist for this to work.
There are also challenges with just adding a base address at build time. There would have to be assumptions made when building the locator in order to add the base address at build time and could cause unexpected or even erroneous geocoding. This is why the base address is required for this new functionality.
We try to maintain these "dummy" base addresses as well, but sometimes they get missed. It would be great if they weren't required to get subaddresses to show up as candidates.@ShanaBritt , do you know why the "feature that represents the base address is required in the reference data used to build the locator in order for the new functionality to work"? It seems unnecessary from a user point of view. Perhaps, the next enhancement could be to remove that requirement....?Glad we got this far.
Thanks,
Dan
I'm happy to see the attention that the ESRI locator team is paying to subaddressing, so thanks!In our municipality / county, there could be parcels where all official addresses contain subaddress data and a base address feature doesn't actually exist. I have built in "dummy" base addresses into locators in the past to ensure that searches will still hit on a more geospatially accurate Address Point instead of falling back on road centerlines. This would be an identical workflow to what you prescribed in your explanation, and building in these Base Address features isn't too difficult.
However, maintaining these base address features does necessitate additional and somewhat unnecessary steps into a workflow when my goal is usually to try and simplify workflows as much as possible. I'm not sure how wide of support there would be for this, but building in functionality to ensure a base address is searchable via locators even though it may not exist in the authoritative data could help streamline peoples data workflows a bit, and every little bit helps. Thanks again!
We've added the ability to return a list of subaddresses and a summary of subaddresses at an address after typing the base address to ArcGIS Pro 3.0. A feature that represents the base address is required in the reference data used to build the locator in order for the new functionality to work. A locator with the new settings enabled must be created in ArcGIS Pro 3.0 and published to ArcGIS Enterprise 11.0 . The new properties, " Show summary of subaddresses with base address suggestion" and "Suggest when base address is typed" are disabled by default and the number of suggestions displayed can be configured in the Locator Properties dialog on the Performance page. If you are part of the Early Adopter Community or have access to ArcGIS Pro 3.0 Beta1 you can test out the functionality and provide any feedback. If you were to go through the create a multirole locator tutorial , you could test the new functionality with the following addresses:
- 1508 CIRCA DEL LAGO, SAN MARCOS, CA
- 1616 CIRCA DEL LAGO, SAN MARCOS, CA
@DMOB17 To avoid those ghost suggestions you would need to build a locator using the PointAddress role in the Create Locator tool in ArcGIS Pro. The suggestions returned by locators created with the Create Address Locator tool in ArcMap or versions of Pro prior to 2.7 did not validate the house number or unit to the street name and this is why the "ghost" suggestions occur. What information are they expected to see returned from the Gazetteer style locator? The Create Locator replacement for that would be the POI role.
If you have not created locators with the Create Locator tool before, 3 tutorials were added for the 2.9 release.
Our jurisdiction also needs to be able to enter a complete address and then be prompted with subaddress units without having to type out the first character of the unit. We fraction our addresses in an alphabetical way for certain locations (123 Main St., 123 Main St. A, 123 Main St. B, etc...) so the suggestion feature as it currently functions is unfortunately useless in providing suggestions for these addresses since you'd need to type out the first character in the unit name, which in our case would be equivalent to just typing out the entire address with the unit. We're hoping for someone to be able to type out 123 Main St. and be shown a list of 123 Main St., 123 Main St. B, 123 Main St C, etc. If they have to type as far as the first unit character then they'll never see any suggestions.
All attempts to create a single house - subaddress locator in catalog have shown very strange errors and "ghost" suggestions for addresses that don't exist. It adds on unit values for addresses that don't have any. I've been down the Gazetteer path but unfortunately some third party vendors use our locators and expect to see more information returned by a locator than a Gazetteer style provides.
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.
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 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-p/486162) 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 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.
What do you mean by "address # suffix suggestions"? It is not clear to me what you are asking for.
Thanks for the feedback. I would like to ask some additional questions that might help clarify the workflow that you are trying to accomplish.
I look forward to additional feedback related to this workflow.
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:
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.
You are probably looking at some time in November.
The locator will need to be created in Pro 2.9 and published to ArcGIS Enterprise 10.9.1.
Anticipated release dates for these^^ ?
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.
Hello,Has there been any update on unit suggestions since discussion ended mid last year? I'm currently using PRO 2.8.3 and the suggestion behavior that has been discussed appears to be largely the same as when this thread was originally posted.
I would agree with what has been said by others in this thread about units showing up in suggestions when the base address is typed. If you know the exact address with suffix, unit, etc. the locators and suggestions work great, but I feel like that falls well within the FindAddressCandidates operation when utilizing a published service or the valid returned candidates when hitting enter with a locator in PRO. I think when utilizing suggestions, a typical user is relying on it because they do not potentially know the full address. That is why, as many people in this thread have mentioned, it would be useful to most end-users to have units show up as suggestions when a base address is supplied (i.e. 600 MAIN). The user also would not be bombarded by 1000's of possibilities because the viewable suggestions would be limited by the Default and Maximum number set in the locators properties. I think it is also intuitive to most users these days that their results will be more applicable as they supply more information in any search bar (e.g. 600 MAIN vs 600 W MAIN, or 600 W MAIN vs 600 W MAIN CHICAGO, ILLINOIS).
We use house address suffixes as well to denote things like duplexes, so similar functionality with that would be great if possible too. Even when a suffix is concatenated into a single field with the address number as recommended (https://desktop.arcgis.com/en/arcmap/latest/manage-data/geocoding/commonly-used-address-locator-styles.htm#ESRI_SECTION1_7FC7CD744FDA4D379399C92D109FA67A) for Single-House w/ Subaddress, you have to know that an A or B suffix exists to have it show up as a suggestion or result. Again, I feel like the typical use case scenario for suggestions is:
1) They get you to a potential valid result quicker than typing out an entire address or portions of address and hitting enter to see a list of valid candidates.
2) They provide potential addresses and sub-addresses that a user may not know existThanks,
~Scott
Hi @ShanaBritt, thanks for your response. The locator is set to YES for Match with no zone and that is not an issue. Thanks to @BradNiemand I figured out why subunit indicators were unnecessary in ArcGIS Pro but needed when using the REST service - because we are still on Enterprise 10.7.My question now is about reverse geocoding - when using our Pro locator built with PointAddress and StreetAddress roles, coordinates for a subaddress are incorrectly matched to the nearest non-subaddress. Essentially, subaddresses cannot be reverse geocoded. I've had a case open on this for weeks but no resolution yet - are you aware of anyone else having issues with this?
Anna:
You can currently enter '100 Main St B ' or '100 Main St B, Redlands' in the Locate pane and get suggestions that return '100 Main St B' or '100 Main St Unit B, Redlands' depending on how the locator was built. Are you saying that when you select the suggestion when the input does not include a subunit indicator (# or unit, apt, suite....) that it zooms to the wrong location?
If the subunit info 'Unit B' is in a single field in the reference data, the # subunit indicator is required. The best practice is to format the reference data so that the unit type and unit id are in separate fields to get the best results.
If you built your locator with zone (neighborhood, city, state, zip) mapped, do you have 'Match with no zone' set to 'YES'? If you built the locator w/o any zone mapped, the 'Match with no zone' property is set to 'YES' by default. I have seen that when this property is not set correctly that it can affect subaddress search results.
-Shana
Gotcha - we're on 10.7 but upgrading soon. Thanks for letting me know, that clears things up!
Well that brings up the next question of what version of ArcGIS Enterprise are you using? Looks like you would need 10.8.1 for that functionality to be supported.
I'm on 2.8! The locator works fine within Pro, but the unit problem occurs when using the published service via REST URL.
What version of Pro are you using? This is already supported so if you are having an issue geocoding without the unit type then it would be something we would like to know about and look into.
Thanks @BradNiemand. Aside from suggestions, subaddresses will only geocode when # or some type of indicator is included in the single line input. Do you know if an upcoming release of Pro will accommodate for geocoding addresses such as 100 Main St B (no # sign), and have it correctly geocoded to the unit address?
At this time locators created with the Create Locator tool support suggestions for subaddresses when the entire unit is entered. Going forward we are looking into supporting suggestions for subaddresses when a partial subaddress is entered. It may require the user to enter #, apt, unit, or some type of unit type prior to showing suggestions but the team is looking to support this in an upcoming release of Pro.
@AnnaStam I'm not aware that this has been fixed, and I'm using 2.7.2....
@BradNiemand or @ShanaBritt , any comments on this?
Pro 2.8 was recently released and it looks like this is still an issue. I am trying to transition entirely from address locators created in ArcMap to Pro locators, but I unfortunately can't do that until the unit problem has been fixed. @Robert_LeClair do you know when this will be implemented? I'm subscribed to @JoeBorgione 's enhancement request but I haven't seen any updates.
This is still be an issue. Pro 2.7.1
Just to clarify... unfortunately, this has not been fixed yet.....
From Brad:
At Pro 2.6 we added support for suggestions for subaddresses but there is a requirement to enter the entire unit number for the suggestion to show....I am not saying we wont consider the enhancement for partial unit suggestions for a future release, I am just saying this isn't part of the Pro 2.6 release.
In Joe Borgione's link for his GeoNet idea - Provide Units in Suggested Addresses - this was implemented in AGP 2.6 according to Kory Kramer.
Dan McCoy is spot on in his reply. But another situation we currently have is some locations only have subunit addresses. The addressing folks are looking at changing this in the future but for now it is allowed and it exists. The Clinch address is a good example. If you look at the screen shot a few items back you will see that 2020 Clinch Ave only has unit addresses. So if the units don't show up in the suggestions then the user would never know it was a valid address.
One use case would be for an agent or customer service rep taking a call from a customer. If the caller says they are at 2220 CLINCH AVE, the CSR could look at the suggestions and ask "are you in Apt #1, 2, or 3?"Also, there's the whole idea of suggestions just enabling users to type less and pick the correct address including subaddress when it pops up... I think there's just an intuitive expectation that suggestions should behave the same way for addresses with units as those without....
Hopefully, that's helpful...
Bryan,
I would really like to understand the use case for when you are trying to find an address where you don't know the subunit information. In what case would you know the base address but not the subaddress and seeing all of the subaddress information would help to make a decision?
We are working on adding support for suggestions with subaddresses for an upcoming release of Pro.
Hey guys- check out a suggestion of mine: https://community.esri.com/ideas/17064 It's in the product plan....
No. Our need/use of ArcGIS Pro has really dropped at this point (we are sticking with ArcMap for the short term) so it isn’t a huge deal right now but we need the ability to search for unit level addresses.
Thanks for checking back,
Bryan
Bryan Lynn, did you ever open a support ticket and/or get a BUG# for this? Eric Anderson, has this been fixed?
My address point data has a 'Full Address' field and when appropriate has the unit included in the form of 1234 S Main St #1. I've created a POI role pointing to that field and it seems to be working for me with respect to suggestions. I've also taken a look at the locator properties / performance / default number of suggest candidates. Shana's comment about 1,000 units strikes a specific chord there....
Things head south when you get greedy....
The behavior in the original post is expected behavior for subaddress addresses, a unit indicator (#, APT, UNIT...) is required to return address matches.
The problem I am seeing is - I can't find the subaddress addresses even if I use a unit indicator (#, APT, UNIT...). The locator only will find an address match that doesn't have a subaddress. Here is screen shot showing a search for 606 main st #150 - which results in the locator ONLY finding 606 MAIN ST and not the subaddress.
It would be great to understand the use case for providing suggestions for subaddress, as well as, returning all units associated with the base address when searching for the base address.
The image below actually shows 2 problems. First, the need for subaddresses in suggestions. Without subaddresses in suggestions - you won't know that 2220 CLINCH AVE #1 even exists. Second, and the bigger problem here, even if you know 2220 CLINCH AVE #1 exists you can't find it. Now, should you have a parcel with out a base address of 2220 CLINCH AVE? I don't know, I am not over addressing.....I just type on my little keyboard and try to make things work
At what point in typing the address do you expect the unit suggestion be returned? If you are searching an address for a building with 1,000 units, are you expecting to scroll through all 1,000 unit candidates to find what you are looking for?
I guess in my mind, when you type 606 MAIN it would be nice to see a list of suggestions that included 606 MAIN ST, 606 MAIN ST #100, 606 MAIN ST #150, 606 MAINTENANCE LN.... at least you would know there are several units at 606 MAIN ST. Now, as a programmer, I can see a couple of problems on how to make this work well in all situations (especially if you have a building with 1000 units), but you are only showing a few suggestions (like 6 -10 or so). I really don't think anyone is expecting to scroll through a 1000 suggestions. I can also see an argument that the unit numbers keep you from seeing 606 MAINTENANCE LN as a suggestion because all of the unit suggestions from 606 MAIN ST push it off the list. However, once you get to 606 MAINT the MAIN ST suggestions drop off the suggestion list and you will see what you need. So, I am not sure what the best solution is here for including units in the list of suggestions but going back to image #2 above - having units in the suggestion list would help you find 2220 CLINCH AVE #1.
Thanks for taking the time to look at this. I have to say the dialog with the Esri staff on this issue has been outstanding.
I know I need to open a support ticket - I have just been sidetracked on a couple of priority tasks.
The behavior in the original post is expected behavior for subaddress addresses, a unit indicator (#, APT, UNIT...) is required to return address matches. This is noted in the Subaddress section in the help, https://pro.arcgis.com/en/pro-app/help/data/geocoding/introduction-to-locator-roles.htm#GUID-BA06C3FE-2210-4634-9E61-CA5BAA6E2E5E.
Suggestions for subaddresses are currently not supported for locators based on the PointAddress role created with the Create Locator tool whether local or as a service. It would be great to understand the use case for providing suggestions for subaddress, as well as, returning all units associated with the base address when searching for the base address. At what point in typing the address do you expect the unit suggestion be returned? If you are searching an address for a building with 1,000 units, are you expecting to scroll through all 1,000 unit candidates to find what you are looking for?
The PointAddress role does require one of three field mappings outside of street name: building name or house number, or house number to and from fields. This is why you are getting the error when only mapping street name. I'm not sure what values you had in the street name field, but the PointAddress role requires the address components to be separated just like street centerlines. See link to help topic above.
This is a good discussion regarding the new approach to creating locators. It's nice to see ESRI ready to join the dialogue as we all make the adjustments.
To confirm, is the issue that the units are not appearing as suggestions, or you are unable to actually locate using a unit as well? Both actually. Address points with units do not appear as suggestions and I am unable to locate them. It is like it simply doesn't know they exist. Which is odd because they work fine in our ArcMap/ArcGIS Server locator.
Let me create a local dataset and give it a whirl.
Thanks for the help!!
Hi Bryan,
Sorry for the confusion, your initial description only mentioned "Suite", so I was just curious if you're seeing this issue with other unit types as well.
To confirm, is the issue that the units are not appearing as suggestions, or you are unable to actually locate using a unit as well?
Here is some sample data I mocked up that is nearly identical to yours, and the locating functionality seems to be working successfully:
I can search "#100", "Suite 100", etc. - all successful.
-Eric
What version of Pro are you using? 2.4
What is the data format of your Unit field (e.g. text, numeric)? Text
What is the data format of your Unit Type field (e.g. text, numeric)? Text
Do you have any other fields mapped that you are not showing in your screenshot? Yes - see image below
What version of Pro are you using?
What is the data format of your Unit field (e.g. text, numeric)?
What is the data format of your Unit Type field (e.g. text, numeric)?
Do you have any other fields mapped that you are not showing in your screenshot?
Yes, I was using the new Create Locator tool in ArcGIS Pro 2.4.
Addresses are from a point feature class stored in an Oracle SDE database.
"Have you tested with other unit types ("#", "Unit", "Apt", "Bldg", etc.)?" Not sure I understand this question. We have a variety of unit types stored in the UNIT_TYPE field. Values include SUITE, APT, UNIT, etc. So when you say "have you tested.." I am not sure what you are asking. I have tested addresses with both a SUITE and an APT unit type. I am expecting to put in "606 MAIN" and have candidates with units show up in the candidates list. What I am seeing is just the primary 606 MAIN ST address (see third image below).
I have attached some screen shots showing how I defined the locator and what I am seeing when using it. I only showed
the "Field Mapping" values that I thought were relevant. If you need to see all of them I can create more screen shots.
Using the locator in Pro - I would have expected to see all of the 606 Main St addresses in the list box (or at least the first 6 addresses).
Even worse, the address points for 2220 CLINCH AVE, which all have unit numbers, never show up in the list of candidates.
Thanks for the help.
To answer Michael Volz's first question (and confirm my own understanding), it sounds like you are using the new Create Locator tool in ArcGIS Pro and using the Point Address role (comparable to the "US Address - Single House" and "US Address - Single House Subaddress" styles with the older Create Address Locator tool).
What version of ArcGIS Pro are you currently using, and which version was the locator created in?
Are you using points or polygons as the input reference data?
Have you tested with other unit types ("#", "Unit", "Apt", "Bldg", etc.)?
I would also like to see how you defined the reference data when creating the locator. Do you have screenshots of how your unit/suite information is structured in the reference data's attribute table, and how you defined it in the Create Locator tool?
Thank you!
Eric
Which locator style are you using? Did you account for the field(s) that hold the units in address locator data source?
I have tried to use the Create Locator tool to recreate a locator from ArcMap based on 1 concatenated field. It appears with the Point Address role you only have 1 required field (Street Name) that I populated with the concatenated field. Unfortunately, when I do this I get the following error message:
So it appears that even though the tool shows that there is only 1 required field, in reality there appears to be more than 1 required field.
Is the intent of the Point Address role to have your point data broken out into individual fields as opposed to 1 concatenated field?
Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
