[twitter-dev] Re: Geocoded searches broken

2010-11-28 Thread bob.hitching
seeing the same problem on http://geome.me, for example -

http://search.twitter.com/search.json?geocode=37.44452,-122.161304,7kmq=love

Response includes:
... warning:adjusted since_id to 9031872674339840 due to temporary
error ...

thanks to Randy for the workaround.

help us Twitter!

On Nov 28, 10:41 am, MikeUCUD michaelmcca...@gmail.com wrote:
 I'm having the same issue.  It worked again for a little while, but
 hasn't worked in a day or 2.

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk


[twitter-dev] Re: Force mobile OAUTH ui?

2010-05-29 Thread bob.hitching
you could use http://m.twitter.com/oauth/authorize?oauth_token=123abc
to force the mobile oAuth page, but with a couple of caveats -

twitter cookies will mean that if the browser session has previously
included some use of the standard (non-mobile) twitter site,
m.twitter.com
will also result in the standard (non-mobile) oAuth page.

also be careful because the mobile oAuth page is served (correctly)
as
Content-type: application/xhtml+xml which will not work on desktop IE!


On May 29, 4:38 am, GG gerber.g...@gmail.com wrote:
 Anyone know a way to get the mobile OAUTH ui from the desktop
 browser?  Looks like they detect the browser and then swap the style
 sheets as oppose to redirecting to mobile.twitter.com/oauth/authorize
 (which dosnt exist)

 Maybe there is an undocumented parameter we can use?  Something like:
  http://twitter.com/oauth/authorize?mobile=1oauth_token=123abc


[twitter-dev] Re: Mobile OAuth Summary

2010-04-30 Thread bob.hitching
Hi Raffi and everyone,

Firstly, Twitter is doing better than some other oAuth pages I could
mention..!

At Xumii we’re using Twitter mobile oAuth on a wide range of phones,
from low-end feature phones to high-end smartphones. A recent QA cycle
revealed 7 out of 30 Most Popular devices not coping with Twitter
mobile oAuth: Samsung C3110, Nokia 3120, SE G502, SE C905, LG KU990,
Nokia N96, SE W705.

But… rather than tracking individual defects on specific handsets, how
about a standards-based approach, using something like the w3 MobileOK
validator? http://validator.w3.org/mobile

Currently, Twitter mobile oAuth scores 68% when the user is already
logged in to Twitter, and 79% when the user isn't yet logged in.

@raffi i’ll email over the MobileOK reports which explain more; it’s
not just the Javascript, there are easily-fixed problems in the XHTML,
the CSS, the images, the DOCTYPE, and the HTTP headers.

Aiming for 100% on MobileOK should solve a big chunk of current issues
on those lower-end feature phones.

What do you think?

Cheers, Bob


On Apr 29, 9:07 pm, Raffi Krikorian ra...@twitter.com wrote:
 hi.

 i'll follow up on this - do you have a notion of what browsers, what phones,
 etc. your users are coming from

 On Thu, Apr 29, 2010 at 1:49 AM, twittme_mobi nlupa...@googlemail.comwrote:



  Hello,

  I migrated my mobile web site to OAuth.
  Now, I have a lot of users complaining that the OAuth page of twitter
  is not
  mobile friendly.Some of them are getting just a blank screen or just
  cannot open it.

  My honest question is - this is being discussed many times but where
  are we with this?
  Are all those users really suppose to get such a bad user experience?
  Why would you need a javascript
  on a login page?Is it so hard to create such page just for mobile
  browsers?

  Is anybody handling this - I mean it is an obvious problem that we
  have for more than a year already.

  Any comments on this are highly appreciated.

 --
 Raffi Krikorian
 Twitter Platform Teamhttp://twitter.com/raffi


[twitter-dev] How to: display approximately geo-located Tweets on a map

2010-04-20 Thread bob.hitching
Hey everyone, I wanted to share with the group this Javascript library
which might be useful for any apps dealing with the new Places
feature.

Many apps display Tweets as points on a map, based on exact latitude/
longitude coordinates. Easy.

However the new Places feature allows Tweets to be approximately geo-
located, within a ‘Place’ of chosen granularity, e.g. a city, or a
neighborhood.

This is great for users who have ‘geo-privacy’ concerns about
revealing an exact latitude/longitude. But this approach presents a
challenge to us developers: how can approximately-located Tweets be
displayed on a map?!

Moreover, we need to adopt a standard way of showing these
approximately-located Tweets, to help users form a consistent
understanding of the Places feature.

‘polytweet’ is my Javascript library which displays approximately-
located Tweets on a Google Map.

