Address geocoding

In 1960, the first operational GIS – named the Canada Geographic Information System (CGIS) – was invented by Dr. Roger Tomlinson, who has since been acknowledged as the father of GIS. The CGIS was used to store and analyze data collected for the Canada Land Inventory, which mapped information about agriculture, wildlife, and forestry at a scale of 1:50,000, in order to regulate land capability for rural Canada. However, the CGIS lasted until the 1990s and was never available commercially.

On 1 July 1963, five-digit ZIP codes were introduced nationwide by the United States Post Office Department (USPOD). In 1983, nine-digit ZIP+4 codes were brought about as an extra identifier in more accurately locating addresses.

In 1964, the Harvard Laboratory for Computer Graphics and Spatial Analysis developed groundbreaking software code – e.g. GRID, and SYMAP – all of which were sources for commercial development of GIS.

In 1967, a team at the Census Bureau – including the mathematician James Corbett[4] and Donald Cooke[5] – invented Dual Independent Map Encoding (DIME) – the first modern vector mapping model – which ciphered address ranges into street network files and incorporated the "percent along" geocoding algorithm.[6] Still in use by platforms such as Google Maps and MapQuest, the "percent along" algorithm denotes where a matched address is located along a reference feature as a percentage of the reference feature's total length. DIME was intended for the use of the United States Census Bureau, and it involved accurately mapping block faces, digitizing nodes representing street intersections, and forming spatial relationships. New Haven, Connecticut was the first city on Earth with a geocodable streets network database.

In the late 1970s, two main public domain geocoding platforms were in development: GRASS GIS and MOSS. The early 1980s saw the rise of many more commercial vendors of geocoding software, namely Intergraph, ESRI, CARIS, ERDAS, and MapInfo Corporation. These platforms merged the 1960s approach of separating spatial information with the approach of organizing this spatial information into database structures.

In 1986, Mapping Display and Analysis System (MIDAS) became the first desktop geocoding software, designed for the DOS operating system. Geocoding was elevated from the research department into the business world with the acquisition of MIDAS by MapInfo. MapInfo has since been acquired by Pitney Bowes, and has pioneered in merging geocoding with business intelligence; allowing location intelligence to provide solutions for the public and private sectors.

The end of the 20th century had seen geocoding become more user-oriented, especially via open-source GIS software. Mapping applications and geospatial data had become more accessible over the Internet.

Because the mail-out/mail-back technique was so successful in the 1980 Census, the U.S. Bureau of Census was able to put together a large geospatial database, using interpolated street geocoding.[7] This database – along with the Census' nationwide coverage of households – allowed for the birth of TIGER (Topologically Integrated Geographic Encoding and Referencing).

Containing address ranges instead of individual addresses, TIGER has since been implemented in nearly all geocoding software platforms used today. By the end of the 1990 Census, TIGER "contained a latitude/longitude-coordinate for more than 30 million feature intersections and endpoints and nearly 145 million feature 'shape' points that defined the more than 42 million feature segments that outlined more than 12 million polygons."[8]

TIGER was the breakthrough for "big data" geospatial solutions.

The early 2000s saw the rise of Coding Accuracy Support System (CASS) address standardization. The CASS certification is offered to all software vendors and advertising mailers who want the United States Postal Services (USPS) to assess the quality of their address-standardizing software. The annually renewed CASS certification is based on delivery point codes, ZIP codes, and ZIP+4 codes. Adoption of a CASS certified software by software vendors allows them to receive discounts in bulk mailing and shipping costs. They can benefit from increased accuracy and efficiency in those bulk mailings, after having a certified database. In the early 2000s, geocoding platforms were also able to support multiple datasets.

In 2003, geocoding platforms were capable of merging postal codes with street data, updated monthly. This process became known as "conflation".

Beginning in 2005, geocoding platforms included parcel-centroid geocoding. Parcel-centroid geocoding allowed for a lot of precision in geocoding an address. For example, parcel-centroid allowed a geocoder to determine the centroid of a specific building or lot of land. Platforms were now also able to determine the elevation of specific parcels.

2005 also saw the introduction of the Assessor's Parcel Number (APN). A jurisdiction's tax assessor was able to assign this number to parcels of real estate. This allowed for proper identification and record-keeping. An APN is important for geocoding an area which is covered by a gas or oil lease, and indexing property tax information provided to the public.

In 2006, Reverse Geocoding and reverse APN lookup were introduced to geocoding platforms. This involved geocoding a numerical point location – with a longitude and latitude – to a textual, readable address.

2008 and 2009 saw the growth of interactive, user-oriented geocoding platforms – namely MapQuest, Google Maps, Bing Maps, and Global Positioning Systems (GPS). These platforms were made even more accessible to the public with the simultaneous growth of the mobile industry, specifically smartphones.

The 2010s saw vendors fully support geocoding and reverse geocoding globally. Cloud-based geocoding application programming interface (API) and on-premises geocoding have allowed for a greater match rate, greater precision, and greater speed. There is now a popularity in the idea of geocoding being able to influence business decisions. This is the integration between the geocoding process and business intelligence.

