Geocoding Developer's Kit for ArcGIS 10.0?

[JonHall]

Is there a "Geocoding Rule base Developer Guide", and GDK, for ArcGIS 10.0?

If so, how where may I obtain a copy?
Thanks,
Jon
************************
I looked back a couple months in this forum, and Bruce H. had responded on 8/26/2010 to a similar Q:
"...10.x locators use the all-new geocoding engine in ArcGIS 10. These are customizable via editing the .lot.xml file(s) in the Locators directory. Documentation for this is still under construction, but you should be able to see similarities with the CLS file elements."

Any update on the status of that documentation?
Thanks,
Jon

[BruceHarold]

Hi Jon

The "how to" document on locator customization is still in the works, we are hoping to have it ready not long after SP1.

Regards

[GastonPezzuchi]

Any news on an updated version of ESRI's GDK for ArcGIS 10?

Thanks

[BruceHarold]

Hi

Please download this technical paper:

http://resources.arcgis.com/gallery/file/geocoding/details?entryID=51EE55F8-1422-2418-7F8B-FD82DE958...

Regards

[RonnieRichards]

The technical paper is a great start but I am having difficulties trying to find out how to make exception rules. Is using the GDK9.2 and encoding a .pat still the only way?

Like the example in the GDK (page 62), "123 TRAIL WEST" where trail could be a suffix type and west is also a pre/post direction but "TRAIL WEST" is the accepted street name.

I have tried adding TRAIL WEST to the StreetAlias section of ths USAddress.lot.xml but no luck.

Any advice on how to create a new pattern for street name exceptions?

Thanks
Ronnie

[GabiVoicu]

Hi Ronnie !

I know it has been a while since you have posted this thread but I was just wondering if you ever figured out how to make exceptions rules - trying to do the same thing here.

Thanks a lot

Gabi

[RonnieRichards]

Hello Gabi,

Unfortunately no we have reverted back to the 9.x locator style for units because the 10.x locators are still not documented well or work very well for that matter. We expect an address locator with units to match at 100% and this is not the case in the current versions and locator style.  There are bugs in the new styles.

Below are all of my ArcGIS Ideas, enhancements and bugs which you might consider reviewing and voting for if you agree. Several releases and years later we are still waiting and now looking at 3rd party solutions because when we call support they call this a "Customization" yet no complete documentation exists and we are using the out of the box locator style.

Fully document the Customizing Locator process and update Locator documentation

https://c.na9.visual.force.com/apex/ideaView?id=087E00000005AR4IAM

Standardize Addresses Tool mixed case results and other inconsistencies

https://c.na9.visual.force.com/apex/ideaView?id=087E00000004GOqIAM

#NIM070066   The Standardize Addresses tool does not return the same address standardization using ArcGIS Version 10 address locators as compared to version 9.3.1 address locators.

Update File based locator's reference feature class

https://c.na9.visual.force.com/apex/ideaView?id=087E00000004EhvIAE

Locator style for Apartment / Units in core product

https://c.na9.visual.force.com/apex/ideaView?id=08730000000by67AAA

#NIM081240   [Enhancement] Please add support for building/unit/apartment numbers in the standard locator styles.

#BUG-000093854   When using the US Address-Single House Subaddress locator style with the Find tool, the match score is improved if using '#' as the unit indicator instead of 'APT' even if the original input data uses 'APT'.

#NIM059962   Cannot create an address locator with a multipoint shape file. The result is a Background Processing Error or ArcGIS Application Error.

schemaLockingEnabled for Geocode services

https://c.na9.visual.force.com/apex/ideaView?id=087E0000000CxTRIA0

[MichaelVolz]

So geocoding addresses with apartment numbers gets better match rates than the OOTB v10 address locator that is supposed to handle sub-units?

[RonnieRichards]

Yes the fix is we have to change our APT values to # which is very silly when the source data matches USPS standards. The locator supports the unit_type column and it is mapped to our column but clearly does not work. Changing to a # only provides a 98.0 score because the unit_type does not match, huh?? Something is wrong here and improving the scoring is not documented anywhere.

This is what #BUG-000093854 refers to. Give it a try with your source data. W were not happy with the results and we have wasted months of time trying to get it to work well.

[GabiVoicu]

Not sure if this helps, but we did try to change the weight of unit type (apt) to zero when scoring and that seems to allow 100 matching rate with apt included in the address…

(but exclude unit type from your locator when you build it)

We changed this part in the original USAddressLocator

……………………………..

………………………………………………

Gabi