Thanks for sharing your tips. I'll make sure this is all covered in the expanded documentation I'm working on!
On Thursday, June 17, 2010, tsmango <tsma...@gmail.com> wrote: > Just to answer my own question in case others were wondering, what I > found was that: > > If you use geo/reverse_geocode, you can specify the granularity as > either 'city' or 'neighborhood'. The default is 'neighborhood'. Places > are never returned. The documentation states that this endpoint "will > deliver generalized results about geography". > > If you use geo/search, you can specify the granularity as either > 'city', 'neighborhood' or 'poi' (not actually documented). The default > is 'neighborhood'. The documentation for this method states that this > is the preferred method for allowing users to select a place to attach > to their tweet. > > Anyhow, probably should have waited until the geo services were turned > back on the other day before posting my questions. Sorry for the > trouble and hope the granularity option of "poi" helps others. > > On Jun 15, 5:31 pm, tsmango <tsma...@gmail.com> wrote: >> I can't really test this right now because geo services are currently >> disabled, but does this mean that the geo/reverse_geocode and geo/ >> search api methods both return "places" in addition to neighborhoods >> and cities now? I understand they are all technically "places" but I >> mean business entities alongside neighborhoods and cities. Are they >> all mixed together now? If so, is there a way to get either business >> listings *or* geographic regions? >> >> I understand you guys now own GeoAPI so you're probably coming from a >> similar point of view and I realize that their entities are nested, as >> in a business is contained within some geographic region, yet both are >> considered entities. >> >> Anyhow, as you said, the documentation is kind of light for geo/search >> so I'm just a bit confused as to the data that's actually returned. >> Unfortunately, the application and service I work on has been using >> geo/reverse_geocode for a while now to attach cities (specifically >> cities) to tweets that run through our service and we've been planning >> to submit our app to Apple tomorrow. >> >> Thank you very much, in advance. >> >> On Jun 14, 7:43 pm, Taylor Singletary <taylorsinglet...@twitter.com> >> wrote: >> >> >> >> > Hi Developers, >> >> > Today we're launching some of the functionality around "Places" that we >> > announced at Chirp. You can read more about the feature >> > here:http://blog.twitter.com/2010/06/twitter-places-more-context-for-your.... >> >> > The launch comes with a batch of API enhancements, with a number of further >> > API additions just around the corner (like creating and updating places, >> > obviously a crucial component for many implementors). >> >> > The documentation in this area is a honestly a bit light at the moment, but >> > we'll be offering some more comprehensive documentation going over >> > suggested >> > use cases, flows, and more in the coming days. >> >> > What matters most for you: >> > - GET geo/nearby_places is now GET geo/search, with some added >> > functionality. This is a companion to GET geo/reverse_geocode, that's ideal >> > for using in conjunction with a place selection UI. >> > Read all about it at :http://bit.ly/dvNmYB >> > - A query parameter called "query" lets you do textual matching when >> > trying to find a place >> > - A query parameter called "ip" lets you do a lookup based on an IP >> > address >> > - You can fine tune results with granularity, accuracy, and the >> > contained_within parameter, which allows you to identify a place_id >> > (matching something like a city), and only search for places within that >> > place. >> >> > - <place> tags in XML output, "place" attribute in JSON output: >> >> > Tweets that have a place_id associated with them can now contain some >> > additional information not available in the past, including some attributes >> > that further describe the location. >> >> > Some common place/attributes you might start seeing: >> > - name >> > - street_address >> > - locality >> > - region >> > - phone >> > - postal_code >> > - twitter (a twitter account associated with the place) >> > - cross_streets >> >> > Attribute key names can be variant. These are just some of the attribute >> > keys you will see, with much more to come. >> >> > Here's a quick XML representation of a status with a place: >> > <status> >> > <created_at>Mon Jun 14 23:30:14 +0000 2010</created_at> >> > <id>16184038366</id> >> > <text>I'm testing out places integrations. Can you hear me Planet >> > Houston? I'm at the Epicenter. (psyche)</text> >> > <source>