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.

David
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.



Reply via email to