Yeah, I have had a long discussion with support about this issue. True, a StreetAddress role will return a location but it's really not useful when it is a 1000 feet from the actual address location. Our street segments have theoretical address ranges not actual ranges. So, the range may be 4000-4099 but the real range only goes to 4024. This causes the StreetAddress point to be misplaced along the street segment.
We have been using the FindAddressCandidates method (from 10.3 locators) to help users find ACTUAL address point - for years. We would take the returned address candidates and sort the results based on score and proximity to the entered house number (i.e. user enters 4231 [which doesn't exist] we would sort the results of actual address points as follows 4232,4229, 4231, 4228.....) This also allowed us to provide the user with additional info from the actual address points (parcel id, owner name, etc.) so they could select the correct address. We could also search/sort the results for other street names (user enters Broadway - we would show them the actual street names Old Broadway, N Broadway, & S Broadway).
The new methodology breaks our existing apps, but we will adjust. Suggestions, which we have never used because they were kind of squirrely - ghost addresses and such, will help, but that too requires changes to the applications. We have discussed the new locators at length in the office and really find the changes....just strange. We were simply updating some processes that rebuild the locators every night and thought we would go ahead and move to the new Pro locators when we discovered the issue. Support has made it clear that it works as designed and that we should move to the new model. And we will, just not very quickly.
Thanks for replying.
