I used a "US Streets" style locator in 9.3 that is pretty much the "US Address - Dual Ranges" style in 10, except "US Streets" has only 9 mapped fields for the primary table instead of 21 for "US Address - Dual Ranges."
My problem: With the old "US Streets" styles, candidates could be generated by typing in just a street name. A list of address ranges along the street would come up without you typing in an address number. This doesn't work with the "US Address - Dual Ranges" style in 10. The same five fields (attached image) - and only these five - are mapped in both locators, but "US Address - Dual Ranges" seems a lot stricter. Dropping down spelling sensitivity and minimum candidate score doesn't help.
I tried modifying the USAddress.lot file to include a "US Streets" locator, but it fails to create a locator of this custom style.
Does anyone have code for the "US Streets" style that I can drop into USAddress.lot? Or does anyone have any recommendations for getting the "US Address - Dual Ranges" style to yield candidates without an address number being included?
I ended up reverting back to the standard streets locator setup. supportsEmptyHouseNumber broke the results for specific locations on a street range. So "5 st name" would return the same results as "st name."
What we told users who wanted to find the beginning of a street with just "st name" is to enter in the single street name twice, as if it's intersecting itself (which every segment actually is doing). For example "Encinitas Blvd & Encinitas Blvd" takes you to the beginning of the lowest range for Encinitas Blvd. This is my desired result for "Encinitas Blvd" when using supportsEmptyHouseNumber. Our users (not GIS-savvy) have seemed to grasp this "intersecting itself" concept and we no longer have the need for supportsEmptyHouseNumber.