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.
---Mark http://twitter.com/mccv On Fri, Apr 2, 2010 at 8:06 PM, M. Edward (Ed) Borasky <[email protected]>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 > borasky-research.net/m-edward-ed-borasky > > "A mathematician is a device for turning coffee into theorems." ~ Paul > Erdős >
