If you want to give something like that a try, check out the trends/available endpoint, as that will let you know what WOEIDs we are exposing trending information for. What this all means is that our Trends API is now interoperable with anybody else who is building a system on top of WOEIDs - you could easily mash-up Flickr’s places with our Trend locations, for example. A program that wanted to get data about San Francisco, CA would first determine that it has a WOEID of 2487956, and with that query. Finally, there is a standard endpoint to query to get more information about a place. In addition, a WOEID has certain properties such as an implied hierarchy (a particular city is in a particular state, for example), and a taxonomy of categories (there is a “language” to categorize something as a “town” or a “suburb”). WOEIDs are 32-bit identifiers that are “unique and non-repetitive” - if a location is assigned a WOEID, the WOEID assigned is never changed, and that particular WOEID is never given to another location. Where we landed was on using Yahoo!’s Where On Earth IDs, or WOEIDs, as our representation. We needed a way to represent a place in a permanent and language-independent way - we didn’t want to be caught in using an identifier that may change over time, and we didn’t want to be caught in internationalization issues. How do you represent a “place”? That’s what we were wondering when we were putting together our API for Trends on Twitter.
0 Comments
Leave a Reply. |