LA Times finds LAPD Geocoding Error

About Directions

Special Announcement

Newsletter Sign Up

Calendar

Syndicate This Blog

RSS 0.91 feed

RSS 1.0 feed

RSS 2.0 feed

Top Referers

myteams.dot.ga.gov (85)
planetgs.com (75)
www.thegisforum.com (70)
www.spatialsciences.org.au (32)
www.bloglines.com (27)

Our Points

Sunday, April 5. 2009

LA Times finds LAPD Geocoding Error

The LA Times details how a geocoding error in an LAPD online crime mapping app puts a high crime rate just around the corner from City Hall and the Police station. In fact, the spike is the result of failed geocoding.

While the article highlights some key points about the process of geocoding and why the error was not found sooner (the app only shows data back a week, making such spikes less obvious) it missed out on some other points including:

- different apps use different geocoding algorithms
- different apps use different data against which to geocode
- sharing raw data (vs. maps) can help identify such errors

There also this great quote from Paul Zandbergen, a professor of geography at the University of New Mexico who studies the quality of online maps: "Most spatial data are inaccurate."

My main question is this: Everyblock took the same data feed for its LA maps, and it seems, ended up with same inaccuracies. Is that because they use the same geocoding and data against which to geocode? That's not clear from the article.

Hat tip to reader Duane for a pointer to the story.

Posted by Adena Schutzberg in Oops at 13:27 | Comments (15) | Trackbacks (0) |

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

It's not clear what the actual cause of the error was here. When I did some similar work for a UK police force they were shocked to find that the main police station was at the center of a crime hotspot. It turned out that if the officer writing the report didn't know the postalcode of the incidence (or it was somewhere with out a postcode) the program wouldn't let him proceed with out a postcode so they would enter the police station's post code (since that was one they knew).

#1 Ian Turton on 2009-04-05 14:48 (Reply)

The error was, most likely, on the part of the user (LAPD) or their contractor and not directly in the address matching algorithm and the address database used. Most address matching software allows the user to define such things as "what do I mean by an 'exact match'" and what is to be done when one is not found.

A common "can't make an exact match" default is to then utilize (in the U.S.) the nine digit ZIP if one is available and to provide the coordinates of its centroid as a substitute. If not the nine digit ZIP, then use the centroid of the five digit ZIP, if not that, then the centroid of the city, etc.

As with any other tool, it is a good idea to understand the tools limitations and capabilities before making use of it. If this is not done in the address geocoding area, some strange things can result. Paul Zandbergen is quite right about spatial data and to paraphrase, I believe, Woody Allen "spatial data is often incorrect and few users care".

#1.1 Duane Marble on 2009-04-05 22:16 (Reply)

The error was on part of the LAPD, but not for the reason stated above. The LAPD contracted their crime mapping appication to L I G H T R A Y -- an outfit specializing in glitzy websites for the stars. L I G H T R A Y in turn subcontracted the geocoding to somebody else.

This is like going to Pamela Anderson's plastic surgeon to treat your ulcer.

#1.1.1 Atanas Entchev (Link) on 2009-04-06 09:29 (Reply)

That "someone else," per the article was PSOMAS, not a newbie to geo. Perhaps they can further explain?

#1.1.1.1 Adena Schutzberg (Link) on 2009-04-06 10:22 (Reply)

The problem is mostly likely with the data or data collection processed used, not the tools or contractor used to GEO code. As always you need to validate the data quality before you can get an accurate view.

#1.2 David Blehm on 2009-04-06 15:03 (Reply)

The problem is with the overall process, not with the technology. The technology is not perfect, and any geo professional worth his/her salt should know that. So whoever was in charge of the overall process, of publishing an accurate crime map, is at fault. We don't know if it is the LAPD or the contractor, because we don't know what the contract says.

#1.2.1 Atanas Entchev (Link) on 2009-04-06 15:31 (Reply)

Ask the LAPD Chief of Police. Do they use the data internally? Do they use the same data at the intelligence fusion center?

#1.2.1.1 Randall Bocock on 2009-04-10 17:47 (Reply)

Perhaps a homeless criminals with no known address is assigned the address of the booking location?

#2 Archie Belaney on 2009-04-06 17:56 (Reply)

Hey y'all.

In hopes of answering some of the questions here, I've blogged the full transcript of my interview with Everyblock founder Adrian Holovaty. You can check it out here:

http://latimesblogs.latimes.com/lanow/2009/04/adrian-holovaty-everyblock.html

Thanks for your interest in our story. We appreciate thoughtful readers like you.

#3 Ben Welsh on 2009-04-06 18:00 (Reply)

Adena and All,

After receiving notification of the geocoding issues, Lightray immediately requested Psomas to review the LAPD crime address matching. We determined that the incorrect concentrations of crimes reported by the LA Times was due to an incorrect setting in the geocoding process that allowed zip code level and low score matches to be included in the maps. This problem has been corrected by not assigning those crimes a coordinate and not displaying them on the LAPD crime map website.

It is somewhat humorous that the Times asserts we moved the crimes off the West Africa coastline. The Times has access to crime data from LAPD through special arrangement. Apparently they did their own mapping of the crimes and included the unmatched crimes which had no coordinate values.

