Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

If I leave any important information out, let me know and I will append what I can.

I am running into this problem when using the geocoder to locate various addresses in Quebec with ArcMap 10 SP1. The type is US Dual-Ranges, and I am using the FSA (no LDU) for Zone/Zip. My Address Locator appears to recognize all of the French road types. Diacritics were removed to normalize the street names between locator and addresses, and apartment numbers were removed.

The issue I am currently wrestling with is that many addresses that fail with absolutely no matches quite suddenly find several as soon as the prefix type is removed. The one we shall focus on is Ch or "Chemin." After receiving the first address match results, I opened the review window to attempt a few manual matches. Here is what I found regarding the pretypes.

With the CH prefix present, there are no matches: enter image description here http://i.imgur.com/8QTup.png

When I remove the CH prefix, however, the story changes: enter image description here http://i.imgur.com/DsZCu.png

From what I understood of the Geocoding process, the address given should be parsed for its component parts and matched against the locators. How is it, then, that removing one of the most integral parts of the match (the prefix) allows it to match? Even worse, why does leaving it in prevent any matches? The prefix type is even present in the locator, as shown in the second image.

What is going on?

share|improve this question
    
Download here @ resources.arcgis.com/gallery/file/geocoding/… –  D.E.Wright Aug 11 '11 at 21:13
    
"No streets here, mon ami" :-)) +1 !! –  Petr Krebs Aug 12 '11 at 13:15

1 Answer 1

up vote 2 down vote accepted

There is a known issue (I had a ticket/bug logged #NIM060261) that had this as the description, "The Standardize Address tool outputs incorrect values for 'PreType' output column when using the US Address - Single House style with ArcGIS Desktop 10.".

So if you call ESRI and reference this bug they should be able to help you; it was supposed to be fixed as of SP2; but I have not fully verified based on time that it is 100%.

share|improve this answer
    
I've never used the Standardize Address tool before. Is it done behind the scenes whenever an address field is supplied for geocoding? –  Nathanus Aug 11 '11 at 20:30
    
Its not specific to that tool; but whenever you geocode yes ESRI standardizes the address elements to increase the quality of the results. And in this case for me and for you the PreType gets butchered or for me gets switched to another value resulting in bogus results.<br><br>Short answer; the PreType values are getting very dirty at 10. I just pushed back to my reps asking them to find out why this still is flagged as open, and not resolved for SP3 or a hotfix. –  D.E.Wright Aug 11 '11 at 20:39
    
Let me know how that goes. What workaround was suggested in your case? –  Nathanus Aug 11 '11 at 20:40
    
The answer was to use the 9.3.1 style locators versus the 10. So really its not a fix, they just didn't want to commit the resources at the time. If you use the older style locator type to build your geocoders then the older engine runs as it was explained to me. But I think that is just a a temp thing since they keep talking/writing about the improvements in the newer engine. –  D.E.Wright Aug 11 '11 at 20:56
1  
This worked perfectly. Thanks again! –  Nathanus Aug 24 '11 at 19:52

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.