Re: [S67] more Bus Hacking
Greg Tracy
A lot in your last email - I'll do my best to answer...
1. Data errors - keep sending me those data errors when you see them.
I have a pretty big chunk of data about the stops so it made it
impossible to double-check all of them by hand. In fact, you may
eventually run across stops that don't have a location associated with
them. But when pointed out, I can go in and fix them.
2. Bus Advocates - I would prefer if you didn't include the SMS
interface in that flyer unless the advocates group was able to make a
fiscal donation to the project. I've never publicized the app because
I can't afford to sustain it if it has wide-spread adoption. Usage has
picked up dramatically in the last three months so it's already
stretching my wallet. All of the cost is in the sending and receiving
of the text messages so if they wanted to use one of the other
interfaces (email or chat), that would be fine. And if they have a
budget for such projects and can pay for some service, I'd be happy to
support all of their members. They could even pick their own phone
number if they'd like.
3. Server load - no worries about API load. The system is quite
efficient at managing those requests. And once I port the various bus
kiosks over to using the API natively, it will get even better.
4. API performance - thanks for articulating the performance problem.
I'm aware of it and I think I have a good idea for addressing it, but
those changes will be more significant so I need to take some more
time to think it through and test. I'll keep you posted.
Just to be clear... is the performance problem you see in a single API
call for 'getnearbystops'? Or is it slow because you have to iterate
over the results and make multiple API calls? If it's the latter, I
could add support to 'getroutes' that allows you to pass in a stopID
to get all routes details for a particular stop. As I type this, this
looks like a big use case. Thoughts?
5. Direction data - the root problem with direction data (for an
individual stop) is that stops are not defined by direction. As you
know, if you look at a stop on the square, there are as many as 30
routes traveling through them and those routes have many different
directions. There are two solutions - (a) make multiple API calls as
you are doing now or (b) change the return values of 'getnearbystops'
so it returns a stop entry for each route and include the destination
in each of those results (this would be similar to what you were
seeing before we made the changes in the last couple of days). I'm
open to experimenting so let's keep discussing.
Again - thank you for helping to flush out the API. These APIs are
important projects to showcase for the city and your input here is
invaluable! When you're ready, it would be nice to post snippets of
your code on the API site to use as examples for other developers.
Also... I'm cc'ing the google group because I think the discussion is
great for the entire API community.
Cheers.
Greg
On Wed, Apr 13, 2011 at 12:31 PM, Walker, Larry <walk...@gmail.com> wrote:
> Greg:
> Excellent! This seems to have done it. Boy do I get a lot of stops now!
> For Univ & Farley, max radius:
> http://www.smsmybus.com/api/v1/getnearbystops?key=B24JK9A4&lat=43.0732692&lon=-89.4337454&radius=5000
>
> status = 0
> stop :
> 10 :
> stopID = 2822
> longitude = -89.4288621
> latitude = 43.0744313
> intersection = HIGHLAND & VA HOSP
>
> 11 :
> stopID = 2270
> longitude = -89.438444
> latitude = 43.0748776
> intersection = UNIV AVE & MARSHALL
>
> 12 :
> stopID = 2393
> longitude = -89.4286723
> latitude = 43.0741412
> intersection = HIGHLAND & FOREST PROD
>
> 13 :
> stopID = 2643
> longitude = -89.42858
> latitude = 43.072487
> intersection = HIGHLAND & UNIV AVE
>
> 14 :
> stopID = 0809
> longitude = -89.42858
> latitude = 43.072487
> intersection = UNIVERSITY &
> HIGHLAND|STP-UW||26;**43.0732878|-89.4112861|CAMPUS & BABCOCK RR
>
> 15 :
> stopID = 2177
> longitude = -89.4386396
> latitude = 43.0713213
> intersection = KENDALL & RIDGE
>
> 16 :
> stopID = 2561
> longitude = -89.4282862
> latitude = 43.0720253
> intersection = UNIV AVE & HIGHLAND
>
> 17 :
> stopID = 0470
> longitude = -89.4282862
> latitude = 43.0720253
> intersection = UNIVERSITY & HIGHLAND|OLD
> UNIVERSITY||19;**43.0716871|-89.3928722|BASSETT & DAYTON
>
> 18 :
> stopID = 2742
> longitude = -89.4392031
> latitude = 43.0713457
> intersection = BLUFF & RIDGE
>
> 1 :
> stopID = 2465
> longitude = -89.4339695
> latitude = 43.0733764
> intersection = UNIV AVE & FARLEY
>
> 2 :
> stopID = 2131
> longitude = -89.4336658
> latitude = 43.0739718
> intersection = U BAY & UNIV AVE
>
> 3 :
> stopID = 2570
> longitude = -89.4338965
> latitude = 43.073966
> intersection = U BAY & UNIV AVE
>
> 4 :
> stopID = 2698
> longitude = -89.4346124
> latitude = 43.0738486
> intersection = UNIV AVE & U BAY
>
> 5 :
> stopID = 2494
> longitude = -89.4363007
> latitude = 43.0738936
> intersection = FRANKLIN & UNIV AVE
>
> 6 :
> stopID = 2443
> longitude = -89.4309454
> latitude = 43.0725927
> intersection = UNIV AVE & GRAND
>
> 7 :
> stopID = 2965
> longitude = -89.4364763
> latitude = 43.0714326
> intersection = KENDALL & FRANKLIN
>
> 8 :
> stopID = 2998
> longitude = -89.4365961
> latitude = 43.0715136
> intersection = KENDALL & FRANKLIN
>
> 9 :
> stopID = 2945
> longitude = -89.4384811
> latitude = 43.0746334
> intersection = UNIV AVE & RIDGE
>
> [FYI: note the odd values for 'intersection' on items 14 & 17...]
>
> When I crank down the radius, I get just the result I'm after:
> http://www.smsmybus.com/api/v1/getnearbystops?key=B24JK9A4&lat=43.0732692&lon=-89.4337454&radius=100
>
> status = 0
> stop :
> 1 :
> stopID = 2465
> longitude = -89.4339695
> latitude = 43.0733764
> intersection = UNIV AVE & FARLEY
>
> 2 :
> stopID = 2131
> longitude = -89.4336658
> latitude = 43.0739718
> intersection = U BAY & UNIV AVE
>
> 3 :
> stopID = 2570
> longitude = -89.4338965
> latitude = 43.073966
> intersection = U BAY & UNIV AVE
>
> 4 :
> stopID = 2698
> longitude = -89.4346124
> latitude = 43.0738486
> intersection = UNIV AVE & U BAY
>
> Changing topics: The Madison Bus Advocates group asked if they could
> publicize our apps. I'd prepared a quick handout for them (which I'll
> attach). Now that the By Location feature is working, I'm going to tell them
> later today they can send the info to their mailing list, unless you have
> reservations. Seems like a good way to put some load on things and see how
> they hold up...
> Larry
> ps: I hope I'm not abusing your server with my By Location feature: after
> getting the nearby stops, I get the routes at each stop and pull the
> direction info for each route at the stop, so I can concatenate them
> together and display them, to be able to tell which direction each stop
> serves. It takes rather a long time to return when I do a Cap Sq stop even
> at a low radius!
> That info shows up thusly:
>
>
> Perhaps you could noodle on whether there's a more efficient way to include
> direction info with stops? I wouldn't be surprised if this isn't feasible,
> just thought I'd ask. I think that this feature will be the less-used-path,
> so maybe the time/load issue doesn't matter much...
>
>
>
>
Walker, Larry
Good news!
A lot in your last email - I'll do my best to answer...
1. Data errors - keep sending me those data errors when you see them.
I have a pretty big chunk of data about the stops so it made it
impossible to double-check all of them by hand. In fact, you may
eventually run across stops that don't have a location associated with
them. But when pointed out, I can go in and fix them.
2. Bus Advocates - I would prefer if you didn't include the SMS
interface in that flyer unless the advocates group was able to make a
fiscal donation to the project. I've never publicized the app because
I can't afford to sustain it if it has wide-spread adoption. Usage has
picked up dramatically in the last three months so it's already
stretching my wallet. All of the cost is in the sending and receiving
of the text messages so if they wanted to use one of the other
interfaces (email or chat), that would be fine. And if they have a
budget for such projects and can pay for some service, I'd be happy to
support all of their members. They could even pick their own phone
number if they'd like.
3. Server load - no worries about API load. The system is quite
efficient at managing those requests. And once I port the various bus
kiosks over to using the API natively, it will get even better.
4. API performance - thanks for articulating the performance problem.
I'm aware of it and I think I have a good idea for addressing it, but
those changes will be more significant so I need to take some more
time to think it through and test. I'll keep you posted.
Just to be clear... is the performance problem you see in a single API
call for 'getnearbystops'? Or is it slow because you have to iterate
over the results and make multiple API calls? If it's the latter, I
could add support to 'getroutes' that allows you to pass in a stopID
to get all routes details for a particular stop. As I type this, this
looks like a big use case. Thoughts?
5. Direction data - the root problem with direction data (for an
individual stop) is that stops are not defined by direction. As you
know, if you look at a stop on the square, there are as many as 30
routes traveling through them and those routes have many different
directions. There are two solutions - (a) make multiple API calls as
you are doing now or (b) change the return values of 'getnearbystops'
so it returns a stop entry for each route and include the destination
in each of those results (this would be similar to what you were
seeing before we made the changes in the last couple of days). I'm
open to experimenting so let's keep discussing.
Again - thank you for helping to flush out the API. These APIs are
important projects to showcase for the city and your input here is
invaluable! When you're ready, it would be nice to post snippets of
your code on the API site to use as examples for other developers.
Also... I'm cc'ing the google group because I think the discussion is
great for the entire API community.
Cheers.