Hoping someone out these can explain this issue: We are currently in the process of migration some location processes (using the Omega Groups Import Wizard) that will leverage multiple locators to best geocode a list of public safety call activity. We are currently running a similar process between 9.3.1 Locators and our 9.3.1 SDE environment - upgrading to a 10.2.2 environment that (at this time) still is utilizing the 9.3.1 feature classes to do the address matches. We are seeing inconsistencies between the old and new processes, in particular, and what seems odd to me, is how some addresses are scoring 100% on an address point match where the Street Number is incorrect - we have the locators running in a pseudo composite mode (the omega tool allows for stacked locating processes - where the application starts at the tightest location desire and works it way down through looser and looser control in a hope to actually grab some location in the end) - however, a handful of addresses exhibit (incorrectly) 100% scores and place the point in a completely incorrect spot - it is not consistent, but is consistent for particular addresses in the collections:
Example:
8300 W PINNACLE PEAK RD (this is an intersection address)
Geocodes to an address point:
10835 W PINNACLE PEAK RD (a mere 25 blocks away from the actual intersection)
I can see that the program might see the directional, street name and type as being valid, but it should not score 100% in this effort.
Is anyone else having issues with locators in 10.2.2 running against SDE data in an older version?
Thanks in advance for any advice.
Tim
