Biz Stone from Twitter has announced that the service will soon get a new feature in its API: the capability to optionally put geolocation data into tweets.
Currently, geo-focused apps like Foursquare must hack location data into updates by linking them to Web pages. Once Twitter lets developers embed geo into tweets themselves, a new and interesting world for developers will likely open up.
As Stone says in his post, "For example, with accurate, tweet-level location data you could switch from reading the tweets of accounts you follow to reading tweets from anyone in your neighborhood or city--whether you follow them or not. It's easy to imagine how this might be interesting at an event like a concert or even something more dramatic like an earthquake."
By having the geodata available only to developers, though, and not via the general Twitter.com user interface, the company may also shift the economics of Twitter a bit. If geodata in tweets can only be written and read by apps and third-party Web services, those services will become even more valuable, possibly kicking off yet another round of Twitter client battles. Which I'm in favor of.
Another change this move may presage is an expansion of information that Twitter stores with tweets. Obvious items that developers could go to town with in an expanded Twitter API include conversational and retweet data (which), and of course embedded URLs. Twitter could, arguably, let developers put links directly into Tweets without relying on fragile third-party URL shorteners.
This move also may show that Twitter is willing to let its SMS roots go by the wayside. If a user reads a geocoded tweet in a text message, they will only get part of the message (the text, without the geodata). If Twitter is finally able to shed the SMS encumbrance, what might happen to the core of Twitter itself, the 140-character text limit, which itself is based on the limits of text messaging?