The future of geocoding also involves three-dimensional geocoding, indoor geocoding, and multiple language returns for the geocoding platforms.

Input data are the descriptive, textual information (address or building name) which the user wants to turn into numerical, spatial data (latitude and longitude) – through the process of geocoding.

Input data is classified into two categories: relative input data and absolute input data.

Relative input data are the textual descriptions of a location which, alone, cannot output a spatial representation of that location. Such data outputs a relative geocode, which is dependent and geographically relative of other reference locations. An example of a relative geocode is address-interpolation using areal units or line vectors. "Across the street from the Empire State Building" is an example of a relative input data. The location being sought cannot be determined without identifying the Empire State Building. Geocoding platforms often do not support such relative locations, but advances are being made in this direction.

Absolute input data are the textual descriptions of a location which, alone, can output a spatial representation of that location. This data type outputs an absolute known location independently of other locations. For example, USPS ZIP codes; USPS ZIP+4 codes; complete and partial postal addresses; USPS PO boxes; rural routes; cities; counties; intersections; and named places can all be referenced in a data source absolutely.

When there is a lot of variability in the way addresses can be represented – such as too much input data or too little input data – geocoders use address normalization and address standardization in order to resolve this problem.

Take for example: 742 Evergreen Terrace

Let's say that this segment (for instance, a block) of Evergreen Terrace runs from 700 to 799. Even-numbered addresses fall on the east side of Evergreen Terrace, with odd-numbered addresses on the west side of the street. 742 Evergreen Terrace would (probably) be located slightly less than halfway up the block, on the east side of the street. A point would be mapped at that location along the street, perhaps offset a distance to the east of the street centerline.

However, this process is not always as straightforward as in this example. Difficulties arise when

• distinguishing between ambiguous addresses such as 742 Evergreen Terrace and 742 W Evergreen Terrace.
• attempting to geocode new addresses for a street that is not yet added to the geographic information system database.

While there might be a 742 Evergreen Terrace in Springfield, there might also be a 742 Evergreen Terrace in Shelbyville. Asking for the city name (and state, province, country, etc. as needed) can solve this problem. Boston, Massachusetts[9] has multiple "100 Washington Street" locations because several cities have been annexed without changing street names, thus requiring use of unique postal codes or district names for disambiguation. Geocoding accuracy can be greatly improved by first utilizing good address verification practices. Address verification will confirm the existence of the address and will eliminate ambiguities. Once the valid address is determined, it is very easy to geocode and determine the latitude/longitude coordinates. Finally, several caveats on using interpolation:

• The typical attribution of a street segment assumes that all even numbered parcels are on one side of the segment, and all odd numbered parcels are on the other. This is often not true in real life.
• Interpolation assumes that the given parcels are evenly distributed along the length of the segment. This is almost never true in real life; it is not uncommon for a geocoded address to be off by several thousand feet.
• Interpolation also assumes that the street is straight. If a street is curved then the geocoded location will not necessarily fit the physical location of the address.
• Segment Information (esp. from sources such as TIGER) includes a maximum upper bound for addresses and is interpolated as though the full address range is used. For example, a segment (block) might have a listed range of 100–199, but the last address at the end of the block is 110. In this case, address 110 would be geocoded to 10% of the distance down the segment rather than near the end.
• Most interpolation implementations will produce a point as their resulting address location. In reality, the physical address is distributed along the length of the segment, i.e. consider geocoding the address of a shopping mall – the physical lot may run a distance along the street segment (or could be thought of as a two-dimensional space-filling polygon which may front on several different streets — or worse, for cities with multi-level streets, a three-dimensional shape that meets different streets at several different levels) but the interpolation treats it as a singularity.

A very common error is to believe the accuracy ratings of a given map's geocodable attributes. Such accuracy as quoted by vendors has no bearing on an address being attributed to the correct segment or to the correct side of the segment, nor resulting in an accurate position along that correct segment. With the geocoding process used for U.S. Census TIGER datasets, 5–7.5% of the addresses may be allocated to a different census tract, while a study of Australia's TIGER-like system found that 50% of the geocoded points were mapped to the wrong property parcel.[10] The accuracy of geocoded data can also have a bearing on the quality of research that uses this data. One study[11] by a group of Iowa researchers found that the common method of geocoding using TIGER datasets as described above, can cause a loss of as much as 40% of the power of a statistical analysis. An alternative is to use orthophoto or image coded data such as the Address Point data from Ordnance Survey in the UK, but such datasets are generally expensive.

Because of this, it is quite important to avoid using interpolated results except for non-critical applications. Interpolated geocoding is usually not appropriate for making authoritative decisions, for example if life safety will be affected by that decision. Emergency services, for example, do not make an authoritative decision based on their interpolations; an ambulance or fire truck will always be dispatched regardless of what the map says.