You can file an issue, but this is very nearly fixed.  The update does
collision detection on the bounding box for a place.  This means that we may
overdeliver (you may get a tweet that isn't in the place, but is within its
bounding box).  If you want absolute collision detection with a place you
can run an additional check on the client.  We think this is a reasonable
balance between processing time consumed on our side and on the client side.


On Fri, Apr 2, 2010 at 8:06 PM, M. Edward (Ed) Borasky <>wrote:

> I've got a Streaming API collector going, collecting tweets from the
> Portland, Oregon area. For those wishing to do likewise, the bounding
> boxes are 'locations=-123.2,45.2,-122.2,45.75'. I noticed a few days ago
> that, even though I have Location turned on for my tweets, and they are
> getting tagged with my location, they weren't showing up in the
> Streaming collector.
> I think I see what's happening now. The tweets that are showing up in
> the collector have the "coordinates" attribute set with a "Point" type.
> I think most of them are getting set by Foursquare and not something in
> Twitter. My tweets, though tagged in Twitter with a "place" attribute,
> have a null "coordinates" attribute.
> I'm guessing I should file this as an issue. I would think, though it's
> obviously a bit more work, that a "locations" filter should include all
> tweets tagged with a place if that place is inside the bounding boxes.
> I have no strong opinions on the definition of "inside", though. Should
> it be any part of the place, all of the place, or the centroid of the
> place? Maybe a quick hack would be to stuff the centroid of the "place"
> into the "coordinates" attribute. ;-)
> --
> M. Edward (Ed) Borasky
> "A mathematician is a device for turning coffee into theorems." ~ Paul
> Erdős

Reply via email to