Users of the ePolicingTM solutions have not had the problem experienced by LAPD. The LAPD innovative crime maps program was developed by Lightray. Psomas joined Lightray to build upon the LAPD ePolicing program to form a commercial product: ePolicingTM, www.epolicing.com, to serve the police industry with affordable community policing solutions. Reengineering of the crime maps and backend solutions use ESRI based technology to bolster the open source geocoding and mapping tools used for LAPD crime maps. ESRI ArcGIS software provides detailed control and quality assurance for evaluating geocoding accuracy.

Placement of crimes on the map on LAPD and ePolicingTM crime maps is intended to be general so that the victim’s location is not pinpointed. Thus a precise geocoding using address reference files to increase coordinate accuracy is not required for this public view of crime locations. Street segment geocoding provides adequate georegerencing of the crime locations.

The LAPD innovation in public crime maps has served as an important and widely used tool for the department to communicate with their constituents as part of a broader community policing program. Presenting weblinks and phone numbers to the neighborhood divisions, LAPD encourages citizens to communicate with their neighborhood police officers. LAPD has also deployed a geographic based email program helping officers proactively communicate safety information with the public who subscribe to their service. LAPD should be applauded for making crime data readily available to citizens and enabling citizen dialog with local patrol officers.

#4 Craig Gooch (Link) on 2009-04-07 15:24 (Reply)

Craig,

Thanks so much for the update. I'm hoping this conversation will help everyone understand more about how geocoding works and where errors can be introduced.

Adena

#4.1 Adena Schutzberg (Link) on 2009-04-07 16:33 (Reply)

Unless it has changed in the past few days, the data provided by LAPD to LAT very clearly includes points with a latitude and longitude of zero. Here is an example record I have copied and pasted from a recent dump.

{"DR": "#091709115",
"Latitude": 0,
"Longitude": 0,
"streetAddress": "Topanga Cyn and Chatsworth",
"Crime": "Theft From Vehicle",
"Date": "03-29-2009 02:00:00 PM",
"Division": "Devonshire Division: 818-832-0609"},

That is an example record prior to any modification or manipulation by LAT.

Readers might also be interested to know that the same issue city hall still exists on a Lightray/Psomas developed site for the Savannah, GA, police department.

http://latimesblogs.latimes.com/lanow/2009/04/the-same-computer-glitches-that-the-times-exposed-in-the-lapds-crime-mapping-site----errors-which-created-a-virtual-crime-wa.html

#4.2 Ben Welsh on 2009-04-07 16:51 (Reply)

Zero, zero is a little over 330 NM due south of Accra, Ghana.

Anyone who's ever used a GPS knows that...;^).

#5 Archie Belaney on 2009-04-08 14:29 (Reply)

Adrian Holovaty details changes at EveryBlock related to geocoding on the EveryBlock blog: http://blog.everyblock.com/2009/apr/08/geocoding/

Bottom line: (1) EveryBlock wll geocode data and see if lat/lon provided by sources are within 375 meters of Everyblock's lat/lon per its own geocoding. If it is, it'll be mapped. if not, it won't be - but will be listed and there'll be an explanation as to why it's not mapped.

(2) Addresses that can't be geocoded will be included in the stats and noted as such.

Here's what did quite follow from start: LAPD offers BOTH the raw addresses of the crimes AND the results of its geocoding (lat/lon). EveryBlock had simply put the received lat/lons on the map, assuming they were accurately geocoded. (Holvaty notes most geocoded government data is pretty good.) Now, because they have access to both the raw addresses and the geocoded data, they can test it. And, they can do this with other data sets, so long as both datasets are available.

Lesson learned from this story thus far:

- data sources should provide raw data if at all possible (LAPD did, so kudos to them)

- don't blindly take geocoded data, it could be in error

- share errors when you find them - several orgs are changing processes because of the LA Times explorations

- explain as much to the public as you can about how the technology works (Holovaty's post offers a primer on geocoding before he explains the changes made in how EveryBlock provides the data. Very clear!)

- this is a great case study for journalists exploring GIS and for GIS professionals; it reminds us to get up close and personal with the data and to be sure we understand their processing

#6 Adena Schutzberg (Link) on 2009-04-09 07:19 (Reply)

Craig Gooch's comments are the most informed and intelligent statements I’ve ready about (and including) the article.

These types of glitches happen in the process of innovation.

Clearly, that leaves wannabe LA Times out – the best they can do is print mountains-out-of-mole-hills stories about true innovators' technology hiccups – typical armchair quarterbacks at best, stooping to any sub-level to get readers/future site visitors at worst.

Next time, at least do your homework.

#7 J Karwoski on 2009-04-09 15:10 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	Enclosing asterisks marks text as bold (word), underscore are made via _word_. Standard emoticons like :-) and ;-) are converted to images. E-Mail addresses will not be displayed and will only be used for E-Mail notifications To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above:
	Remember Information? Subscribe to this entry

Advertisers

Polls

What's your opinion of the quality of Google's "new" U.S. dataset?

	November '09
Mon	Tue	Wed	Thu	Fri	Sat	Sun
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30