I had an idea for making open geographic tags over the weekend so I hacked out a quick proof of concept in JavaScript. If you hate reading, you can skip to my demo here and play with it now.
You may have read the recent noise about URL shortening services being “the herpes of the web“. Please. I think this comes down to tagging being a closed system, but it’s not easy to fix and I doubt these kinds of things will ever go away.
It got me thinking, though: links to geographic information could benefit from shortening, and selectively loosing information could even be an advantage. Latitude and longitude is expressed as a pair of numbers, traditionally divided up by degrees, minutes, and seconds, but digitally expressed as floating numbers between -90/90 and -180/180 respectively. For example, a beach near my home is at 33.54240,-117.78559. For example, say I wanted to tell my friends that I’m at the beach, and my Twitter client could access my GPS and append my location to the message (yes I know about Twinkle). That’s 19 characters out of 140 and it’s very public. Also it’s a single point, not a whole area, and how do I search for other people near me?
My idea is to create a new kind of geographic code that specifies areas, not points, and is constructed in a text-search friendly way. Here’s how it works. First divide the world into a grid of 36 x 36, or 1,296 squares. Assign each row a number or letter using 0-9 and A-Z, that’s why 36. If we specify one of these grids by coordinates, such as “o6″ for example, that would specify a rather large part of the earth, as you can see below. If we were then to reference a point using a further 36 x 36 subdivision of this grid, we could specify an area even further, such as “o6p7″, which would be smaller still, and so on and so forth, all the way down to “o6p7iy6z”, the rough equivalent of the 19-character coordinates above in only 8 characters.
The more specific you want to be about your location, the more subdivisions your code would include, although using base 36, four levels is about the size of a house, three levels is a few blocks, two levels is about an hour’s drive, and one level is a day’s drive. That sizing feels right to me, but perhaps if this ever gets used people will standardize on different subdivisions, such as base 16 or base 24. Anyway, if you’re sharing your location but want to protect your privacy, leaving your location general and loosing a little specificity is a good thing. The subdivisions function like decimal places in that case. “o6″ means somewhere in SoCal, while “o6p7iy6z” means a certain spot by the volleyball nets on Main Beach in Laguna Beach, California.
When looking for proximity, you can see at a glance if a code is near you. In my case, I wouldn’t bother with things that don’t start with “o6p7″, although I might look at “06p8″ or “o6q7″, which are adjacent. A text search engine could find nearby items tags a wildcard search pattern (“06p7*”).
One other major benefit of a protocol like this is that it would be open. It’s not perfect; you may live close to the boundary of a big grid, and there’s an up-front hassle in figuring out exactly what grid you’re presently in unless your device can calculate your geo tag for you. Once in place, no single company would be the gatekeeper for the information that makes the tags meaningful, as in the case of URL shorteners. A unified location tag protocol could open up many interesting mashups between location aware devices and services, not just Twitter et al.
If someone’s already done something like this, then I wasn’t able to find it and I apologize, please let me know. If you want to fix it up and build upon this idea, by all means go for it but please link back here. Please view the source of the HTML demo file for implementation details and send any errors or suggestions. I think it’s not a perfect square because of the distortion from the map projection, but I could have flubbed something too.
