<?xml version="1.0" encoding="UTF-8"?>
<created_at>Tue Apr 07 22:52:51 +0000 2009</created_at>
Thanks for the email, answers inline below...
On Thu, Aug 20, 2009 at 2:11 PM, @epc<epcos...@gmail.com> wrote:
> Will twitter validate the coordinates (ie, what will the API do when I
> pass lat=777&long=-666)?
> If the coordinates are invalid, will the status get posted or will the
> entire request get rejected with a 4xx code?
status will get posted and invalid data will get dropped
> If a user has not enabled geolocating (<geo_enabled>false</
> geo_enabled>), what happens if I pass in coordinates for that user?
> Silently ignored?
correct, if geo is not enabled we will silently ignore the lat and long data
> Geo data will be attached to individual tweets and not users, right?
> This will have no effect on the <location> field in a user profile?
correct, the tweet-level geotagging is separate from profile-level location
> -ed costello
Users will need to come to the website to change the setting. If we
provided an API, a misbehaving application would change the setting
without the user knowing - hence the read-only attribute.
Thanks for the email and glad you picked up on GeoRSS. We don't have
any plans for this release to support georss:radius. We picked the
standard because we like the flexibility and the types of geospatial
data it can describe.
The W3C Geolocation API is close to my heart. I started the initiative
many years ago with a site called locationaware.org that ended up
being one of the forming specs for the W3C standard. We'll be using it
on m.twitter.com for launch.
As for altitude, its something we may consider in the future, but it's
a very GPS-centric attribute as alternative positioning methods like
Wifi or cellular positioning can't determine altitude.
Ah, sorry -- looks like the bolding syntax messed it up. There should
be no asterisks in the API.
If any are here, I'd like to work with a team or group that actually
acts and defines the level such as diffusion, scoring, tracking paths,
distance, etc etc
cell 917 512 6281
On Aug 21, 2009, at 4:54 AM, Sean dCallahan <seanca...@gmail.com>
The location field on the user's profile will be stating put!
On Aug 21, 2009, at 1:54 AM, Sean Callahan <seanca...@gmail.com>
Anyway just throwing in here... Scaryish topic (one I play with).
What if you are celebrity + hit threat and your loc coordinates are
available no matter what (oh yeah uuuuggnkbghk!!! :)?) ---- what do
you do then? Anyway I won't post generic discussion further in this
list ---- I just started using or actually, I mean, SENDING to any
lustserv (this and cake) If I am wrong on etiquette, I apologize ---
will ttyl. :)
I'm working on a few Twitter rhings myself. I own StockAPI.com. I
imagine it might play and offer with others ;-)!!!
917 512 6281
On Aug 21, 2009, at 10:36 AM, Mike Champion <mike.c...@gmail.com>
Even so, though, I don't think that would fully get around the malicious
application problem unless you could say *which* apps got to turn it on and
off, and even then ...
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- /etc/motd: /earth is 98% full. please delete anyone you can. ---------------
We hope that user.location goes back to being more static and
descriptive to where you are typically "based". In my case it will be
"SOMA, San Francisco, CA". It will provide us additional context and
be more informative to someone viewing your profile than "iPhone
Nothing will really change about the way it works, but we expect the
behavior to change a bit.
Currently we geocode your user.location data to get an idea of where
you are. That gets attached to each tweet as it comes in, but its not
usually a representation of where you were when you actually sent the
tweet. The new functionality will allow you to geotag the actual
update without modifying the user.location field.
When it comes to search, we'll use both and give priority to the
Yup - we've started updating the docs.
Generally, there will always be a <geo> in the <status> (it may just
be empty, however, if there is no geolocated information attached),
and there will always be a <geo_enabled> on every <user> which is a
boolean representing whether the user has enabled geolocation on his
or her account.