Geocoding in ArcView with Fuzzy Zones & Resolving ambiguous addresses using Variable Zones.

Author: Bruce Harold

Abstract:

Critical geocoding applications, such as Police response systems, need to achieve the highest possible success rates in geocode location. This may be frustrated by the lack of a usable Zone field in the match data fields, or by variability in the given Zone values. Causes of variability might be colloquial use of multiple names for areas which may also overlap, or uncertainty in correct Zone in border areas. ArcView's standard geocoding technology performs a logical "AND" between Address and Zone score values, severely limiting the tolerance for variability in Zone values. However, the access to these internal processes available through Avenue permits us to solve the problem another way. This paper describes how to make use of a combination of ArcView's tunable geocoding technology and ArcInfo`s Route System data model to resolve ambiguous address geocoding when available zone values are also subject to ambiguity.

Summary:

The problem we are solving here is two-fold. Firstly, you need a zone item but there isn't any officially sponsored one, or secondly, you have zone data but more than one zone value is possible in individual event addresses. Both issues are resolved with the following approach:

-Create an AddressStyle to let you standardise zone values given with event addresses. This step is optional.

-Create a point coverage defining the notional centre of zones you want to allow for.

-Allocate routes from these zone centres, and expand them to overlap to taste.

-Populate an item in the network cover AAT containing a space separated list of RAT# values to which each arc belongs - its zone membership.

-Custom Geocode with zone values, processing multiple candidates with each candidate arc's zone membership in mind.

The picture below shows the typical problem we solve. The Road theme has about 21000 features in Auckland, New Zealand. (Auckland is on an isthmus - the white space is largely sea.) The event address "10 Beach Road" has seven candidates shown as GraphicPoints. The GraphicText beside each candidate shows an unambiguous zone name which the user may use to resolve the address location, or ideally could have used with the event to find it directly. Zone values may be given flexibly to allow for colloquial usage, for instance "Cockle Bay" would resolve as for "Howick".

Illustration - Multiple Candidates for an event address

The Details:

Lets cover each of the bullet points in the summary above:

-Create an AddressStyle to let you standardise zone values given with event addresses (optional).

This paper is not about creating AddressStyles - Esri will give you help in doing this - but it is helpful to pre-process zone values to allow for common abbreviations and aliases in zone values. For instance in the New Zealand context, suburbs often have abbreviations in common use and these must be catered for. "BUCKLANDS BCH" must work as well as "BUCKLANDS BEACH" for instance. Each of the zones to which a candidate belongs has only one name in the routesystem used to store the zones, so this is your chance to handle variability in spellings, aliases and the like. In the scripts supplied with this document you will see the given zone value standardised with the SetKey request for this purpose. This step adds to the robustness of your solution.

-Create a point coverage defining the notional centre of zones you want to allow for.

This is just a digitising job into a point coverage. Make sure you snap to your network/address cover nodes as you go. To make your solution as robust as possible put in any and all places you think may be given as zones. In Auckland, people can use the names of suburbs, beaches, shopping centres, postal districts and so on in addresses, so the more the merrier. A twist in handling the "importance" of places is visible in the legend for the Places theme in the picture following the next paragraph. Universally known zones have been coded with "SBRB" - these are judged to be zones which overlap very little. Locally known zones, judged to be valid within a small travel radius, have the value "LCTY", and these ignore other zones in their overlap tendencies. This behaviour is handled by the AMLs supplied.

-Allocate routes from these zone centres, and expand them to overlap to taste and Populate an item in the network cover AAT containing a space separated list of RAT# values to which each arc belongs - its zone membership.

This requires ArcInfo Network and is handled by a suite of AMLs. You run MAKEROUTES.AML, which calls MAKELCTYS.AML, ALTERITEM.AML and POPLIST.AML, first creating the SBRB routesystem then analysing the network cover AAT to populate a character field with a space-separated list of the internal RAT# values to which each arc belongs. To make the SBRB routesystem, the ALLOCATE command is used, with the CENTERs being taken from your zone centre digitising work. Each output route has a "NAME" field taken from a like field in your zone centroid point set. Individual zones are created in one of two styles. Zones grown from centre points coded as "TYPE" = "SBRB" overlap by a percentage of terminal measure at their border after initial allocation. Zones grown from centre points coded as "TYPE" = "LCTY" are allowed to overlap all other routes until they reach their maximum impedance. The overlap you set for "SBRB" zones is given as an argument to MAKEROUTES.AML - I use 20%, "LCTY" I grow to 2000 m. travel distance. There is little penalty in using these quite large overlaps and radii other than the size of the section table you end up with. Note though that the section table may be deleted after processing, as the zone resolution software only requires AAT and RAT tables at run time. This is a consideration - the Auckland city prototype data set with 158 zone points has 46000 sections over its 21000 arcs. Now examine the picture below:

Illustration - Zone Valence for Address Reference Cover Arcs:

The Zones theme has been gridded from Road theme arcs to 250 metres resolution and analysed and dichromatically symbolised uniquely on the count of zones to which cell arcs belong, from blue to red. Dark blue is single-zone membership, dark red would be ten-zone membership. We get to a count of 7 in the visible area. Remember the white space is NODATA (sea or parkland). The Place theme points are symbolised by type, "SBRB" or "LCTY". You can see the area of high zone membership occurs roughly equidistant from the three ("important") "SBRB" points, and that the "LCTY" points have local effects - adding 1 to membership count within 2 km. travel.

-Custom Geocode with zone values and process multiple candidates with the candidate arc's zone membership in mind.

The project from which these pictures were obtained has a View with a line theme having geocoding properties set to an AddressStyle that does not use a zone item. The View has two View DocGUI buttons added. One permits address location similarly to the standard View.Locate system script.Its Click script is View.ZoneLocate. The other button makes a Geo theme from a project table and adds it to the View. Its Click script is View.ZoneGeocode. Both handle zone information similarly:

+standardise the input address and zone, then..

+score the address, then..

+match if a single candidate & exit, or..

+find multiple candidates with equal score, then..

+accept any single best candidate & exit, or..

+find the zone membership for each remaining candidate, then..

+accept any candidate with given zone in its membership & exit, or..

+ask the user to choose a zone which is unambiguous & exit, or..

+exit

Acknowledgements: Thanks go to Agatha Tang at Esri for her help in AddressStyle construction.

Appendix: AML and Script source:

MAKEROUTES.AML