topic Re: Unexpected Behavior with Pro 2.6 Locator in ArcGIS Pro Questions

Unexpected Behavior with Pro 2.6 Locator

JoeBorgione — Mon, 10 Aug 2020 20:05:44 GMT

I have just begun to 'play with' locators created in arcgis Pro 2.6 using Create Locator. I'm seeing what I think is unexpected behavior when it comes to addresses with unit numbers. Here is a typical point address with a Unit number:

Here are the parameters I used in setting up the locator:

'PointAddress.HOUSE_NUMBER AddressPoints.ADDR_HN';
'PointAddress.BUILDING_NAME AddressPoints.BLDG_DESIG';
'PointAddress.STREET_PREFIX_DIR AddressPoints.ADDR_PD';
'PointAddress.STREET_NAME AddressPoints.ADDR_SN';
'PointAddress.STREET_SUFFIX_TYPE AddressPoints.ADDR_ST';
'PointAddress.STREET_SUFFIX_DIR AddressPoints.ADDR_SD';
'PointAddress.SUB_ADDRESS_UNIT AddressPoints.UNIT_DESIG';
'PointAddress.CITY AddressPoints.CITY'

As you can see Building Name and Sub Address Unit are mapped to the respective fields

If I use the Locate Tool and begin to enter the address, I get a suggestion as I type, with no unit number. I'm okay with that, in fact surprised since 4773 W SILVER FOX DR, KEARNS does not exist in my point data. This locator is a single point address role. I have turned off the the other locators that load automatically with Pro. If they were switch on, that suggestion wouldn't surprise me at all as it would 'hit' against a centerlines locator. When I actually select the suggestion here is a partial list of what is returned:

When I look at these actual points, they all have the a BLDG_DESIG value of 'W' . It appears that the Prefix Direction of my address (W) is being mistaken for the building identifier. When I fully qualify the address with a unit, it works just great:

While I have not tested this extensively, I'm concerned that if an address were submitted to us that requires a unit designator, but does not come with one we'll get a false positive of epic proportions.

Perhaps I'm missing something in the set up of my locator?

Edited moments later: I changed the mapping from

'PointAddress.BUILDING_NAME AddressPoints.BLDG_DESIG';

'PointAddress.SUB_ADDRESS_BUILDING_UNIT AddressPoints.BLDG_DESIG'

and getting the same results...

Shana Britt‌

Brad Niemand‌

Re: Unexpected Behavior with Pro 2.6 Locator

BradNiemand — Mon, 10 Aug 2020 21:31:46 GMT

Joe,

Building name is not typically used in the USA but some datasets have it modeled in this way. Typically a building name would be a POI that is linked to the PointAddress record like Esri is linked to 380 New York St, Redlands ca...

I am not 100% sure without seeing the reference data but I think you have some units that are actually just building names such as building A or building B. In this case you should map the Building value to the "Building Unit" instead. For your data I would imagine it would be Unit and Building Unit that are mapped. See the highlighted below.

We allow searching on just the building name so likely those are all pretty low scored candidates that matches the "W" as the building name. Likely this is because one of your buildings has the name "W".

Hope this makes sense.

Brad

Re: Unexpected Behavior with Pro 2.6 Locator

JoeBorgione — Mon, 10 Aug 2020 22:22:31 GMT

That's what I did, in the second go round. Our field BLDG_DESIG is mostly empty but there are quite a number of them with the value of 'W'. So I mapped it to Building Unit instead of Building Name.

Apparently there a quite a number of address points where BLDG_DESIG = 'W' ; I just did a selection for it and there are 61 to be precise.

I just don't understand:

1. Where the suggestion is coming from if the only active locator does not have that address in it

2. Where the similarity is between the mystery suggestion and the list of candidates

Re: Unexpected Behavior with Pro 2.6 Locator

BradNiemand — Mon, 10 Aug 2020 22:36:53 GMT

Joe,

Just trying to make sure I understand. The second time when you mapped the building field to the building unit field you got correct results? If so, the results you were getting the first time were because the data that you have really didn't fit the field mapping that you used which caused unexpected behavior.

If the above it not the case, I might not understand and may need some additional information.

Brad

Re: Unexpected Behavior with Pro 2.6 Locator

JoeBorgione — Mon, 10 Aug 2020 22:58:49 GMT

Nope: I got the same erroneous results as I did when I mis-mapped them. I starting from scratch, and this time I'm not going to interject anything related to the building identifier.

Re: Unexpected Behavior with Pro 2.6 Locator

JoeBorgione — Mon, 10 Aug 2020 22:59:48 GMT

But while I have you, how come the Street Name is the only required field in Point Address Role locator?

Re: Unexpected Behavior with Pro 2.6 Locator

BradNiemand — Mon, 10 Aug 2020 23:16:34 GMT

Joe,

Technically the house number is also require but only one of the two sets of options is required. Either House Number, OR House Number To and House Number From. We do give an error before execution if one of either of the two is not populated. It would be equally as confusing if all 3 were required so we went with none of them showing as required with an asterisk in the UI.

Brad

Re: Unexpected Behavior with Pro 2.6 Locator

JoeBorgione — Tue, 11 Aug 2020 14:10:05 GMT

I removed the reference to building and things have settled down to a behavior that makes sense to me. The particular address shown in the original post only has unit numbers; there is no point with the 'base address' Many of our address points with unit numbers do have a base address point without any unit, so they can resolve when a unit identifier is not provided.

In Provide Units In Suggested Addresses , Kevin MacLeod‌ makes a suggestion in providing a user-set parameter limiting the number of returns for address with units. I can see pros and cons for that. The biggest con would be in 9-1-1 dispatch and response; if caller does not provide a unit number in a complex of several hundred units (or more), and the address accepted has a particular unit assigned there could be catastrophic ramifications.

A simple solution for my case presented here is to use a multi-role locator that includes a street address role. When working in 9-1-1 dispatch, I considered that approach to be best practice as you never know what address a distressed caller will provide.

Re: Unexpected Behavior with Pro 2.6 Locator

BradNiemand — Tue, 11 Aug 2020 20:01:05 GMT

Joe,

Are you saying that in the case where a base address does not exist in the Point Address dataset it is better to fall back to a Street Address location instead of an arbitrary unit associated with the address? If so, I would say that even better than that would be if there was a process to ensure that every complex has a base address point location without any unit as well. It could just be the centroid of the complex but it would be better than an interpolated Street Address location in my opinion.

If I have misinterpreted you comments, I might need some further clarification of what you are trying to describe.

Brad

Re: Unexpected Behavior with Pro 2.6 Locator

JoeBorgione — Tue, 11 Aug 2020 20:16:44 GMT

I would say that even better than that would be if there was a process to ensure that every complex has a base address point location without any unit as well. It could just be the centroid of the complex but it would be better than an interpolated Street Address location in my opinion.

I don't disagree with you Brad, but due to the authoritative agency ownership of the address point data, I'm not in the position to add any points. I don't make the rules, I just gotta live by them! We are in a transition period and the agency I work for will take over ownership later this fall, and that's when I'll fix those exactly how you describe.