New geocoding engine is terrible.

[DanMarrier]

I really can't figure this one out.  It flies in the face of the hierarchical priority for composite locators that we've been led to believe is in place.

I have a composite locator service that makes use of 9 individual locator services.  Each of those 9 individual locator services has been tested and works as expected when run by itself on a given input address list.

For a specific address in my data set, I know ahead of time that the first locator service in the composite will not find a match when run as a standalone, but the second locator service will, as will some of the subsequent locator services lower in the hierarchy, although the later ones are more prone to errors.

However, when I run this address through the composite locator service, the second locator service is not returning a match.  It ends up defaulting to the fourth locator service in the composite, and that service is actually returning a bad point location because I'm allowing for tied scores to be matched, and it is randomly picking the wrong one.

How on earth can a locator service find a match for an address when run by itself, but not when run in a composite where no locator higher than it in the hierarchy finds a match???

As an additional slap in the face, if I input just an address and a zipcode, and the locator finds the address in a different zipcode, the reported score is 95 out of 100.  Really???  95???  I would expect the default settings of any geocoding service to report a significantly lower score than 95 when the "matched" Zone is completely different than the one I input! 

There also seems to be no heuristic or even common sense when making a match to a different zipcode.  I know of at least one case where the input zipcode has been miskeyed as "02113" instead of "02133".  But due to the highly arbitrary nature of matching tied score records... the "matched" address has a zipcode of "12508"... that's not even in the same state!!!  You'd think that there would be some sort of additional check that if scores are tied and there are different zone values in play, that the one which more closely resembles the input would get a higher priority.

Has anybody else tested a composite service where an individual locator service works for a given address but fails when implemented in the composite?

[DanC]

Screenshot of the composite locator attached.

Dan

[BradNiemand]

Can you give me a list of the locators from the top level to the last locator with the following:

1. Locator Style (with ArcGIS version) ex. US Address - Dual Ranges (ArcGIS 10)
2. Zone fields locator was built with.  ex. city, state and zip     or      just zip
3. Field Mapping - ex. Street = _Street, Unit = _Unit, ...

Brad

[DanC]

1. Address Points Municipal City - US One Address with House Unit and Zone, 9.2, City
2. Address Points Postal City - US One Address with House Unit and Zone, 9.2, City
3. Same as #1, with lower minimum match score of 80.
4. Same as #2, with lower minimum match score of 80.
5. Same as #1, with lower minimum match score of 60.
6. Same as #2, with lower minimum match score of 60.
7. Parcel Points Postal City - US One Address with House Unit and Zone, 9.2, City
8. Local Street Centerlines Municipal City - US Streets with Zone, 9.3, City
9. Local Street Centerlines Postal City - US Streets with Zone, 9.3, City
10. Regional Street Centerlines - US Streets with Zone, 9.3, City

Field Mapping for the first 7 (Point data):
Street = _Street
Unit = _Unit
Zone = _Zone

Field Mapping for the rest (Line data):
Street or Intersection = _Street
Zone = _Zone

These locators are only for our 'City' zones, I have another composite locator that changes out the zone for Zip code fields.

[BradNiemand]

This issue that you are seeing is not related to what is in this thread because the thread is specific to 10.0 locators in a composite.  I would open a call with tech support.

Brad

[ChristianMalmquist]

I support the choice of name for this topic!

I spent ages setting up the geocoder for a small non-US datasett and would have saved time doing it manually or with a python script calling the google api.

Even went looking for the ArcView 3.1 install disks as its geocoder, albeit simple, actually did the job without any hassle 🙂