You know, just to cover all bases :)

[update: Aaron talks about a similar Flickr/Dopplr/FireEagle dance over here]

Tonight twitter released their next batch of API improvements, of course the one that caught my eye was …

“[NEW] /account/update_location.[xml|json] - sets the location for the
authenticated user to the string passed in a “location” parameter.
Nothing fancy, no geocoding or normalization. Just putting this out
there so developers can start playing with how geolocation might fit
into their Twitter applications.”

… which is nice as it’s just thrown in there as a ‘what if’ type of thing. There’s no direct reason for twitter to have location stuff, (well no more than Flickr I guess) but everyone knows that everyone wants it.

As it says there’s no geocoding etc. it’s basically a free text field to put stuff in that everyone’s agreed is for location. Say you wanted to tell other developers that you were in San Francisco when you twitted a tweet, you could use a URL like this … (don’t click this link unless you want to update your location to San Francisco!)

http://www.twitter.com/account/update_location.xml?location=san+francisco

(This will pop-up a username/password box, that’s twitter asking, not this website btw, you don’t have to enter your username and password, all that’s going to happen if you do though is it’ll set your location to ’san francisco’)

… the return looks something like this …

It’d be great if you didn’t have to update twitter yourself and there was something else out there that could do it for us.

Fire Eagle seems like a great place to start. For some absurd reason I can’t fathom, too busy probably, I’ve not written about Fire Eagle. I think it’s the most wonderful thing in the world, but that aside, it is, in short, a location broker. You get things to put your location in, and allow other things to get location out.

I tend to have Zone Tag running in the background on my N95, set to ping updates to fire eagle every few minutes (or until the battery dies). I hear that navison is also very good. Frankly, I want anything that knows where I am to be able to tell Fire Eagle, if it can’t do that, then what’s the point? I fully hope to have about three hardware devices and a couple of web applications (like Dopplr) sending updates to fire eagle by the end of the year.

Ok, so assuming Fire Eagle knows where I am, I can then authorize another application to query my location (to a level of granularity I specify). When that application asks where I am, it’ll get a response back something like this (example from here) …

<rsp stat="ok">
	<user token="abcdefghijkl">
		<location-hierarchy>
			<location best-guess="true">
				<id>114031</id>
				<georss:point>37.7812461853 -122.3957595825</georss:point>
				<level>0</level>
				<level-name>exact</level-name>
				<located-at>2008-03-03T10:58:55-08:00</located-at>
				<name>500 3rd St, San Francisco, CA</name>
			</location>
			<location best-guess="false">
				<id>114041</id>
				<georss:box>
				37.7494697571 -122.40650177 37.7862281799 -122.3790893555
				</georss:box>
				<level>1</level>
				<level-name>postal</level-name>
				<located-at>2008-03-03T10:58:55-08:00</located-at>
				<name>San Francisco, CA 94107</name>
				<place-id>8Xq01wWYA5u_OEMhyQ</place-id>
				<woeid>12797158</woeid>
			</location>
			<location best-guess="false">
				<id>114051</id>
				<georss:box>
				37.7037811279 -122.5154571533 37.8545417786 -122.32472229
				</georss:box>
				<level>3</level>
				<level-name>city</level-name>
				<located-at>2008-03-03T10:58:55-08:00</located-at>
				<name>San Francisco, CA</name>
				<place-id>kH8dLOubBZRvX_YZ</place-id>
				<woeid>2487956</woeid>
			</location>
			<location best-guess="false">
				<id>114061</id>
				<georss:box>
				32.5342788696 -124.4150238037 42.0093803406 -114.1308135986
				</georss:box>
				<level>5</level>
				<level-name>state</level-name>
				<located-at>2008-03-03T10:58:55-08:00</located-at>
				<name>California</name>
				<place-id>SVrAMtCbAphCLAtP</place-id>
				<woeid>2347563</woeid>
			</location>
			<location best-guess="false">
				<id>114071</id>
				<georss:box>
				18.9108390808 -167.2764129639 72.8960571289 -66.6879425049
				</georss:box>
				<level>6</level>
				<level-name>country</level-name>
				<located-at>2008-03-03T10:58:55-08:00</located-at>
				<name>United States</name>
				<place-id>4KO02SibApitvSBieQ</place-id>
				<woeid>23424977</woeid>
			</location>
		</location-hierarchy>
	</user>
</rsp>

For the moment, let’s say I’m sharing city level data with twitter, we’d be looking at this snippet here …

