Latest Contributions by KarynBackus

I contacted ESRI tech support because I was hesitant to edit the .lot file myself. I needed ESRI to make several customizations to the .lot file to improve geocode success for CT addresses. As part of it, ESRI adjusted the score weights for some of the address elements. In looking at their changes, it appears that they doubled the score weights for the prefix, suftype, and suffix. This seems to have increased the penalty when these fields do not match. Since these edits were made in addition to some others, I can't say what their individual impact was. But upon review of the match scores, I was able to determine that a 90% match score gives me the match quality that I was looking for, where previously it was closer to 95%. With the greater weights for the elements, a 90% works better for me because it allows for penalties due to spelling sensitivity that were lost with a 95% criteria. From the customized ESRI file: <!--Street name elements and their assigned weights--> <def name="FullStreetName"> <alt> <elt ref="prefix" weight="10" stan_weight="11" pre_separator="required" post_separator="required"/> <elt ref="pre_type_no_sthwy" match_as="pretype" weight="6" stan_weight="1000" /> <elt ref="StName" weight="70" stan_weight="10" pre_separator="required" post_separator="required"/> <elt ref="suftype" weight="14" stan_weight="1000"/> <elt ref="suffix" weight="10" stan_weight="15" pre_separator="required"/> </alt> <alt fallback="true"> <elt ref="prefix" weight="10" stan_weight="11" pre_separator="required" post_separator="required"/> <elt ref="pre_type_sthwy" match_as="pretype" weight="6" stan_weight="2000" /> <elt ref="OptHyphen" weight="0"/> <elt ref="StName" weight="70" stan_weight="10" pre_separator="optional" post_separator="required"/> <elt ref="suftype" weight="14" stan_weight="1000"/> <elt ref="suffix" weight="10" stan_weight="15" pre_separator="required"/> </alt> </def> Hope this helps. -Karyn ... View more

Thank you for posting this!   I see this will be handy to my project. ... View more

Kim, I believe that ArcToolbox still has the Standardize Address tool available.  The standardized address output function is no longer a part of the address locator, but the tool can be used on your input addresses or on your matched/unmatched addresses independent of the geocoder. ... View more

Excel doesn't always maintain variable properties as it goes back and forth between programs.  If the zipcode in Excel is being displayed with the preceding zero because the zipcode format has been applied to that cell/column, then the data is still considered numeric.  Also, even if the zipcode data column has been changed to text format, your data may not retain that property when being read into another program. For ArcGIS, I always save my data tables in dbf format.  You can save your excel file as dbf, but check to be sure the preceding zero was maintained.  Also, you can always convert your Excel table into an ArcGIS table via ArcCatalog.  This would be the preferred method to ensure compatibility between your table and ArcGIS processing. ... View more

In v10 just like 9.x, when you create an address locator, you pick the fields from the reference database that match the address locator elements.  In v10, at the bottom of the field selections, there is the option to select an additional (L and R if using Dual Range Style) field from the reference database that will be output with the matched results.  For my projects, I choose the unique identifier in the reference database as the additional field.  This way, I can look at my results and link each matched result back to the candidate it matched to in the reference database because the unique identifier value is listed as the User_fld. ... View more

Brad,  This customization will be very helpful.  For my projects, we geocode by both town and zip code but then we want to geocode remaining addresses by just one zone.  I could not get the v10 composite address locator to properly apply the individual address locators because it always expected both town and zip even when an address locator was created using only 1 zone. I will try your proposed solutions.  Thank you. Also, you may want to tag or repost this thread since the title is not representative of your very valuable solution. ... View more

In 9.x, the matching of ties is arbitrary.  As I understand it, the first candidate that matches at 100% is used.  If choosing not to match when candidates are tied, then cases with duplicate candidates with the same geometry will remain unmatched.  This can be an issue when using alternate names (like 10th St and Tenth St).  In v10, the documentation states that candidates with the same geometry will not be considered Ties.  This avoids the 10th vs Tenth issue.   However, matching of ties with different geometry is still arbitrary. ... View more

As a specific example:  110 N Main St matches to 110 E Main St at 97% I do not want a N Main St to match to an E Main St and I would have thought the penalty for a different pre-directional would be greater. ... View more