First, congrats foursquare team! I'm sure this opens the floodgates in almost every respect for you guys. It's gonna be a big year.
Second, any big API changes coming down the pipe due to this? It seems deprecating city id is due to this change. Anything else we should be wary of... or even look forward to?
I've seen naveen write that cityid calls should be replaced by geolat + geolong.
and I echo the congrats!
On Tue, Jan 5, 2010 at 1:56 PM, dp <bigonthepig...@gmail.com> wrote: > First, congrats foursquare team! I'm sure this opens the floodgates > in almost every respect for you guys. It's gonna be a big year.
> Second, any big API changes coming down the pipe due to this? It > seems deprecating city id is due to this change. Anything else we > should be wary of... or even look forward to?
> -- > To post to this group, send email to foursquare-api@googlegroups.com
> I've seen naveen write that cityid calls should be replaced by geolat + geolong.
> and I echo the congrats!
> On Tue, Jan 5, 2010 at 1:56 PM, dp <bigonthepig...@gmail.com> wrote: > > First, congrats foursquare team! I'm sure this opens the floodgates > > in almost every respect for you guys. It's gonna be a big year.
> > Second, any big API changes coming down the pipe due to this? It > > seems deprecating city id is due to this change. Anything else we > > should be wary of... or even look forward to?
> yah. for now: stop using cityid (and all city methods like /switchcity > in your apps). instead pass "geolat" and "geolong"
> most of your apps should be fine. i've been watching call traffic just > to make sure
> that's pretty much it; the api has been silently city-agnostic for > most of its life. will update if i think of anything else
> On Jan 5, 4:58 pm, Will Carter <will.car...@gmail.com> wrote:
> > I've seen naveen write that cityid calls should be replaced by geolat + geolong.
> > and I echo the congrats!
> > On Tue, Jan 5, 2010 at 1:56 PM, dp <bigonthepig...@gmail.com> wrote: > > > First, congrats foursquare team! I'm sure this opens the floodgates > > > in almost every respect for you guys. It's gonna be a big year.
> > > Second, any big API changes coming down the pipe due to this? It > > > seems deprecating city id is due to this change. Anything else we > > > should be wary of... or even look forward to?
> On Jan 6, 9:38 am, John <robotshoela...@gmail.com> wrote:
> > Did Foursquare Everywhere bring with it an API call for getting "New > > Mayors Near X" or "Recent Checkins Near Y?"
> we haven't exposed these kinds of queries
> you can still get mayors/checkins nearby if you use the /v1/venues > call to pull venues out first (and then parse that data for mayor/ > history/etc)
> yah. for now: stop using cityid (and all city methods like /switchcity > in your apps). instead pass "geolat" and "geolong"
> most of your apps should be fine. i've been watching call traffic just > to make sure
> that's pretty much it; the api has been silently city-agnostic for > most of its life. will update if i think of anything else
> On Jan 5, 4:58 pm, Will Carter <will.car...@gmail.com> wrote:
> > I've seen naveen write that cityid calls should be replaced by geolat + geolong.
> > and I echo the congrats!
> > On Tue, Jan 5, 2010 at 1:56 PM, dp <bigonthepig...@gmail.com> wrote: > > > First, congrats foursquare team! I'm sure this opens the floodgates > > > in almost every respect for you guys. It's gonna be a big year.
> > > Second, any big API changes coming down the pipe due to this? It > > > seems deprecating city id is due to this change. Anything else we > > > should be wary of... or even look forward to?
I read the blog and changed my home city from Denver to the suburb of Denver that I'm in. When I called http://api.foursquare.com/v1/user.xml I still received back a cityid of Denver.
This doesn't cause a problem in any way, I was just wondering if when you enter a location it geocodes it and finds the nearest finds a larger city. Are there certain size or distance rules that allow a prevent a city to stand on its own as far as the API is concerned?
Thanks -dp
On Jan 8, 2:00 pm, naveen <naveen...@gmail.com> wrote:
> On Jan 5, 6:17 pm, naveen <naveen...@gmail.com> wrote:
> > yah. for now: stop using cityid (and all city methods like /switchcity > > in your apps). instead pass "geolat" and "geolong"
> > most of your apps should be fine. i've been watching call traffic just > > to make sure
> > that's pretty much it; the api has been silently city-agnostic for > > most of its life. will update if i think of anything else
> > On Jan 5, 4:58 pm, Will Carter <will.car...@gmail.com> wrote:
> > > I've seen naveen write that cityid calls should be replaced by geolat + geolong.
> > > and I echo the congrats!
> > > On Tue, Jan 5, 2010 at 1:56 PM, dp <bigonthepig...@gmail.com> wrote: > > > > First, congrats foursquare team! I'm sure this opens the floodgates > > > > in almost every respect for you guys. It's gonna be a big year.
> > > > Second, any big API changes coming down the pipe due to this? It > > > > seems deprecating city id is due to this change. Anything else we > > > > should be wary of... or even look forward to?
> I read the blog and changed my home city from Denver to the suburb of > Denver that I'm in. When I calledhttp://api.foursquare.com/v1/user.xml > I still received back a cityid of Denver.
> This doesn't cause a problem in any way, I was just wondering if when > you enter a location it geocodes it and finds the nearest finds a > larger city. Are there certain size or distance rules that allow a > prevent a city to stand on its own as far as the API is concerned?
> Thanks > -dp
> On Jan 8, 2:00 pm, naveen <naveen...@gmail.com> wrote:
> > btw, we just put up a blog post about what "everywhere" means when it > > comes to badges, points, city buckets, adding venues, etc
> > On Jan 5, 6:17 pm, naveen <naveen...@gmail.com> wrote:
> > > yah. for now: stop using cityid (and all city methods like /switchcity > > > in your apps). instead pass "geolat" and "geolong"
> > > most of your apps should be fine. i've been watching call traffic just > > > to make sure
> > > that's pretty much it; the api has been silently city-agnostic for > > > most of its life. will update if i think of anything else
> > > On Jan 5, 4:58 pm, Will Carter <will.car...@gmail.com> wrote:
> > > > I've seen naveen write that cityid calls should be replaced by geolat + geolong.
> > > > and I echo the congrats!
> > > > On Tue, Jan 5, 2010 at 1:56 PM, dp <bigonthepig...@gmail.com> wrote: > > > > > First, congrats foursquare team! I'm sure this opens the floodgates > > > > > in almost every respect for you guys. It's gonna be a big year.
> > > > > Second, any big API changes coming down the pipe due to this? It > > > > > seems deprecating city id is due to this change. Anything else we > > > > > should be wary of... or even look forward to?
we couldn't be exactly sure which API clients were still observing those fields (we can only tell you're hitting /user and not what you're doing with the data). we didn't want to break your clients (because many of them user /user for authentication, fetching user data on launch, etc)
it's deprecated and it will disappear in the near future
On Jan 8, 4:36 pm, dp <bigonthepig...@gmail.com> wrote:
> On Jan 8, 2:34 pm, dp <bigonthepig...@gmail.com> wrote:
> > Naveen,
> > I read the blog and changed my home city from Denver to the suburb of > > Denver that I'm in. When I calledhttp://api.foursquare.com/v1/user.xml > > I still received back a cityid of Denver.
> > This doesn't cause a problem in any way, I was just wondering if when > > you enter a location it geocodes it and finds the nearest finds a > > larger city. Are there certain size or distance rules that allow a > > prevent a city to stand on its own as far as the API is concerned?
> > Thanks > > -dp
> > On Jan 8, 2:00 pm, naveen <naveen...@gmail.com> wrote:
> > > btw, we just put up a blog post about what "everywhere" means when it > > > comes to badges, points, city buckets, adding venues, etc
> > > On Jan 5, 6:17 pm, naveen <naveen...@gmail.com> wrote:
> > > > yah. for now: stop using cityid (and all city methods like /switchcity > > > > in your apps). instead pass "geolat" and "geolong"
> > > > most of your apps should be fine. i've been watching call traffic just > > > > to make sure
> > > > that's pretty much it; the api has been silently city-agnostic for > > > > most of its life. will update if i think of anything else
> > > > On Jan 5, 4:58 pm, Will Carter <will.car...@gmail.com> wrote:
> > > > > I've seen naveen write that cityid calls should be replaced by geolat + geolong.
> > > > > and I echo the congrats!
> > > > > On Tue, Jan 5, 2010 at 1:56 PM, dp <bigonthepig...@gmail.com> wrote: > > > > > > First, congrats foursquare team! I'm sure this opens the floodgates > > > > > > in almost every respect for you guys. It's gonna be a big year.
> > > > > > Second, any big API changes coming down the pipe due to this? It > > > > > > seems deprecating city id is due to this change. Anything else we > > > > > > should be wary of... or even look forward to?
