My question is if there will be any plans for a whitelist of apps to
allow for persistent geo information?
I post travel tweets and would love to post them with the geo info of
the location, not necessarily where I'm at. In this case persistence
would be beneficial for people who search and find past tweets of
Travel Off The Cuff
On Sep 29, 4:25 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> ah, yes - most certainly. �...@rsarver will be putting together a list of
> "best practices" around geo, but, most certainly, you could just store
> this locally.
> > Right, and I see where Twitter's coming from. I'm speaking more to
> > API consumers that wish to persist the API/Geocode data on their own
> > systems.
> > its not a matter of caching the tweets, per se - its a matter of
> > storing extremely sensitive information for the long haul. we intend
> > to provide this information on a long-lived-basis at some point, but
> > until we have better privacy mechanisms in place, we are not going
> > to be storing this information at all after the hard expiration date.
> >> I assume you're caching the tweets in a local DB or something in
> >> order to provide histories of > 3200 tweets. For now, can't you
> >> also just cache the geocode info?
> >> As an alternative to a hard coded 7 days for the interval to the
> >> removal of geocoding information from a tweet, I suggest that an
> >> optional "expires" parameter be added to the statuses/update method.
> >> The value of this parameter would give the number of days between the
> >> tweet creation and when the geocoding would be removed from the
> >> tweet.
> >> The default value of the parameter, i.e., the value used if the
> >> parameter is not present in a statuses/update request, would be 7, in
> >> conformance with current policy.
> >> An explicit value of 0 would indicate that the geocoding information
> >> is never to be removed (But see below.).
> >> You may also want to consider a new method that removes the geocoding
> >> information from an existing tweet, even if the interval was
> >> specified
> >> as 0. Obviously, irreversible, like deleting a tweet, and could only
> >> be done by the creator of the tweet, like the statuses/destroy
> >> method.
> >> Comments expected and welcome.
> >> Jim Renkel
> >> On Sep 29, 12:42 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> >> > > I just noticed this in the API wiki, under the statuses/update
> >> method:
> >> > > "Currently, all geolocated information will be removed after
> >> seven
> >> > > days."
> >> > > Two questions:
> >> > > 1. What exactly will be removed: the geocoding attached to the
> >> tweet?
> >> > > Or the whole tweet?
> >> > the geocoding attached to the tweet.
> >> > > 2. Why? I.e., why remove the geocoding or the whole tweet? I
> >> can think
> >> > > of many use cases where it is important for the geocoding to
> >> remain as
> >> > > long as the tweet remains. For example, I take a great vacation
> >> > > picture, upload it to Twitpic, then tweet about it, including
> >> where I
> >> > > took it. The location where I took the picture remains the same
> >> > > forever. Why delete the geocoding information from the tweet,
> >> or the
> >> > > whole tweet. This will just cause folk to put the geocoding
> >> > > information in the text of the tweet, taking up valuable space
> >> and
> >> > > reducing the value of geocoding tweets, and cause developers
> >> (Like me,
> >> > > admittedly) to develop applications that put the geocoding in
> >> the text
> >> > > of the tweet. With applications like that available, twitter
> >> users are
> >> > > less likely to go to the botther of opting-in to twitter
> >> geocoding of
> >> > > their tweets.
> >> > this is being done for privacy issues, and in the future data
> >> will be
> >> > kept for longer once more sophisticated privacy controls are put
> >> into
> >> > place.
> Raffi Krikorian
> Twitter Platform Team
> ra...@twitter.com | @raffi