.:MattTopper.com:.

Analysis of Geocoder.us vs Free Navteq Data for San Francisco Starbucks

As promised (I know a couple days late, but I had a brainfart on some of the non-codable data) here is the analysis of the Geocoder.us data vs. the Free San Francisco data from Navteq. The data I used to prove this was 75 records for the Starbucks with a San Francisco address.

The first thing to discuss is the extra time it took for the Geocoder.us data. When I geocoded the data against the Navteq data that was loaded inside of the Oracle database it took me approximately 1:15 seconds to geocode the 75 records on my laptop. The same data through the Geocoder.us csv webservice took almost 10x as long, it was ~10 minutes to took to code the same 75 rows. OK, definitely a major hit there, the latency was due to the UTL_HTTP call I was making out of the database was taking 12 seconds per record to return. The Geocoder.us website discusses how to setup your own local Geocoder.us server, maybe in the future I will see what the difference in time is using their interface locally.

On a good note, there were 3 addresses that the Navteq data would not recognize, but the Geocoder.us data recognized all but one row. The one row that it did not recognize had 'ONE' for the street number instead of the actual number 1. When replacing the number for the string in the data, the site was successfully coded. Simple enough to fix, but still a limitation.

OK, now onto the data. The Navteq data was coded down to 12 decimal places, while the Geocoder.us data only gets coded down to 5 decimal places. This might not seem like a big deal, but take this into account.

So basically we are talking a difference in less than inches. While this might not be a big deal for the address is off by 4" (I think we'll be able to find it) but if it was a missle defense system, we may have some issues that need to be discussed. Since normal GPS devices are only accurate to about 15 feet on the best days this pretty darn good for free.

The first problem we run into is that the Geocoder data from Navteq is in SRID 8307 format, aka Longitude/Latitude (WGS 84) and the Geocoder.us data is in SRID 8265 format aka Longitude / Latitude (NAD83). So for most people this means nothing, but its actually very important. Remember back in elementary / middle school where they showed all the different maps of the world; one where greenland was really big, one where there were rips in the map, etc. Well this all comes back to us when we are talking about Coordinate Systems in Oracle Spatial. All the different types of map projections; coordinate, catesian, geodetic, projected, geodetic datum, and authalic sphere are all present in the Oracle Spatial database predefined for our use. These projections follow the defined standard projections defined by the OpenGIS consortium ( http://www.opengeospatial.org/specs/?page=specs ).

Very simply I wrote a quick SQL statement that uses the built in SDO_CS package to transform the data from 8265 to 8307 and then calculates the distance between the two points in meters.
select /*+ordered*/
o.store_name
, o.location navteq_location
, g.location geocoder_location
, sdo_geom.sdo_distance ( o.location, sdo_cs.transform(g.location, 8307), .005, 'unit=METER') distance
from sf_starbacks o,
sf_starbucks_geocoder_us g
where g.store_name=o.store_name
order by distance;

Below is the results table that was returned from the function.

Out of the 75 Starbuck stores in the table, 3 could not be compared because one of the two distances did not have a geocoded value for the address. The minimum distance difference was 2.71 meters and the maximum was 182.47 meters. The average distance difference was 19.44 meters. So on average the difference is alright, 20 meters average is fine if your trying to find a stores location on the street, but to do anything that requires more precision than driving directions you'd probably want to be assured that your data was more accurate. Even in the worst case it is only off by a tenth of a mile. Which data is more correct? Within the industry its typically accepted to be the Navteq data. Navteq spends many dollars a year to validate their data and make sure its the most accurate around.

The Yahoo uses both Navteq and TeleAtlas data for their geocoder. Maybe I should run some analysis against their service to see what comes out...anyone interested?