Quoting David Helder <da...@twitter.com>:
The geo field is the user's (or tweet's) exact location. The place
field, whether a POI, neighborhood, city, or admin, contains the
place's location. Today POIs are always points, but in the future
there may be some polygons (e.g. stadiums, malls, amusement parks).
In this case the exact location would matter.
A place-annotated tweet will show up in the streaming API, even if
it doesn't have an exact location.
Twitter Geo Team
The POI data I've collected show that they are coded as four-sided
polygons even if they are points, with all four "corners" of the
polygon being equal to the "point". And sometimes the "geo" field is
present and sometimes it isn't. And sometimes the "coordinates" field
is present and sometimes it isn't. IIRC the geo and coordinates field
have latitude first and longitude second, but it's the other way
around for the "corners" of polygons!
Can we get this stuff documented so I'm not writing code that matches
things that will change? And so I can file bugs when something doesn't
work, like searching for places? Conversely, is there value in an open
source library that monitors the "sample" streaming API and announces
to the world when Twitter starts sending something new or starts
sending stuff in a new format? ;-)
I've been in the "industry" a long time - normally Twitter's pretty
good about announcing major changes, but "little stuff" like geo data
formats tends to just get changed without documentation and sometimes
without even warnings. In the case of User Streams, we *know* it's a
developer preview and subject to change. But something like places is
a *released* feature, and I think that kind of thing should happen
*with* documentation on or preferably *before* release.