<location best-guess="false">
	<id>114051</id>
	<georss:box>
	37.7037811279 -122.5154571533 37.8545417786 -122.32472229
	</georss:box>
	<level>3</level>
	<level-name>city</level-name>
	<located-at>2008-03-03T10:58:55-08:00</located-at>
	<name>San Francisco, CA</name>
	<place-id>kH8dLOubBZRvX_YZ</place-id>
	<woeid>2487956</woeid>
</location>

… there are two useful location IDs you can use, place-id and woeid, woeid is probably the best one to use going into the future. In short it’s a unique identifier that Fire Eagle uses to pin a place to a record in the database (there are several San Franciscos around and they’re really hard to disambiguate without at some point going to a unique ID).

The main point is, if everyone can agree that 2487956 is San Francisco, CA, US, and I twittered from 2487956 five minutes ago and you twittered from 2487956 two minutes ago, then we are both …

1. In the same place
2. In San Francisco, CA, US

So how would this work? Well probably something like this …

You have a twitter app running on your PC, Mac, iphone or whatever, and your iphone just so happens to be running navizon which is updating your exact lat/long position to fire eagle. You then have a twitter application that you’ve authorized with fire eagle, allowing it to see which city you’re in. When you send a twitter the application first sends a request to fire eagle for your location. It extracts the woeid (or place-id) and before it sends the tweet to twitter calls twitter’s update location method …

http://www.twitter.com/account/update_location.xml?location=2487956

… then sends the tweet. Now other applications that display your tweets can also grab your location information from twitter at the same time and maybe put your tweet in a little more context. I know that I often use twitter to home in on people for meeting up.

Now there are a few problems with this …

1) Each tweet isn’t location-stamped, it’s only your own location that’s updated, looking back you wouldn’t get a historical view of where the tweets happened, so if you twittered something in Paris last week, and then went to San Francisco, the only location an application would have access to would be the San Francisco one. Unless you had something tracking that and recording it for you, i.e. something like twitterrific could save the tweets and locations at the time it received them locally, and allow the person viewing a history of your tweets to see them on a map, or whatever. I don’t think twitterrific currently does keep a history of tweets, but if it did, etc. etc. Hopefully in the future with another nudging we’ll be able to location-stamp the tweets with something like <located_at>.

2) Saving 2487956 into the location isn’t very user friendly, it doesn’t really mean anything to someone viewing your page on twitter, So far I’ve just been looking at this from a code point of view. A solution could be to store something like “san francisco woeid:2487956″ or “san francisco place_id:kH8dLOubBZRvX_YZ”. Then whatever is looking for your location can parse the location based on those patterns. The human just deals with “parsing” the san francisco bit of it.

3) Fire Eagle currently offers no way (as far as I know) to find out where 2487956 actually is. What’d be really handy is something where you can say, hey where on earth is 2487956.

But anyway, the short is that the new update_location method in the twitter API opens up some possibly fun options. Fire Eagle is a good way to handle getting the location, because ZoneTag that knows and cares nothing for Twitter, is constantly updating fire eagle anyway. And it’s relatively trivial to have something else asking for your location back from fire eagle and pushing that too twitter. Before fire eagle you’d have to beg the people behind something like ZoneTag to also update your twitter location, and then the next thing and the next. Now all they (or any other location type thing) needs to do is send updates to the one true fire eagle service and everyone else can tap into that.

I was going to write a proof of concept myself, probably involving something cheeky like having Google Reader point to a php page that was pretending to be an RSS feed (poor persons cron job), but actually did the request to fire eagle and update to twitter. But I decided just to write a blog post about it instead.

But wait! There’s more.

Now seems to be a great time to mention a handful of new Flickr API services. We have four new Places API methods (and have had for a while now), that you can find on the services/api page, under the Places heading.

• flickr.places.find
• flickr.places.findByLatLon
• flickr.places.resolvePlaceId
• flickr.places.resolvePlaceURL

flickr.places.resolvePlaceId most closely follows the above discussion. Even though it’s called resolvePlaceId, it’ll also handle woeids. So calling it with place_id=2487956 will get flickr to tell you where it thinks that location is. Plugging the values into the API explorer will get you something like this …

So if you parsed woeid:123456 from someone’s twitter profile xml throwing it at resolvePlaceId could get you back a friendly name.

