Hi Brad, I have been doing a ton of testing, using addresses across the nation with your updated locator, and have a couple issues to report. Using your locator with the standardize addresses tool, all street names with two words, and no street type or suffix directional or unit type / num, are parsed incorrectly. The second word in the street name gets placed into the ADDR_UN field. For example, try to run standardize addresses with "100 RACING WINDS". WINDS gets parsed to UN. There are lots of streets and addresses under this scenario. This in turn is messing up results for geocoding / get address candidates. So, if you have 100 RACING WINDS in your data, you use your locator, and run geocode to find the same address, it doesnt match. However, 100 RACING # WINDS will match. When you pass in an address without a unit designator to the get candidates method, addresses having a unit are ranked the same as an exact match without a unit. This effectively means that the geocoding operation does not perform correctly for any location having secondary addresses (has units) AND a primary address (no units), such as an apartment building with a office at the primary address. As a result of these issues, my code has to look at an address, determine if there is a secondary using our own parser, then based on presence / absence of secondary either use your locator with every address in my data, or the US Address (no units) locator with ONLY the addresses in my data that lack unit type and num - very clunky and not possible for most other users. Who do you recommend that I contact at esri to work through these issues? Are you actively updating this locator? I would be happy to provide additional documentation / screenshots of the discrepancy patterns. Thank you, Roy We're experiencing the same problem as Roy described. Strangely, for addresses have only house number, street name, and street type, some of them are parsed correctly, but some not. A lot of the incorrectly parsed addresses have street names which could be a street type and indeed are in suf_type in grammar section of the style file. For example, "234 front st" cannot be parsed correctly, with "front" being placed in street type, "s" in unit type, and "t" in unit number. "300 mission rd" cannot be parsed correctly, with "mission" placed in street type, "rd" in unit number. With this incorrect parsing, the match scores are very low. At the other side, "2400 Liberty Dr" is parsed correctly as "Liberty" is not in suf_type in grammar section. So a test was performed to see whether taking out a specific suf_type (e.g. taking out "front" and "mission") would resolve this problem. There was no luck. The technical paper "customized arcgis 10 locators" is really not enough. ESRI, please help.
... View more