I have some questions about bare street matching.
I'm noticing that "8th Ave, New York. NY" is returning "8 Avenue A", is there a reason?
Additionally, I'm seeing that even with "?match=range" the geocoder try to find addresses even when I give it a bare street. For instance, Ludlow St, New York, NY yields multiple hits: 1 Ludlow St, 6 Ludlow St, 13 Ludlow St, 17 Ludlow St ... is that expected? If I want high confidence that smartystreets found a match for a bare street, should I tell it x-standardize-only: true, candidates = 5, and check that all the results returned have dpv_footnotes=AAM3 and are all the same street?
Our system is designed to give a positive match on a valid address. As a byproduct, it standardizes address data and corrects spelling where possible. Giving it a street without a primary number (house number) causes it to buckle, as you've found. At that point, it reverts to returning the the first 10 (H)ighrise candidates on that street, or a similar street. This won't work for you and we are looking into how to correct that issue.
It will also not work for you to enter a single number every time, such as 2 stanton, because on Stanton St, the valid range is 1-23 (odd), 4-26(even), 9,10,11,13,15,15,19,25-39 (odd), 28-40 (even), 41-59 (even), 42-58 (even) and so on. If you were to choose the number 2 as your "generic" address, it would fail because it's not in the range. Picking a 100 is a better option as many more streets have a 100, but not all of them.
I'm recommending that for each location that you want to validate, you submit a batch to us. Processing a batch of up to 100 addresses is just as fast as submitting a single address, so you lose no time with this method. So, with the three streets that you gave me 8th ave, ludlow, and stanton, I would generate a batch API request that contained addresses that look like this:
and so on (that way it hits odd and even addresses).
You'll need to hone the batch to give you the best possible results with the fewest addresses. Perhaps 25, 50, 75,100 and so on would be enough. Now, in interpreting the results, you'll see a number of different footnotes in the analysis. (dpv_footnotes and footnotes) These will help you to see what was done to the address.
Input: 2 stanton new york ny
Output: [ ] (it's not within the valid street range)
input: 25 stanton ave new york ny
Output: 25 Stanton St New York NY ("St" designator corrected)
input: 50 stanton new york ny
Output: 50 Stanton St New York NY ("St" designator appended)
input: 75 stantn new york ny
Output: 75 Stanton St New York NY (street spelling fixed)
input: 100 stantin new york ny
Output: 100 Stanton New York NY (street spelling fixed)
You would then take the outputs that you got and and, looking specifically at street_name and street_suffix, be able to determine that it is a valid street name. This would work on the back end for a list that you already have or on the front end, in a realtime environment (while your users are entering an address).
(The address 1 8th Ave, and others where there may be a similarly named street in the same 5-digit ZIP Code, will fail. Meaning it will suggest E 8th St and W 8th St. We've found a solution and are working to implement it.)