Articles

Recently an image on Twitter caught my attention. It was a snap of some handwritten meeting notes at a presentation by (I assume) Peter Speyer. In the corner the notetaker had scribbled a comment, “no more spreadsheets scrolls.” I read that, and thought to myself, “amen.”

Let’s say we need unique identifiers for map locations. Off hand, you might guess that a normal address makes for a perfect identifier. After all, with geocoding applications, we can easily translate an address to a place on the map. So it would seem like a perfect identifier. However, as I’m sure you have guessed by now, there are lots of use cases for which an address does not make a great identifier of a map location, at least from a database or data mart perspective, or even from an analytical perspective.

To protect customer privacy, organizations sometimes do not allow in their data marts elements that can be used to identify specific customers, elements such as addresses. This is particularly true if their customer base includes consumers (as opposed to businesses). I guess some employees are tempted to search through address records looking for names of famous people.

Search for 13145 Alpine Ridge RD in Cheyenne, Wyoming, 82009, in any on-line mapping site, like Google or Bing Maps. They will not locate it properly on a map. Google’s Geocoding API returns an accuracy level of ”geometric center.” Bing Maps returns a “PostCode1.” Pitney Bowes returns a “Z1,” which is short hand for a ZIP Code centroid. In other words, the exact location on the map of the address has not yet been digitally captured. Therefore, it is not yet possible to plot it – at least not by a machine.

James Fee, in his Spatially Adjusted blog, recently remarked about ESRI Shape Files, “So antiquated, so limiting, so dangerous….” True. True. Yet I could also add, “so everywhere.” Love them or hate them, Shapefiles are everywhere. Therefore, they are probably here to stay, at least until we all retire to some tropical paradise.

Submit Ireland’s famous “Blarney Stone” to Bing Maps’ and Google’s geocoding APIs and both will return its map coordinates, rather precisely too. Bing Maps geocodes it’s location to Latitude 51.929092, Longitude -8.570564; and Google to Longitude 51.929019, Latitude -8.570338. That’s a difference of about 14 meters. Neither is accurate enough to kiss it, but both do at least get you to the front door. Try that with a traditional enterprise geocoder and you’ll get nowhere.

This question is another one of those, “if I got a stamp for every time I heard” stories. From the Census Bureau, you cannot get ZIP Codes, at any price, free or otherwise. Instead, the Bureau makes available a geographic product called ZIP Code Tabulation Areas,” or ZCTATM for short.

This kind of outcome is quite possible. When working with spatial applications, it’s routine for me to “validate” and “geocode” addresses. People often use those terms interchangeably. Yet they are two distinct processes, which can sometimes yield contradictory results. Neither process can be said to be better than the other. It’s a matter of context.

Google a phrase like “how do I load spatial data into SQL Server?” and you will find lots of blog references to Shape2SQL. That is because it is a great piece of software. In fact, I have used it for years to populate spatial tables in Microsoft SQL Server. I suspect its popularity among bloggers is tied to its price, which is zero. Couple that with the wide availability of “free” (public domain) datasets of basic geographies like country and state/province boundaries in ESRI’s shapefile format — and you have the makings of a blog post on how to load a spatial table.

Well, not really. But the data certainly would suggest it has. The “data” in this case, is a spatial object with a unique characteristic. Yes, the spatial object happens to look like a dog. (As a matter of fact, I do plan to keep my day job!) But the spatial object also happens to have a hidden flaw.

Pages