I hacked it together at Chirp last week, because I will need something
like this for GeoMeme (my app, see http://www.geome.me), and also to
share it with other developers and encourage a standard approach.

You can see the demo at http://bit.ly/polytweetdemo which includes an
added bonus demo of Hovercards On A Map. Screenshots and more details
on http://hitching.net

The Javascript library itself is at http://code.google.com/p/polytweet/

Let us know what you think.


-- 
Subscription settings: 
http://groups.google.com/group/twitter-development-talk/subscribe?hl=en


[twitter-dev] Re: Upcoming changes to the way status IDs are sequenced

2010-03-26 Thread bob.hitching
+1 on the need to maintain support for since_id in the Search API

On Mar 27, 7:41 am, Taylor Singletary taylorsinglet...@twitter.com
wrote:
 Hi Developers,

 It's no secret that Twitter is growing exponentially. The tweets keep coming
 with ever increasing velocity, thanks in large part to your great
 applications.

 Twitter has adapted to the increasing number of tweets in ways that have
 affected you in the past: We moved from 32 bit unsigned integers to 64-bit
 unsigned integers for status IDs some time ago. You all weathered that storm
 with ease. The tweetapoclypse was averted, and the tweets kept flowing.

 Now we're reaching the scalability limit of our current tweet ID generation
 scheme. Unlike the previous tweet ID migrations, the solution to the current
 issue is significantly different. However, in most cases the new approach we
 will take will not result in any noticeable differences to you the developer
 or your users.

 We are planning to replace our current sequential tweet ID generation
 routine with a simple, more scalable solution. IDs will still be 64-bit
 unsigned integers. However, this new solution is no longer guaranteed to
 generate sequential IDs.  Instead IDs will be derived based on time: the
 most significant bits being sourced from a timestamp and the least
 significant bits will be effectively random.

 Please don't depend on the exact format of the ID. As our infrastructure
 needs evolve, we might need to tweak the generation algorithm again.

 If you've been trying to divine meaning from status IDs aside from their
 role as a primary key, you won't be able to anymore. Likewise for usage of
 IDs in mathematical operations -- for instance, subtracting two status IDs
 to determine the number of tweets in between will no longer be possible.

 For the majority of applications we think this scheme switch will be a
 non-event. Before implementing these changes, we'd like to know if your
 applications currently depend on the sequential nature of IDs. Do you depend
 on the density of the tweet sequence being constant?  Are you trying to
 analyze the IDs as anything other than opaque, ordered identifiers? Aside
 for guaranteed sequential tweet ID ordering, what APIs can we provide you to
 accomplish your goals?

 Taylor Singletary
 Developer Advocate, Twitterhttp://twitter.com/episod

To unsubscribe from this group, send email to 
twitter-development-talk+unsubscribegooglegroups.com or reply to this email 
with the words REMOVE ME as the subject.


[twitter-dev] Re: Developer Preview: upcoming geo features (a.k.a A place is not just a latitude and a longitude - it has a name)

2010-03-26 Thread bob.hitching
good stuff raffi, any further news on if/when the new place data
will be exposed via the Search API?

cheers, bob

GeoMeme - http://www.geome.me - what's happening where?

On Mar 2, 12:44 pm, Raffi Krikorian ra...@twitter.com wrote:
 hi all.

 i wanted to give you all a heads up on some big changes we're making to our
 geo-tagging API.  right now, you can post a status update along with a
 latitude and longitude pair -- what we've jokingly referred to as
 geo-tweeting, is actually just a status update with a where in the form
 of a coordinate attached to it.  we're about to add a whole new layer of
 context to that status update.

 our goal is to provide a few more options to API developers (and the users
 they are servicing) through this contextual information.  people, we find,
 inherently want to talk about a place.  a place, for a lot of people, has
 a name and is not a latitude and longitude pair.  (37.78215, -122.40060),
 for example, doesn't mean a lot to a lot of people -- but, San Francisco,
 CA, USA does.  we're also trying to help users who aren't comfortable
 annotating their tweets with their exact coordinates, but, instead, are
 really happy to say what city, or even neighborhood, they are in.
  annotating your place with a name does that too.

 once our new additions to our geo infrastructure comes into place,
 geo-tweets will get richer data.  for example, a status object may look like
 the following (abbreviated):

 {
   id:9505317221,
   ...
   coordinates: {
     type:Point,
     coordinates: [-122.40060, 37.78215]
   },
   place: {
     country:United States,
     country_code:US,
     full_name:SoMa, San Francisco,
     name:SoMa,
     place_type:neighborhood,
     bounding_box: {
       type:Polygon,
       coordinates: [
         [
           [ -122.42284884, 37.76893497 ],
           [ -122.3964, 37.76893497 ],
           [ -122.3964, 37.78752897 ],
           [ -122.42284884, 37.78752897 ]
         ]
       ]
     },
     id:7695dd2ec2f86f2b,
     url:/1/geo/id/7695dd2ec2f86f2b.json
   },
   ...
   text:Wherever you go, there you are.

 }

 here you'll see a new place attribute that gives the contextual location of
 the geo-tweet itself.  in these cases, you'll have rich, and human-readable,
 information about where this tweet has come from -- in this case, SoMa, San
 Francisco.  the geo object, for the time being, is still there, so you don't
 have to worry about backwards compatibility. it will soon be deprecated,
 however and please plan for that.  we're also introducing a
 coordinatesobject which has the added bonus that, when in JSON, it is
 properly GeoJSON
 encoded with the longitude before latitude.

 to support this these changes we've added a few endpoints:

 https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-geo-revers...https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-geo-ID

 you can call geo/reverse_geocode with a latitude and longitude, and it will
 return an array of places that you can use to annotate your tweet with.
  each place that is returned will have a unique ID that you can use, as well
 as a displayable name, and even a geographical bounding box that you can use
 for display on a map.  if you want more details, then hit the
 geo/idendpoint where, if available, and if you're interested, you can
 retrieve a
 more detailed geometry for more accurate map drawing.  we've also updated
 the statuses/update documentation 
 (https://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0...)
 to indicate how to pass that place ID with your status update.

 for this first pass, we're only going live with United States-centric data,
 but that will quickly be expanded geographically as we work out the kinks in
 our system.  there are definitely some nuances that i'm missing in this
 e-mail, a few things are still in flux, but we're rapidly documenting this
 on our wiki, and we hope to be going live with it quite soon.  as always, if
 you have any questions, just find us at @twitterapi, or drop us an e-mail.

 --
 Raffi Krikorian
 Twitter Platform Teamhttp://twitter.com/raffi

To unsubscribe from this group, send email to 
twitter-development-talk+unsubscribegooglegroups.com or reply to this email 
with the words REMOVE ME as the subject.


[twitter-dev] Re: Developer Preview: Trends API

2009-11-10 Thread bob.hitching

hi raffi, this is great.
+1 on being about to query trends by lat, lng, radius (or using a
bounding box spatial query)

this might help what i am doing with GeoMeme - http://www.geome.me
which currently uses the Yahoo Term Extraction API to work out
trending topics at *any* lat / lng position.

keen to hear your thoughts on GeoMeme if you are willing / able.

keep up the geo!

cheers, bob

On Nov 10, 9:13 am, Raffi Krikorian ra...@twitter.com wrote:
 We've heard from lots of users that trending topics, as seen on the  
 twitter.com homepage and on search.twitter.com, are a fun way to  
 figure out what's going on in the Twitter-verse at this very instant.  
 The one feature request that we've heard over and over, however, is  
 what's going on where I am?.  To answer that, we wanted to give you  
 all a heads up regarding the new Trends API that we're launching.  
 This API will open up trending information that is specific to a  
 number of locations around the world.

 At a high level, there will be two new endpoints:

 * an endpoint to give a listing of all locations that trends are  
 available for, and
 * an endpoint to actually allow you to query by a specific location.

 We're using Yahoo!'s Where on Earth IDs (WOEIDs) to name each location  
 that we have information for -- we're doing so because those IDs give  
 not only language-agnostic, but also permanent, stable, and unique  
 identifiers for geographic locations.  For example, San Francisco has  
 a permanent and unique WOEID of 2487956, London has 44418, and the  
 Earth has WOEID 1.  You can find out more about those IDs 
 athttp://developer.yahoo.com/geo/geoplanet/
 .  The EXAMPLES section at the bottom of the documentation's landing  
 page shows an example of how to find out the WOEID of a specific place.

 To start reading through the documentation, check out:

 https://twitterapi.pbworks.com/Twitter-REST-API-Method%3A-trends-avai...https://twitterapi.pbworks.com/Twitter-REST-API-Method%3A-trends-loca...

 It should be noted that at launch, unlike the trends that are  
 available by the search API, these localized trends will not be rolled  
 up into daily and weekly trends.  Those rollups may come in a future  
 release.

 --
 Raffi Krikorian
 Twitter Platform Team
 ra...@twitter.com | @raffi


[twitter-dev] Re: Can the Twitter API call me?

2009-09-13 Thread bob.hitching

some events like 'new follower' generate an email message - you can
build a listener to react to those emails.  there's even some useful
twitter headers included so you don't have to parse the message body.

Bob


On Sep 12, 1:24 am, Duncan dun...@therecoveryplace.net wrote:
 Does Twitter have something in place where i can build a litener app
 that Twitter can HTTP/POST to when a new follower follows me or
 someone sends me a direct message, etc?

 Duncan


[twitter-dev] GeoMeme, search api /or rest api

2009-09-10 Thread bob.hitching

hello raffi and everyone,

a demo and a question;

GeoMeme is geo-app using the Location field to provide measurement and
comparison of real-time local twitter trends, e.g. see http://www.geome.me/51ARK
to compare New Yorkers tweeting about Snow Leopard vs. Windows 7.

when geolocation is available for individual tweets, that will allow
more tweets to be located accurately on the map.  for now, it may be
useful for others to see as an example geo-app.  i'd love to hear what
this group thinks about GeoMeme, either here or @geomeme

and my question to Raffi;

will the geo tags be contained in results from the public Search API
/or just the REST API?

cheers, bob