Carol and I spent some time at Sector67 yesterday, poking at the edges of the Bus Terminal concept and generally brainstorming (thanks Brandon and Marcus!) about hardware options.
A couple of new conceptual approaches came out of the discussion. They hinged off the observation that having a browser or not (and all the OS, h/w, s/w cost that goes along with having one) seemed like a pivotal decision:
1) Use a wireless picture frame as the output device. Set it to display a certain folder on Picassa (or somewhere). Use some server software to "construct" an image of a bus schedule display and render it as a JPEG. Once a minute regenerate the image and replace the file on Picassa. (Can digital photo frames be told to go refresh an image periodically?)
2) Most/many places that would want a Bus Terminal display (coffee shop, restaurant, office building) will already have a PC running. Look for a device that can use USB (or other port) to connect to a wireless device that transmits the video image to a wireless receiver hooked to a monitor. I believe X-10 makes such devices, for instance. Run a background program on the receptionist's PC, and transmit the output wirelessly to a monitor.
On the software front, I'm very close to having a smartphone live-arrival-time web-app finished. Just need Greg to open up one more call to the SYSMyBus API and I'll be able to let you enter a generic location description ("State and Gorham", "University & Farley") and get back a list of nearby stops (using Google Maps API plus Greg's API); select a stop and get back the list of the next N arrivals (based on live GPS bus data, fetched through Greg's API). Nice hack, thanks to Greg's suggestion.
Carol's working up an HTML5 CSS wrapper for the iPhone to make the liveBus web-app look prettier, and properly iPhone-like. If we can get that working, we'll be looking for someone with an Android phone to test on...
And I have bar-code bus-stop stickers working as well:
Meant to chat with you for a few minutes last night, but got involved in some other discussions and didn't make it around.
I think that San Francisco provides a nice model of what's possible. SF public transport provides a mobile website that functions much like what you are proposing. Madison Metro claims to provide a similar website, but I have not had much luck using it from my phone.
Do you know if it's possible to request GPS information from a smartphone in a mobile website? If possible, you could identify the users location, locate the closest bus stop, and pull the arrival information for that particular stop.
Each MUNI stop in SF has a scrolling LED display that notifies of the next bus or trolly to arrive, and when it's expected. I noticed that some of the stops utilized PV to power the system. Given Madison's city-wide Wi-Fi, it would be possible to build similar devices for areas covered under the 802.11 network to provide scrolling arrival information. I'd be interested to see just how low you could go, power wise, for a system like this.
I'm excited about whatever the solution. It's high time that Madison had a better way to access Madison Metro information - this is a huge source of frustration for me when I think about taking the bus rather than driving!
Mark
On Mon, Apr 4, 2011 at 9:50 AM, Larry Walker <la...@walkerenergysystems.com>wrote:
> Carol and I spent some time at Sector67 yesterday, poking at the edges of > the Bus Terminal concept and generally brainstorming (thanks Brandon and > Marcus!) about hardware options.
> A couple of new conceptual approaches came out of the discussion. They > hinged off the observation that having a browser or not (and all the OS, > h/w, s/w cost that goes along with having one) seemed like a pivotal > decision:
> 1) Use a wireless picture frame as the output device. Set it to display a > certain folder on Picassa (or somewhere). Use some server software to > "construct" an image of a bus schedule display and render it as a JPEG. Once > a minute regenerate the image and replace the file on Picassa. (Can digital > photo frames be told to go refresh an image periodically?)
> 2) Most/many places that would want a Bus Terminal display (coffee shop, > restaurant, office building) will already have a PC running. Look for a > device that can use USB (or other port) to connect to a wireless device that > transmits the video image to a wireless receiver hooked to a monitor. I > believe X-10 makes such devices, for instance. Run a background program on > the receptionist's PC, and transmit the output wirelessly to a monitor.
> On the software front, I'm very close to having a smartphone > live-arrival-time web-app finished. Just need Greg to open up one more call > to the SYSMyBus API and I'll be able to let you enter a generic location > description ("State and Gorham", "University & Farley") and get back a list > of nearby stops (using Google Maps API plus Greg's API); select a stop and > get back the list of the next N arrivals (based on live GPS bus data, > fetched through Greg's API). Nice hack, thanks to Greg's suggestion.
> Carol's working up an HTML5 CSS wrapper for the iPhone to make the liveBus > web-app look prettier, and properly iPhone-like. If we can get that working, > we'll be looking for someone with an Android phone to test on...
> And I have bar-code bus-stop stickers working as well:
> (Try it: point your smartphone's bar-code-reading app at this email :-)
> Demo at Tuesday's meeting?
> Larry > -- > You received this message because you are subscribed to the Google Groups > "Sector67" group. > To post to this group, send email to sector67@googlegroups.com. > To unsubscribe from this group, send email to > sector67+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sector67?hl=en.
Yep, if you write an HTML5/CSS/JS app and package it using PhoneGap, you can access the GPS location information of a smartphone.
Tangentially, I'm interested if there is any way to get Madison Metro route information into the format that Google is using in it's protocol for transit systems. http://code.google.com/transit/spec/transit_feed_specification.html Greg, we may have talked about this but I don't recall, nor do I recall the name of the software that is theoretically working on an API that MM woudl use. Not highwire, but something else the Bus Radar guys mentioned.....?
This could both put Madison Metro in the Google Maps transit space, but also ultimately allow for an App that would work in any city that ses the protocol. So rather than an App built by each city, folks can compete to make good interfaces and then each city would be accessible once you arrived, because they all used the same protocol.
Carol
On Wed, Apr 6, 2011 at 5:36 PM, Mark D. Ratzburg <mratzb...@gmail.com>wrote:
> Meant to chat with you for a few minutes last night, but got involved in > some other discussions and didn't make it around.
> I think that San Francisco provides a nice model of what's possible. SF > public transport provides a mobile website that functions much like what you > are proposing. Madison Metro claims to provide a similar website, but I have > not had much luck using it from my phone.
> Do you know if it's possible to request GPS information from a smartphone > in a mobile website? If possible, you could identify the users location, > locate the closest bus stop, and pull the arrival information for that > particular stop.
> Each MUNI stop in SF has a scrolling LED display that notifies of the next > bus or trolly to arrive, and when it's expected. I noticed that some of the > stops utilized PV to power the system. Given Madison's city-wide Wi-Fi, it > would be possible to build similar devices for areas covered under the > 802.11 network to provide scrolling arrival information. I'd be interested > to see just how low you could go, power wise, for a system like this.
> I'm excited about whatever the solution. It's high time that Madison had a > better way to access Madison Metro information - this is a huge source of > frustration for me when I think about taking the bus rather than driving!
> Mark
> On Mon, Apr 4, 2011 at 9:50 AM, Larry Walker < > la...@walkerenergysystems.com> wrote:
>> Carol and I spent some time at Sector67 yesterday, poking at the edges of >> the Bus Terminal concept and generally brainstorming (thanks Brandon and >> Marcus!) about hardware options.
>> A couple of new conceptual approaches came out of the discussion. They >> hinged off the observation that having a browser or not (and all the OS, >> h/w, s/w cost that goes along with having one) seemed like a pivotal >> decision:
>> 1) Use a wireless picture frame as the output device. Set it to display a >> certain folder on Picassa (or somewhere). Use some server software to >> "construct" an image of a bus schedule display and render it as a JPEG. Once >> a minute regenerate the image and replace the file on Picassa. (Can digital >> photo frames be told to go refresh an image periodically?)
>> 2) Most/many places that would want a Bus Terminal display (coffee shop, >> restaurant, office building) will already have a PC running. Look for a >> device that can use USB (or other port) to connect to a wireless device that >> transmits the video image to a wireless receiver hooked to a monitor. I >> believe X-10 makes such devices, for instance. Run a background program on >> the receptionist's PC, and transmit the output wirelessly to a monitor.
>> On the software front, I'm very close to having a smartphone >> live-arrival-time web-app finished. Just need Greg to open up one more call >> to the SYSMyBus API and I'll be able to let you enter a generic location >> description ("State and Gorham", "University & Farley") and get back a list >> of nearby stops (using Google Maps API plus Greg's API); select a stop and >> get back the list of the next N arrivals (based on live GPS bus data, >> fetched through Greg's API). Nice hack, thanks to Greg's suggestion.
>> Carol's working up an HTML5 CSS wrapper for the iPhone to make the liveBus >> web-app look prettier, and properly iPhone-like. If we can get that working, >> we'll be looking for someone with an Android phone to test on...
>> And I have bar-code bus-stop stickers working as well:
>> (Try it: point your smartphone's bar-code-reading app at this email :-)
>> Demo at Tuesday's meeting?
>> Larry >> -- >> You received this message because you are subscribed to the Google Groups >> "Sector67" group. >> To post to this group, send email to sector67@googlegroups.com. >> To unsubscribe from this group, send email to >> sector67+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/sector67?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "Sector67" group. > To post to this group, send email to sector67@googlegroups.com. > To unsubscribe from this group, send email to > sector67+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sector67?hl=en.
I'm with Carol regarding getting Metro into the Google Transit system: clearly where we ought to be going. In the meantime, though, there is clearly a lot we can do to hack the current system into a more usable form. And maybe use the demos to raise some public attention that Metro could be doing so much more to make it easier to ride the bus.
So Carol is exploring how much access we can get to device properties (like GPS position) from a web-app (i.e. HTML5/CSS/JS), and I'm working on the server-part that calls Greg's API and feeds the data into Carol's CSS. It's mostly all working (or close enough to have a V1.0 release Real Soon Now), and once it is, we'll have to decide where to go next with this project...
As to your question about "how low you can go, power-wise": not that low yet. But I haven't started learning about Arduino sleep-mode, which could take battery life from days to months, if it doesn't mess up the WiFi connection. A more interesting challenge is "how cheap can you go". I'd like to come up with a bare-bones "bus terminal" device that costs well under $100 (possibly using recycled devices, like old LCD displays rehabbed at Sector67).
I've started thinking about how/what we could do in the way of a "bus-lookup awareness week": a publicity event, maybe with post-it bar-codes on all the downtown/campus bus-stops, some articles arranged ahead of time about BusRadar and <whatever Carol & I come up with for iOS/generic-smartphone>, a call for Metro to get into the Google Transit system, promote the SMSMyBus API for other hackers to build on, demo "bus terminals" in some high-visibility locations, etc, etc.
Greg: Are plans proceeding for a "civic hacking" BarCamp? Perhaps a Metro-Lookup Week could piggy-back on such an event?
Larry
On Apr 6, 2011, at 5:36 PM, Mark D. Ratzburg wrote:
> Meant to chat with you for a few minutes last night, but got involved in some other discussions and didn't make it around.
> I think that San Francisco provides a nice model of what's possible. SF public transport provides a mobile website that functions much like what you are proposing. Madison Metro claims to provide a similar website, but I have not had much luck using it from my phone.
> Do you know if it's possible to request GPS information from a smartphone in a mobile website? If possible, you could identify the users location, locate the closest bus stop, and pull the arrival information for that particular stop.
> Each MUNI stop in SF has a scrolling LED display that notifies of the next bus or trolly to arrive, and when it's expected. I noticed that some of the stops utilized PV to power the system. Given Madison's city-wide Wi-Fi, it would be possible to build similar devices for areas covered under the 802.11 network to provide scrolling arrival information. I'd be interested to see just how low you could go, power wise, for a system like this.
> I'm excited about whatever the solution. It's high time that Madison had a better way to access Madison Metro information - this is a huge source of frustration for me when I think about taking the bus rather than driving!
I met Chuck Kamp, general manager of Metro, at a public meeting in February. I asked him about getting Metro's data into Google Maps's trip planner. He said they were working with Google on it.
Google's transit data is route and stop info; it does not include real-time data.
I'd like to help with some part of this project.
--Davi
On Fri, Apr 8, 2011 at 9:55 AM, Larry Walker <la...@walkerenergysystems.com>wrote:
> I'm with Carol regarding getting Metro into the Google Transit system: > clearly where we ought to be going. In the meantime, though, there is > clearly a lot we can do to hack the current system into a more usable form. > And maybe use the demos to raise some public attention that Metro could be > doing so much more to make it easier to ride the bus.
> So Carol is exploring how much access we can get to device properties (like > GPS position) from a web-app (i.e. HTML5/CSS/JS), and I'm working on the > server-part that calls Greg's API and feeds the data into Carol's CSS. It's > mostly all working (or close enough to have a V1.0 release Real Soon Now), > and once it is, we'll have to decide where to go next with this project...
> As to your question about "how low you can go, power-wise": not that low > yet. But I haven't started learning about Arduino sleep-mode, which could > take battery life from days to months, if it doesn't mess up the WiFi > connection. A more interesting challenge is "how cheap can you go". I'd like > to come up with a bare-bones "bus terminal" device that costs well under > $100 (possibly using recycled devices, like old LCD displays rehabbed at > Sector67).
> I've started thinking about how/what we could do in the way of a > "bus-lookup awareness week": a publicity event, maybe with post-it > bar-codes on all the downtown/campus bus-stops, some articles arranged > ahead of time about BusRadar and <whatever Carol & I come up with for > iOS/generic-smartphone>, a call for Metro to get into the Google Transit > system, promote the SMSMyBus API for other hackers to build on, demo "bus > terminals" in some high-visibility locations, etc, etc.
> Greg: Are plans proceeding for a "civic hacking" BarCamp? Perhaps a > Metro-Lookup Week could piggy-back on such an event?
> Larry
> On Apr 6, 2011, at 5:36 PM, Mark D. Ratzburg wrote:
> > Larry,
> > Meant to chat with you for a few minutes last night, but got involved in > some other discussions and didn't make it around.
> > I think that San Francisco provides a nice model of what's possible. SF > public transport provides a mobile website that functions much like what you > are proposing. Madison Metro claims to provide a similar website, but I have > not had much luck using it from my phone.
> > Do you know if it's possible to request GPS information from a smartphone > in a mobile website? If possible, you could identify the users location, > locate the closest bus stop, and pull the arrival information for that > particular stop.
> > Each MUNI stop in SF has a scrolling LED display that notifies of the > next bus or trolly to arrive, and when it's expected. I noticed that some of > the stops utilized PV to power the system. Given Madison's city-wide Wi-Fi, > it would be possible to build similar devices for areas covered under the > 802.11 network to provide scrolling arrival information. I'd be interested > to see just how low you could go, power wise, for a system like this.
> > I'm excited about whatever the solution. It's high time that Madison had > a better way to access Madison Metro information - this is a huge source of > frustration for me when I think about taking the bus rather than driving!
> > Mark
> -- > You received this message because you are subscribed to the Google Groups > "Sector67" group. > To post to this group, send email to sector67@googlegroups.com. > To unsubscribe from this group, send email to > sector67+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sector67?hl=en.
Based on my experience building various transit apps, putting together the API, and interacting with the city on these projects, I'm of the belief that the best way to get their attention and promote more open data systems is simply to continue to build useful tools. There is still a lot of opportunity just in transit and Larry and Carol are doing an awesome job exploring new applications.
As Larry alluded to, there is an effort to put together a mini-Barcamp in the next month or so that is focused on civic hacking and transit hacks would be a great thing to highlight.
On Sun, Apr 10, 2011 at 9:29 AM, Greg Tracy <gtr...@gmail.com> wrote:
> Based on my experience building various transit apps, putting together the > API, and interacting with the city on these projects, I'm of the belief that > the best way to get their attention and promote more open data systems is > simply to continue to build useful tools. There is still a lot of > opportunity just in transit and Larry and Carol are doing an awesome job > exploring new applications.
> As Larry alluded to, there is an effort to put together a mini-Barcamp in > the next month or so that is focused on civic hacking and transit hacks > would be a great thing to highlight.
> -- > You received this message because you are subscribed to the Google Groups > "Sector67" group. > To post to this group, send email to sector67@googlegroups.com. > To unsubscribe from this group, send email to > sector67+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sector67?hl=en.
> On Sun, Apr 10, 2011 at 9:29 AM, Greg Tracy <gtr...@gmail.com> wrote:
> Based on my experience building various transit apps, putting together the API, and interacting with the city on these projects, I'm of the belief that the best way to get their attention and promote more open data systems is simply to continue to build useful tools. There is still a lot of opportunity just in transit and Larry and Carol are doing an awesome job exploring new applications.
> As Larry alluded to, there is an effort to put together a mini-Barcamp in the next month or so that is focused on civic hacking and transit hacks would be a great thing to highlight.
> -- > You received this message because you are subscribed to the Google Groups "Sector67" group. > To post to this group, send email to sector67@googlegroups.com. > To unsubscribe from this group, send email to sector67+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/sector67?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Sector67" group. > To post to this group, send email to sector67@googlegroups.com. > To unsubscribe from this group, send email to sector67+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/sector67?hl=en.
