Much of the data we store, retrieve, and analyze has a spatial component, and when exploring data to make decisions, maps can be hugely valuable. Modern database systems have the ability to store and reason about location and geometric information natively, and users are increasingly taking advantage of these capabilities. Nonetheless, it’s common for location to be expressed implicitly, for example as addresses or names of regions.

In some cases, data is truly spatial while the representation is not. For example, you might have an Excel spreadsheet that contains a lat/long location for each row. Or, you might have data in a format that describes airport runways in terms of location, length, and orientation. These are simple cases to deal with; all that’s necessary is to build a geometric representation using the values at hand.

A more challenging (and common) case is to extract locations from addresses. This is called geocoding. You can go backwards too – reverse geocoding starts with a location and looks for an address. Geocoding is very data intensive; for it to work, you need to know where all the addresses are, or have a model that can predict the answers. And geocoding is big business: there are many companies providing geocoding services, software, or supporting data. Safe isn’t in the geocoding business, but we want our ETL software to be a great platform that plugs into others’ geocoding solutions.

Given recent interest, I took the opportunity to take a look at some of the ways you can geocode addresses with FME.

One set of options is to access web services to do the job. It’s easy to do this within FME, either by building a query URL and fetching the result, or by embedding a Python script for extra flexibility. On fmepedia, you can find examples of accessing Yahoo’s geocoder (by building a query in the context of this great example, or via Python), or Google’s geocoder also via Python. Some of these may require editing to get working, e.g. the last example is tailored for Germany, and includes reprojecting the lat/long results into a local coordinate system.

There’s another simple option available. We added native support for Proxix’s PxPoint geocoder, recently discussed here. All you need to do is arrange for service from Proxix and drop a ProxixGeocoder transformer into your ETL workspace.

Geocoding helps make the jump from charts and graphs to maps, which in turn can offer greater context and insight. Happy geocoding!

About Data Convergence Coordinate Systems Interoperability Location Intelligence Spatial Databases Transformation

Paul Nalos

Comments

One response to “Geocoding: Extracting Value from Non-Spatial Data”

  1. […] or import arbitrary geometry from KML. Addresses and place names are automatically converted (geocoded) into map locations, and users can fix incorrect locations using a search-and-select procedure. […]

Leave a Reply to Google Evolves Spatial Offerings with Fusion Tables | It's All About Data Cancel reply

Your email address will not be published. Required fields are marked *

Related Posts