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:
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.
Well, it would be a good idea to try and isolate this issue. I would suggest trying this on 9.3 File geodatabase and observing the results. You can use create file geodatabase tool to create 9.3 geodatabase
ArcGIS Help (10.2, 10.2.1, and 10.2.2)
You can copy your address locator to this geodatabase or create new address locator in this geodatabase (using small sample of data) and then testing the behavior. The results would help to isolate this issue being locator engine specific (Desktop issue) or SDE specific (geodatabase issue).
Based on the results of testing above we all can take this issue further.
Hope this makes sense!
What exactly does this import wizard do? Could it be clobbering things?
I think the suggestion above is a good one; just build a locator with 10.2 that point to your 9.3 SDE feature class. My only additional suggestion is to not include the locator(s) as database objects but rather store them in their stand alone directory.