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>

Reply via email to