Prevent near street intersections from being matched using ArcGIS Pro Create Locator

j_rsg · ‎01-24-2023

Hi. I'm using the Create Locator 2.9 tool to build a Locator for matching street intersections. I would like the locator to prevent matching invalid intersection locations. For example, in the screenshot below it is an invalid street intersection address that I do not want the Locator to match. Lassen St & Lassen St should not match in this scenario. However, the locator matches to a location on a perpendicular street between the two parallel streets (Lassen Ct & Lassen St). Not only that, it gives it a pretty high score that would not make it possible to find in a large dataset through score alone.

I realize it would be possible in this scenario to flag this location before geocoding, but seems like this should be preventable (or at least scored significantly lower) when setting up the locator.

Is there a way to prevent this from matching or scoring lower that I am not aware of?

Thanks.

mhudson · ‎02-27-2023

This won't be of any help, but I'm looking at doing somewhat of the exact opposite of what you are wanting to do.

Based on the documentation, there is a default tolerance of 60m for finding "near intersections". I would like to increase this tolerance as we have internal users that like to put in streets that may or may not have an intersection just to get them to the area faster. This tolerance appears to be larger for the World Geocoder.

If you happen to hear of a way to increase/decrease this tolerance, please share.

Thank you!

ShanaBritt · ‎02-27-2023

You can increase the minimum match score and minimum candidate score to 96 and this intersection wouldn't match during batch geocoding or return as a candidate when searching in the Locate pane.

You may want to consider submitting this as an idea for an enhancement so that it can be evaluated.

-Shana

j_rsg · ‎02-28-2023

Thanks Shana. Adjusting the minimum match score would exclude this record, but numerous valid matches as well. The score is way too high to differentiate it from other valid geocoded locations. I think the matched score should be much lower for this scenario.

I would certainly welcome more advanced configuration options for locators. A near intersection configuration option would be helpful (and perhaps help out mhudson).

I'll try to submit an enhancement idea as I continue exploring creating locators compared to the previous experience in arcgis desktop.

Thanks.

ShanaBritt · ‎03-20-2023

If you run into something while upgrading your locators to those created with the Create Locator tool that is not clear or works unexpectedly please post a question here or submit something to Support. I would encourage you to review the help section for Geocoding, below are some to get started.

j_rsg · ‎04-14-2023

Thanks, I've submitted an idea here:

https://community.esri.com/t5/arcgis-pro-ideas/create-locator-additional-options-when-creating/idi-p...

And since another example came up in our work, I'm adding a second example showing the same issue with another outcome for reference.

This intersection address at San Fernando Rd & Cypress Ct does not have an exact match. However, ArcGIS Pro gives multiple candidates. The first image highlights a near intersection match between San Fernando Rd & Cypress Ave.

The second image shows a location slightly further north where San Fernando Rd intersects a Cypress St. This seems like a more likely candidate for our work, but it has the same score as the near intersection so is not matched in this example. If the near intersection was not active for this we would have matched to the more likely result.

jsg · ‎07-20-2023

This is an issue in our applications that rely on Esri geocode services as well. I understand Esri may be trying to accommodate for bad street data here, but for emergency response/routing to locations these phantom intersection results are a major problem. Either a configuration setting in the locator, or a property in the response indicating "nearby" is needed so these can be filtered out by the client. I have submitted this to Esri as ENH-000154208.