According to the ArcGIS Pro literature (see Street Blocks), searching for Street Blocks should be a function of the locator when creating a custom locator with Create Locator (GP Tool) and a Street Address role. I currently have a multi-role locator (Address Points, Street Address, and POI) built, but this Street Block search functionality does not appear to be working in ArcGIS Pro or via a published GeocodeServer. Address numbers are supplied via Left To/From and Right To/From fields (4 fields total) in the Street Address role, which along with the street name fields would appear to be the key field mappings needed to facilitate this functionality.
Has anyone else ran into this issue or have a suggested fix or troubleshoot? Are their specific fields that need to be mapped or Locator Properties that need to be set. I have home-brewed this functionality by creating my own Mid-Block point features and building them into the POI dataset, but this feels a bit clunky and creates another data workflow to keep track of. I'd rather utilize the built in functionality, or at least be able to weigh the pros / cons between both approaches.
Thanks!
Solved! Go to Solution.
I was finally able to get an address locator that uses centerlines with address ranges as its primary reference table and a Street Address role to return results for street blocks. I tried different combinations of settings in the locator's Geocoding options, but what seemed to finally work is below:
Match with no zones: Yes
Categories to support: All categories supported by the locator.
@ScottFedak2085I'm currently grappling with the very same issue and using a similar mid-block POI workaround for now. It doesn't handle data entry issues and inconsistencies in the table I need to geocode particularly well though.
Like you, I'd at least like to be able to evaluate the street blocks functionality to see if it handles the data issues more gracefully than the POI workaround, especially before I dive into trying to possibly clean up the data. I'm continuing to look into this and will follow up if I'm able to get street blocks to work.
@RogerDiercks1 Thanks for the input and I'm glad I'm not the only one dealing with this.
Like you mentioned, this POI workaround does not handle user entry errors well. I have the POI name formatted as (1800 BLK - N MAIN ST) and suggestions populate well with proper key strokes, but it doesn't account for errors or variations (i.e. 'Blocks', 'BLK, 'Block') very well, you can't search a range of blocks as the literature suggests is possible, and you have to type quite a bit correctly to get a valid candidate if you bypass the suggestions.
I was finally able to get an address locator that uses centerlines with address ranges as its primary reference table and a Street Address role to return results for street blocks. I tried different combinations of settings in the locator's Geocoding options, but what seemed to finally work is below:
Match with no zones: Yes
Categories to support: All categories supported by the locator.
@RogerDiercks1 I was able to reproduce your results with a multirole locator; however, I did not need to set Match with no zones to YES. I was able to get results regardless of how that boolean property was set.
It appears the governing property is to have Categories To Support set to All categories supported by the locator. Screenshot of a configuration that worked for me is at the bottom of this post.
This is unfortunate because I really don't like to support the Street Name category as it is too broad and has limited or no use case for me. In fact, it actually invites more confusion for the fast-paced public safety environment I'm trying to fine-tune some locators for at the moment. It would be nice if Street Blocks was added as it's own category to support. I added this as an idea
I'm glad you got it to work and thanks for adding the idea. I just added my kudo to it.