WherePost: now even more useful!

Since I launched Where Post? on Friday morning, the response has been pretty gratifying. My thanks to David Eaves for his nice post about Where Post? this morning. I launched the app with a total of 28 mailboxes and 1 post office. Since then, 29 contributors have added in another 400-odd mailboxes and about 20 post offices. (NB: ‘contributors’ are identified currently via a combination of a cookie & IP Address – so it’s not exact, but close enough).

I’m please to announce a very useful addition: Every post office in the Google Maps database, everywhere, pulled in from the Google Places API. I had noticed while adding post offices that there was often an envelope icon already in the map where I wanted to add a post office. After some digging this afternoon, I was able to pull in the places API to just get all the places that identify as a post office.

There’s a few oddities to figure out:

  1. Often each post office is listed 2 or 3 times at least in Canada: The french name & english name appear to be 2 places, and sometimes the post office in english, the post office in french and the store containing the post office are all listed. Odd, and I haven’t yet figured a way to filter this, but still pretty nice.
  2. I have a rate limit of 100,000 queries a day. Given that each time you see the “loading mailboxes” message there’s a query to Google, there’s a distinct possibility I’ll reach that. For now not a worry, but definitely a scaling/caching issue to think about in the future.
  3. Integrating with the “nearest” function. Currently, the “nearest” mailbox is simply pulled from an SQL query – which means that post offices, coming in from Google, are ignored. There’s likely a way to merge the two, but nothing’s coming to mind at the moment.

As always, if you have any suggestions, comments or anything else, please let me know!

Nighttime cycling, open data, app idea

Last night I had a board meeting that ran until about 9pm – this being the fall, it was dark when I rode home, for the first time since I’ve started this daily bicycle commuting thing. I’m generally well-prepared: I wear reflective clothing, my saddle-bag has a reflector, I have a back light that flashes. I don’t (currently) have a front light because it mysteriously disappeared the first time I forgot to take it off my handlebars. I think I’d also like a helmet light to help my vision too.

My route, from Broadway & Fir to home took me along the 10th ave, Ontario & Ridgeway bicycle routes – all ones I’m well familiar with during daylight hours. However, these all become significantly less fun at night. Why? Because there are so many lights that don’t work, dozens more lights who are almost entirely obscured by trees, others yet so dim as to barely light the ground at all. The nicest portion of the ride is the stretch up on Ontario from 12th to 16th, where those new bright-white lights that seem more focused (less light pollution?) have been installed. The stretch of 10th from Hemlock to Ash was by far the worst.

The streetlight across from my house (which is also on a bike route) has been out for sometime. Last night Leah called the city to let them know about that, which you can do via the 311 service But given that there’s a data feed of street lamps for Vancouver, maybe we can automate this a little more. I don’t have the time in the next couple of days, but if anyone has time to cobble together an app, here’s what I was thinking of:

  • Map that shows street lights, let me click on a lamp to indicate it’s not working, obstructed, dim, etc.
  • Twitter service that, based on location of the tweet (using @replies), maps that to the above.
  • Sends a service request to the city (is there a 311 API?)
  • A cool feature would be to “darken” bits of the map based on this data, so you could “show” a map of Vancouver at night based on where lights are on/off, etc – this could be the most useful service, particularly if mapped against bike routes, running routes, etc.

 

%d bloggers like this: