Nanoformats for location sharing

[Jesse Boyes]

Hey,

We launched a feature on Outalot last week that lets you send the place you're headed to Twitter.  You pick the details of the place you're going to and click 'Check in via Twitter'.  It looks something like this:

http://twitter.com/jexe/statuses/836415399

But I'm interested in doing a little more with it, like actually including location information on the twitter post itself.  This seems like a job for geohash, or at least a good opportunity to start trying it out.  Or we could use the L:[location] format that is already in use here and there.

Any opinions?  Is anyone else struggling with the same thing?  And, if we start putting a geohash on our tweets, will some system out there recognize them?  Or does it just junk up the message too much to bother with at all?

Any ideas are most welcome.

jx

--
 Jesse Boyes / Outalot
 Location Based Discovery: http://www.outalot.com

[Andrew Turner @ mapufacture]

On Thu, Jun 19, 2008 at 5:03 PM, Jesse Boyes <je...@seedwireless.com> wrote:
> Hey,
>
> We launched a feature on Outalot last week that lets you send the place
> you're headed to Twitter. You pick the details of the place you're going to
> and click 'Check in via Twitter'. It looks something like this:
>
> http://twitter.com/jexe/statuses/836415399
>
> But I'm interested in doing a little more with it, like actually including
> location information on the twitter post itself. This seems like a job for
> geohash, or at least a good opportunity to start trying it out. Or we could
> use the L:[location] format that is already in use here and there.

There was the beginning of agreement on this on the Microformats wiki
(though as picoformats)

http://microformats.org/wiki/picoformats

Essentially what should be done is fleshing out the Microformats page
on all the existing methods, both for publishing and consuming.

L: is perhaps the most popular due to a number of clients using it
thanks to Dave's own TwitterVision giving a compelling reason for it.
And not other tools pick up on it.

A big problem with it is that it doesn't allow for marking out the
specific location text. In your own example, how would it look:

Headed to L:Fashion 40 with Reuters. http://outalot.com/t/f2n

but is that location "Fashion 40 with Reuters" or just "Fashion", or
what? And remember that twitters and such won't just be in English, so
inferring from Grammar will be difficult.

>
> Any opinions? Is anyone else struggling with the same thing? And, if we
> start putting a geohash on our tweets, will some system out there recognize
> them? Or does it just junk up the message too much to bother with at all?

GeoHashes are useful for machine-markup, but useless for Humans. I
personally won't be twittering in my location in GeoHash format, and
any user that just "sees" it won't recognize it as nearby their
location (e.g. oh, I see you're in dqcjr20fc7jz!)

>
> Any ideas are most welcome.

Gather info, document it, then we can discuss specifics. :)

>
> jx
>
>
> --
> Jesse Boyes / Outalot
> Location Based Discovery: http://www.outalot.com
> >
>

--
Andrew Turner
mobile: 248.982.3609
and...@mapufacture.com
http://highearthorbit.com

http://mapufacture.com Helping build the Geospatial Web
Introduction to Neogeography - http://oreilly.com/catalog/neogeography

[Jesse Boyes]

There's a little more discussion about this here:

http://microformats.org/wiki/microblogging-nanoformats

Taking a step back, the broader goal is to make our messages more machine-friendly, so we can derive some more meaning/interconnectedness from the message.  That could mean this type of nano (or pico?) formatting, or could be something else entirely -- like expecting a location-aware bot to follow the link and look for location meta tags.  Incidentally, that would conceal a lot of the complexity and potentially be more useful for the general case, but it would mean that a location-based tweet has to have some add'l hosting somewhere.

As for the L: clause, a venue name won't be of much use at all usually.  Trying to decode L:Starbucks isn't likely to yield much success. ;) I was thinking of autogenerating something more specific, like:

"Headed to Starbucks. L:40.6885,-73.9929 http://outalot.com/t/pcd"

or

"Headed to Starbucks. L:dr5rkr058 http://outalot.com/t/pcd"

or 

"Headed to Starbucks: L:167 Court St, Brooklyn NY 11201 http://outalot.com/t/pcd"

Anyway, it ends up being a lot of code at the end of a message, and like you said -- not much of it is very interesting to a human (aside from the address, which could be verbose, ambiguous, and/or hard to parse).  But that might just be the cost of a text-only datatype for systems like Twitter.

Jesse

[David Troy]

For what it's worth, the "official" L: specification allows for an
optional terminating colon. So you could have "Headed to Starbucks. L:
40.6885,-73.9929: http://outalot.com/t/pcd". This is not a great
solution but it was a way to deal with the "trailing garbage" problem.

Additionally, it's been mentioned that L: is a bit hard on some folks
using T9 typing schemes -- : is a pain to get to.

Anyway, L: has made its way into all sorts of places. I'd be very
open to finding ways to make it more usable in both human and machine
contexts.

Also, in Twittervision there is the notion of personal locations. So
you can define L:starbucks=40.6885,-73.9929 and then, L:starbucks will
be recognized by the parser.

This tends to avoid the trailing garbage problem since the personal
locations are defined as single words, and we look for the single word
after an L: to see if it is a defined personal location.

My own feeling is that L: for human use was a good stopgap for the
days before widely available phone gps, but now that that is starting
to change. I agree that Geohash is pretty useless for humans to
communicate location to one another directly, but L:dr5rkr058 makes
some sense as it could be easily machine interpreted and it's highly
compact.

Also I think using geohash for proximity search makes a ton of sense,
especially in lightweight non-spatial indexing environments. For
instance, SQLite on iPhone.

OK, I am going back underground to do more iPhone coding. :)

Dave