It should be noted that Flickr has no intention of becoming an all purpose general geocoder and as such all these places api methods only work down to a city level. This api call is used mainly for when you want to be able to direct a user to the Places page for a given photos. For example using the flickr API explorer for flickr.photos.getInfo enter the photo ID “2434908810″ and select “Do not sign call?”, in the XML that you get back there’s a section for location …

<location latitude="37.783142" longitude="-122.40411" accuracy="16" place_id="kH8dLOubBZRvX_YZ" woeid="2487956">
	<locality place_id="kH8dLOubBZRvX_YZ" woeid="2487956">San Francisco</locality>
	<county place_id="hCca8XSYA5nn0X1Sfw" woeid="12587707">San Francisco</county>
	<region place_id="SVrAMtCbAphCLAtP" woeid="2347563">California</region>
	<country place_id="4KO02SibApitvSBieQ" woeid="23424977">United States</country>
</location>

You can now take the woeid for this picture, plug it into flickr.places.resolvePlaceId and you have the URL for the places page.

As an aside, once you know the woeid for a photo, you can call flickr.photos.search and pass in the woeid as a parameter to find other photos in the same location, which is also a new thing. Handy for finding photos in California (2347563) where a bounding box isn’t going to help you much.

flickr.places.resolvePlaceURL takes you back the other way. If you know the Places page URL, you can use this to get back the woeid and place_id. Or you can try hand crafting them, such as “/us/ca/sf”.

flickr.places.findByLatLon for flickr type stuff is used to get the woeid at a certain point (city level and above), once you have the woeid you then go on to use flickr.photos.search to find photos in that area.

In the context of updating your twitter location above without fire eagle, then you could pass your current lat/long to this method, get the woeid back out and update your location with that. Another application could then read your woeid back out of your location and using flickr.places.resolvePlaceId convert it back to a human readable format.

Round trip example …

Plug, lat/long 37.783,-122.404 into flickr.places.findByLatLon, gives you …

<rsp stat="ok">
	<places latitude="37.783" longitude="-122.404" accuracy="16" total="1">
		<place place_id="kH8dLOubBZRvX_YZ" woeid="2487956" place_url="/United+States/California/San+Francisco" place_type="locality"/>
	</places>
</rsp>

So now you have the woeid. You can either parse the place_url to get the human readable format, or push it back into flickr.places.resolvePlaceURL, doing that for “/United+States/California/San+Francisco” gives you back …

<rsp stat="ok">
	<location name="San Francisco" woeid="2487956" place_id="kH8dLOubBZRvX_YZ" place_url="/United+States/California/San+Francisco">
		<locality place_id="kH8dLOubBZRvX_YZ" woeid="2487956">San Francisco</locality>
		<county place_id="hCca8XSYA5nn0X1Sfw" woeid="12587707">San Francisco</county>
		<region place_id="SVrAMtCbAphCLAtP" woeid="2347563">California</region>
		<country place_id="4KO02SibApitvSBieQ" woeid="23424977">United States</country>
	</location>
</rsp>

Which gives you a little bit more to work with. Then you can throw that at twitter’s API …

http://www.twitter.com/account/update_location.xml?location=san+francisco+woeid:2487956

Other people can grab your location using the twitter API, parse out the woeid and throw it back into flickr.places.resolvePlaceId to get the human readable form. Of course as it also gives you the state, and country, you can find out that even if you’re not twittering in the same city, you may be in the same state or country. You could also probably work out which timezone they are in, to put some twitters into context.

Oh and you’ll probably want to watch your flickr API rate limit too (hint: local caching) before your key gets turned off.

So there we have it, a quick poke at one of twitters new API methods, a look at how fire eagle could easily be used to keep twitter updated with your current location, without having to go to all the trouble of updating twitter itself. And a quick run through of some of Flickr’s new API methods.

Hopefully if you add into the fray Upcoming.org that uses place_ids such as this http://upcoming.yahoo.com/place/kH8dLOubBZRvX_YZ (spotting that’s the place_id for San Francisco from all the examples above) you should be able to see how fire eagle can be really great for pulling all these things together.

If you use it to keep your twitter location updated, you can start to pull in events from upcoming that happened at that time, see if your contacts/friends were also at the same events, check out flickr photos for that location from your contacts for the timespan of the event. Or go the other way round and have it so that posting a flickr photo to an upcoming.org event, sets your location in fire eagle for twitter to poll for your location, and so on. And if other websites also use the same woeid for news events, and so on and so on, you can see how all these things can be pulled together and support one another.

Obviously its all a little geeky at the moment, but the idea is to make it all nicely seamful as someone might say.