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?
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.
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) > 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?
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...
On Sat, Jul 12, 2008 at 8: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) > 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?
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)
> > 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?
On Sat, Jul 12, 2008 at 9:01 AM, 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) > > 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?
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.
Jesse Stay wrote: > I'm guessing this is similar to what I referred to - that would be nice.
> Jesse
> On Sat, Jul 12, 2008 at 9:01 AM, Evan Weaver <ewea...@twitter.com > <mailto: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 > <mailto: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) > > 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?
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.
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.
On Sat, Jul 12, 2008 at 12:54 PM, tweetip <twee...@mac.com> wrote:
> 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.
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
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.
> 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.
> On Sat, Jul 12, 2008 at 12:54 PM, tweetip <twee...@mac.com> wrote:
> > 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
> > apphttp://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.
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?
On Wed, Jul 16, 2008 at 12:18 PM, Sean P. <seantpa...@gmail.com> wrote:
> 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.
> On Jul 12, 1:36 pm, "Alex Payne" <a...@twitter.com> wrote: > > 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.
> > On Sat, Jul 12, 2008 at 12:54 PM, tweetip <twee...@mac.com> wrote:
> > > 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 > > > apphttp://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.
