nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Add "Street Block" as a supported category in Locator Properties

ScottFedak2085

It appears that searching for Street Blocks is only supported in a locator if All categories supported by the locator is selected in the Locator Properties (see below). It would be beneficial to have Street Blocks as a selectable category so that it could be allowed while others, like Street Name, are excluded.

Find more posts tagged with

Geocoding

Status: Open

Comments

BradNiemand

I would be interested to know the workflow you are trying to accomplish in more detail. Matches to StreetMidBlock have a specific type of input that contains "Block" or "Block of" at the beginning of the search string. Are you essentially trying to force an unmatched result instead of a fallback to StreetName?

Brad

ScottFedak2085

Hey @Brad, thanks for responding!

There may be other desired workflows, but the main one I would like to accomplish is to be able to allow users to search by Street Blocks but not have to include the ability to search by Street Name. The data I'm working with is more local and for Public Safety dispatching purposes. The Street Name capability often invites more confusing and less helpful geocoding returns, and I've disabled that functionality. However, being able to search for Intersections (already enabled) and Street Blocks (build into POI as a current workaround) is a desired level of search by our public safety personnel. Even though I've found a workaround by building Street Blocks into a POI dataset, the Create Locator built-in functionality for Street Blocks is better than I can probably offer or have time to build-out at the moment.

Thanks again!