Select to view content in your preferred language

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

884
6
01-24-2023 11:25 AM
j_rsg
by
Occasional Contributor

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.

 

 

j_rsg_0-1674587710706.png

 

6 Replies
mhudson
Occasional Contributor

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!

0 Kudos
ShanaBritt
Esri Regular Contributor

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

0 Kudos
j_rsg
by
Occasional Contributor

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.

0 Kudos
ShanaBritt
Esri Regular Contributor
0 Kudos
j_rsg
by
Occasional Contributor

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. 

j_rsg_0-1681492215829.png

j_rsg_1-1681492592583.png

 

 

0 Kudos
jsg
by
New Contributor

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.

Tags (1)
0 Kudos