Latest Contributions by HXiao

I found the same behavior when Match with no zones option is set to No. This option is under Match Options. Change it to Yes solved my problem. ... View more

We have the same question. Our reference data can not match any of the existing locator role in ArcGIS Pro. We had to customize the locator style in ArcMap to build a locator against the data. We're wondering how to customize the locator role in ArcGIS Pro. Does anybody have an idea? Thanks. ... View more

It seems that this has not been fixed in sp1. I received the same error message in 10.1 sp1. Does anybody have a solution? ... View more

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

Hello agray, Thanks for your reply. I could not follow you yet. Do you mind giving a piece of code to help understand the difference? ... View more

Hello, Lionel, I got the same thing as you. Throwed an exception, but my feature was deleted without any message. Did you find a solution? Thanks. ... View more

We have been waiting this for years too. ... View more