Case Studies

How MAG is Using Placekey with GIS Applications to Efficiently Track Building Inventory, Landmarks, and Employers

How MAG is Using Placekey with GIS Applications to Efficiently Track Building Inventory, Landmarks, and Employers

About Maricopa Association of Governments

Located in Phoenix, AZ, MAG is a forum for local governments to come together and share information to better the lives of the region.  Its members include 27 cities and towns, 3 Native nations, Maricopa County, portions of Pinal County, and the Arizona Department of Transportation, with a total area of 10,600 square miles (Maricopa Association of Governments).

MAG: A Chartered Placekey Product User

After MAG's GIS Program manager, Jason Howard, discovered Placekey— the free, universal identifier for any physical place that lets place data be easily merged across datasets— he quickly alerted Jack Fairfield, a GIS engineer working for MAG. At that point, Fairfield's scope of work included interactive map viewers, as well as server-side coding (python) to enhances various datasets. Not least of these was an employer database with 90,000 points. When it came to the database, Fairfield was heavily involved with a project centered around depublication. Ordinarily, deduplication can can lead to excessive amounts of unnecessary data that takes up precious memory. 

Fairfield explains “The challenge was to clean up, standardize, and deduplicate that data and present it in a way that is useful.". The goal of the project, high-level, was to "do some aggregations and analysis so that we can provide reports to agencies and members of public as well as get the data fed into socioeconomic models". Placekey, it turns out, has capacity to serve as an extremely useful tool in the deduplication of this data, which would "save many man-hours of tedious preparation, cleaning of datasets, and money spent on manhours and space on servers."

How would the operation work? Fairfield explains: "Placekey lets you assign a unique identifier to a location based on the address. If you have several sources of addresses, you might have "123 N Main St" in one, where "North" and "Street" are abbreviated, but in another database, you have "North" and "Street" spelled out. While we might be able to understand that, a computer doesn't know that." Simply put, Placekey resolves differences in two databases that a human understands, but a computer wouldn't.

Once the operation was completed, employers would have identification that could be used universally through multiple datasets. It would also allow for common users to go into MAG’s GIS map viewer and edit any of the metadata such as employer name, alternative name, NAICS code, number of jobs, key industries, and additional feedback.  

Figure 1. Screenshot of MAG’s Arizona Employer Map Viewer. The different sized bubbles represent the number of employees. The bubble layer contains attribute data

Placekey resolves differences in two databases that a human understands, but a computer wouldn't.

To examine the utility to MAG of Placekey without revealing Arizona data, we'll give an extraneous example. The below table represents five data sets for the Empire State Building in New York City. In this case, you as a data analyst want to join all five data sources to capture their respective variables (i.e. steps, floors, height, building cost in 1931 dollars).  

Table 1. Five sources of data on the Empire State Building in New York City. Highlighted in yellow are the different variables each dataset contains.

In this instance, each data set has a piece of information that is not available in the other data set, which is valuable to the end-user.  If the tables are joined based on city, state, or zip code, it will conflict with thousands of other locations in New York (you don’t want data on the Rockefeller Center corrupting your Empire State data).  Now, if the other entities/data sources cooperate and use a universally identifiable Placekey, there is no duplication and the data can be joined to result in one seamless piece of data with all variables in one row as seen below:

Table 2. Five sources of data joined to contain data in one row.

Multiply this across 90,000 pieces of data, and you can see how this becomes immensely valuable to analysts like Jack Fairfield and the team at MAG. The dataset is clean and saves man-hours and memory.

“Sometimes running spatial joins on large datasets can be time-consuming.  It can take eight hours for one project for address standardization and address verification.”

At the end of the day, Fairfield likes the structures of Placekey that uses a satisfying hexagonal grid that covers the world and is not strictly text-based.  He says, “I like the logical consistency of it. It’s not just a random grid but rather you can derive some meaning.” While MAG and Fairfield are currently in early stages of working with Placekey, the grand vision would be to attach it as a primary key to all point databases to include Maricopa County employers, residential housing, and building permits.

Recommended Case Studies

Maricopa Association of Governments

"Placekey resolves differences in two databases that a human might be able to understand, but a computer doesn’t."


"We can deliver something seamless and tied to a single key, while de-risking the privacy cost of the join itself. "

Johns Creek, GA

"The beauty of Placekey is that, once you have these keys appended to your data, you can link anything."