Standard format for locations/GPS data in twitter

[twibble]

There are more and more twitter applications using GPS data / location
information of some sort. This is great but unfortunately the format
being used differs among the applications: E.g. twitterrific on the
iPhone uses "iPhone: <lat>,<long>", twittervision and twibble use
"L:<lat>,<long>:" (cf. http://microformats.org/wiki/microblogging-nanoformats)
and some others are using geo hash tags like "#geo:<lat>,<long>" (cf.
http://www.ietf.org/rfc/rfc2426.txt). And there are even more geo
standards around.
To be able to share locations across applications and devices it would
be great to have a common format which should be uniquely used in the
twitter universe. I personally prefer the L: notation since it is the
shortest but don't mind that much. @twitter are there already
recommendations?

Best,
Thilo
http://twitter.com/twibble

[Evan Weaver]

We are planning to add the ability to store arbitrary key/value pairs
on tweets, in which case "lat":000 and "lng":000 would probably make
the most sense.

Until then I also like the L: notation.

Evan

--
Evan Weaver

[Jesse Stay]

I'm not a big fan of either because they all seem to detract from the theme of "what are you doing?" and clutter up Twitter.  I would instead prefer if there were some sort of "meta" protocol that apps like Twhirl, Twitterific, Twittervision, etc. could call to retrieve this data and display it to the user in their own format.  The "meta" protocol would be a way for applications (not users) to state not just "what are you doing", but "where are you doing", and "how are you doing it", and "why are you doing it".  It would also keep the base Twitter stream from being cluttered with non-status information while still allowing applications access to know more about that status.  It seems things like location should accompany a status, not be a separate status itself.  Just my $.02...

Jesse

[twibble]

this sounds like a really cool feature! It helps to keep tweets clean
from meta information which usually is not very human readable. In
addition to allow arbitray key/values it probably make sense to
"standardize" some of them. Eg.
"lng": "+9° 59' 31"
"lon": "+9.9922"
"long": "9.9922E"
all have the same meaning using a different syntax.

Thilo

On 12 Jul., 17:01, "Evan Weaver" <ewea...@twitter.com> wrote:
> We are planning to add the ability to store arbitrary key/value pairs
> on tweets, in which case "lat":000 and "lng":000 would probably make
> the most sense.
>
> Until then I also like the L: notation.
>
> Evan
>
>
>
> On Sat, Jul 12, 2008 at 10:18 AM, twibble <thilo.horstm...@gmail.com> wrote:
>
> > There are more and more twitter applications using GPS data / location
> > information of some sort. This is great but unfortunately the format
> > being used differs among the applications: E.g. twitterrific on the
> > iPhone uses "iPhone: <lat>,<long>", twittervision and twibble use

> > "L:<lat>,<long>:" (cf.http://microformats.org/wiki/microblogging-nanoformats)

[Jesse Stay]

I'm guessing this is similar to what I referred to - that would be nice.

Jesse

[Hans Engel]

I agree with the tweet 'metadata' idea - instead of cluttering tweets
with 'L:somewhere', there should be an API parameter for status updates
that accepts latitude, longitude, state, country, et cetera.

-Hans

[tweetip]

Foremost, our point of view comes from twitter stating they are
becoming a "global communication utility".

Let's suppose our desktop app has 10,000 installs. Each being mission
critical in scope to the end user.

The lack of planning by twitter and mobile client apps on Location
specs has forced failure at each of our installs. If an Event occurs
later today, we may not be able to easily determine where tweets are
coming from. Our system spits out garbage, reflecting badly on us and
twitter. Frustration expands.

If we have 1,000,000 installs each paying twitter a monthly service
fee - this frustration turns into a class action lawsuit. Twitter is
then a utility like any other we hate...

Solution? Stop focusing so much on the shiny. Seriously. Twitter's
potential is sooo much greater. So Twhirl, Twitterrific, Twinkle, and
all other mobile clients - smack down a spec here, attempt to form
consensus with other developers here, endorse it, and submit it to
twitter.

BTW twitterrific, you're the leader, so lead : 3x updates from iPhone
app http://tweetip.us/lkzoq

In the future, as new features become understood, the convo needs to
start sooner than one week before changes are pushed out.

hth

Michael :)
Moab

[Alex Payne]

If a community-proposed standard around per-status geolocation
emerges, we'll gladly adopt it where technically possible. Still lots
of nice standards-building work to be done here, and I'd much rather
have developers figure out what they need than have us ship our best
guess.

--
Alex Payne
http://twitter.com/al3x

[tweetip]

right forum? check. I was asked to clarify my comments on another
blog, and since no one
may ever see them I'll repost here. If twitter changes their minds
and
has no desire to become a highly reliable worldwide comm utility,
then
my comments are 100% invalid.
---
from a mission critical developer/end user point of view, and twitter
being a ---> worldwide comm utility <---
by not drafting an advanced specification, twitter failed to insure
the integrity of the data. Mobile app developers just started pumping
in whatever format/values they desired. This data "breaks" our app,
if
we are filtering values based on historical analysis as is the case
of
First Responder / Earthquake / Tornado / Emergency Services or for
that matter Market Movement / Breaking News / any realtime anything
where we feel Location is integral to our analysis.
---
Michael

[tweetip]

pkedrosky: @mdufort my location isn't being intentionally transmitted

source: twitterrific

problem: we'd love to see others debate this

[Sean P.]

As developer of Twobile, I propose a simple fix (in XML, but similar
for JSON):

in the <location>...</location> tag, why not add an attribute called
"type" which has the following 3 values: "geo", "loc", and "other". A
type attribute value of "geo" would correspond to absolute GPS
latitude/longitude coordinates (we can even have them as child
elements so it appears like <location type="geo"><lat>...</
lat><long>...</long></location>). A type attribute value of "loc"
would correspond to city, state/provence, country, etc. A type
attribute value of "other" would take the location just as it stands
now (since some people have things like "the middle of nowhere" as
their location).

I've been considering adding geo-location features to Twobile for the
last few weeks, but this too has been a problem that I've been trying
to work around, and I think a standard like this would work nicely for
nearly all cases.

Sean Payne
Infinitum Software
www.infinitumsoftware.com

> > apphttp://tweetip.us/lkzoq

[Jesse Stay]

I suggest keeping it simple, and open, similar to how Twitter is.  Attach a meta spec to each post, which developers can send a hash of any data they want about that individual.  Some suggestions could be set (I suggest as a community we set a wiki for this stuff), but I think Twitter's openness is what makes it powerful.  Something like the following (in JSON):

{'meta':
  [
    {'coords':'12345x12345'},
    {'temp':'45'},
    {'shirt color':'red'},
    {'what he ate for lunch before the post':'pad thai'},
  ]
}

The idea being, anything could be between the <meta/> tag - it would be completely up to the developers to decide.  Then, once this protocol is in place by Twitter, we, as developers could unite and provide our own suggested spec and standard on a wiki somewhere for other developers to follow on how recommended hash tags should be followed.  Thoughts?

Jesse