Customize 10 locator to match resulting candidates seen in 9.3

[CarmenDurham]

Hello all,

I would like to find out what I need to change in the .lot.xml files that would allow the user to "Find an Address" and have the same candidate results shown in the 10 locator as I did the 9.3 locator. Or at least close to the same candidate results. 

We use CityWorks and it uses our SDE locators to allow the user to enter an address and CityWorks essentially returns a list of candidates to them for that address.  It mimics what the "Find Address" tool does in ArcMap. 

Using a locator that uses a layer of Address Points as ref. layer.  IGNORE that the locators are called "Parcels".  This is a naming requirement by Cityworks.

Example search from 9.3 locator:  The user enters 208 S Main St which doesn't exist. Below are the results.  It returns candidates that are at least nearby.
[ATTACH=CONFIG]16004[/ATTACH]


Example search from 10 locator:  the user enters the same address, but no candidate is even shown until I click "show all candidates".  Those candidates are horrible.  What can I alter to make this work more like it does in 9.3?
[ATTACH=CONFIG]16005[/ATTACH]

In 9.3 locators, I had altered us_addr2.mat and some .cls files.  But what I altered there doesn't seem to easily transfer to what I would edit in the USAddress.lot.xml.

I have been looking at the Customizing a Locator in 10 white paper, but was hoping someone could more quickly steer me in the right direction!

Thanks,
Carmen

[Anonymous User]

Original User: khighlan

Does your locator return 100% match score results on correct addresses?

You might be able to play around with the weights in the xml file to get what you want (maybe giving more weight to the address number?), but you need to know what you're looking for.

I would try adding more weight to the "House" element under the NormalAddress Element (assuming this is what your locator is using...) here:

<def name="NormalAddress"><alt selector="supportsWeightedHouseNumber"><elt ref="House" weight="15"/><elt ref="FullStreetName" weight="60" pre_separator="required" separator_list=".,;-"/><elt ref="OptionalUnit" weight="0"/></alt>

Hopefully that works or at least starts you off in the right direction...


-Kevin

[CarmenDurham]

Kevin,

Thank you for replying.  Yes, a correct address returns 100% score. 

I changed the weight for the house number and the effect was that it at least lowered the score for the really bad candidates like 1 N Main St and 1 E Main St, but never "finds" any of the addresses that were 'close' to the house number entered as the 9.3 locator does. 

Even if I changed the minimum match score and minimum candidate score to 1 and "show all candidates", the only other candidates would be those with house number = 1.

I am moving on to seeing if I can make a dual range street centerline based locator work as expected for addresses where the street number is empty so that it will show the different range options to choose from.  Our Cityworks users expect to be able to find a suitable range if the number doesn't match or if they type in just a street name.  I see the "empty street number" option.  Hope I can get that to work or I will be posting another question!

Thanks,
Carmen

[Anonymous User · Accepted solution]

Original User: bruce_harold

Hi Carmen

What you are seeing is a result of the new geocoding engine being very fastidious about not allowing false positives.

In other words, point locations with house numbers numerically close to your input are not good candidates.

That is the (assumed) intent of using point-based reference data, the workaround would be to create a composite locator that included an address range locator and a street name locator under the point-based locator.  That would get you on the page every time; if no parcel point exists with a correct house number a street segment that included the number would be searched for, and if that does not exist then you'll land on the first street centreline segment with the correct name and zone values.

ArcGIS ships with a retired version of Esri StreetMap data for geocoding, if you don't have centreline data to hand.  It is on the Data & Maps DVD.

Regards

[CarmenDurham]

Bruce,

thanks for the information.  Yes, I agree it probably will work wonderfully when I am geocoding tables against our address point data.  No argument there.

The issue is how CityWorks uses locators within their ArcEngine product (Anywhere) for when the user is entering a location for a new work order/service request.  The product doesn't seem to work with composite locators. The user has to switch between an Address Find and a Street Find.  Each "find" is using a different locator.  It acts a lot like the "Find" within ArcMap using a locator.  The users are used to seeing the other address options because it could be one of the other addresses is a better choice than interpolating along a street segment.  If it isn't possible to show those other candidates, then we will just have to inform the Cityworks users to switch to "Streets" and/or pinpoint the location on the screen.

At least I know to stop trying to make it work!

Thanks,
Carmen

[DanMcCoy]

If you would like to see the geocoding in 10.x improved to include the house number matching like in 9.x, you can vote for the following idea:

http://ideas.arcgis.com/ideaView?id=087E000000059oLIAQ

There's also some discussion about this issue in this post:

Re: Locator won't match close street number in single address locator

Dan

[Anonymous User]

Original User: bruce_harold

Hi Carmen

Please point this out to CityWorks.  It sounds like an enhancement request is in order.

Regards