Still some problems of course, but check out the latest iteration of the real-time display app.
New in this version:
- Headsigns are trimmed and included. There is still some more cleaning to do though. Headsigns are quite inconsistent and I’m trying to just pull out prominent destinations.
- Heading arrows have been dimmed and placed behind the text headings. These only show up after all of the shapes have loaded. Clearly, there are some legibility issues right now, but I think the positioning is the way I like it and legibility can maybe be resolved with color changes.
- I’ve removed the randomly placed ‘vehicle locations’ that I’d been playing with. For now ;-)
Thoughts and comments much appreciated! If you follow the link above, you’ll be taken to a page where you can select stops. Pick one or a few and hit the button that says ‘use selected stops’. Then wait for something to go wrong and then tell me about it.
Is it too bold? It has to be too bold, right? Cause I think I kind of like it a lot.
See this version of the app directly!
In any case I got a couple new things working since yesterday:
- Trigonometry: I don’t totally understand it, but it is orienting those arrows that appear after a minute to tell you which way the bus is heading.
- That tileset. Yum.
- Route numbers have been removed from the second or third appearance of each route. Is anyone reading this colorblind? Can I get some feedback on that?
Yet to accomplish:
- Still need to accommodate portrait oriented screens (I’m using CSS vmin a lot right now).
- De-emphasise departures which are not real-time.
- Vehicle locations! Make them real instead of generating them randomly ;-)
So, as you may remember, I’ve been tasked with developing a live display using SORTA’s real-time API. The basic idea is to put tablet computers around town in store windows, behind bars, on coffee shop counters, etc, which will alert people to the fact that there is a bus coming (they are almost always almost here) to take them where they might already plan on going. To that end I’ve been developing a web application that can run in a browser. When full-screened, it turns any monitor into a real-time display.
The tablets that we distribute to businesses will basically just have a link to the web-app stuck to their home screens. Which means of course that the tablets/laptops/typewriters y’all are using right now to read this can also function as a real-time display! Power to the people, I say.
Well, development has been progressing more or less slowly over the last couple months (Did I mention that I graduated, got married (before it was legal!) and moved to another country? Well, I did. I’ve been busy.) but the app is finally ready to share as a beta version available at http://cincymap.org/rt/ .
To get started, pan to your location (or hit the button that asks for your location) and select some stops. For the love of jesus, make them close together; I didn’t design this for crazy teleporting people. Then hit the button to use the selected stops and the app will load arrival times for those stops and start refreshing them when new data is available.
One of my big goals for this app is that it should help show people what’s available and where transit is actually going, not just when the obscure number X local is departing northbound, so maps are a big part of this. Right now, I have the app displaying the actual route on a background of OpenStreetMap tiles, with the portion already travelled diminished and the part yet ahead in a darker color. The map also has a bit of animation going on to highlight the whole remainder of the route before zooming back into the immediate context of the stop.
I’d appreciate any constructive feedback suggestions that anyone has, but please keep in mind that I’m still actively developing this. If you’re about to suggest something obvious, I’m probably about to do it anyway. Keep the suggestions subtle!
Goals for the next few days:
- Modify stylesheets to allow for portrait oriented screens.
- Find a tileset that I can use without bothering anyone. I’m pretty sure the OSM people will be a little peeved if I use the basic tiles in a production app. Something black and white perhaps?
- Remove the route numbers from all but the first departures for each route. The colors can distinguish for the rest, or perhaps I can just make the number a lot smaller to allow a bit more map space.
- Distinguish between arrivals that are real-time and those which are only scheduled. This shouldn’t matter once Gaslight makes an update to their API.
- Give an indication of direction for each of the upcoming arrivals on the right side. This matters a lot for two-way stop selections, but it’s not super obvious how to do it technically in a way that will give intuitive results. I’m thinking something like this.
Goals for the next month:
- Play with displaying vehicle locations when vehicles are off-screen. I’m planning to have this ready to present at the NACIS conference in Minneapolis this October. Right now I have the app generating random vehicle locations for the purposes of testing some ideas, until we get the vehicle locations API up and running.
For those of you who may have missed an earlier post, or who are finding this blog for the first time, please be advised that there may be but few updates coming. I have moved away from my exciting and bitter eight-year relationship with Cincinnati to the more expensive and diverse city of Toronto, Ontario.
Still seen as through a cell phone, darkly.
Though having been here for several days now, I feel I should send a letter home with some initial thoughts and relevant comparisons.
- I don’t yet understand how bicycling works here. There seems to be much more bicycle infrastructure, and about a thousand times more cyclists, but I still find myself quite definitely on the vehicular cycling side of the debate. Cyclists here ride far to the right side of the road, and while car drivers seem very much more competent at driving near people, they can still pass extremely close to the cyclists, even while they are riding in the door-zone next to parked cars. In fact, that appears to be the norm. Perhaps people are also extremely cautious about opening their car doors? As a vehicular cyclist myself, this sort of riding absolutely terrifies me. Yet a couple times when I tried to take the lane for myself, the car behind me clearly indicated that this was not how it expected/wanted me to behave. There are also clear benefits to filtering forward on the right: cars can’t turn until the pedestrians clear the crosswalks, but bikes going straight can get ahead of the turning cars by moving with the pedestrians.
- Streetcar tracks are not as bad for bike tires as I thought they would be or as the ones in Cincinnati are. I think the Toronto tracks have narrower grooves and are more flush with the road.
- There is actual bicycle congestion here, exacerbated to be sure by the fact that cyclists generally stick to a narrow bike lane. Passing is constrained by the presence of cars on the left, so a slow rider can hold up a line of bikes for a while. Also, cyclists actually pile up at red lights! That’s not interesting so much as it is exciting, I guess.
- Can it be possible that Cincinnati has a slightly more modern fare payment system than Toronto?? This agency still has tokens and accepts cash fares at the point of boarding, and does not have a stored-value card!
- Streetcars travel down the middle of many two lane streets and people board them by walking to the middle of the street across a lane of traffic. But the traffic is extremely well-trained and will not pass a stopped streetcar until all of the doors are closed.
- What’s the deal with the new streetcar designs TTC is rolling out? Are they supposed to be sexier? Flashier? To get all the “choice riders”? Hell no. They are clearly being introduced because they are larger and the smaller streetcar vehicles can get insanely crowded. There is a line in the Spadina subway station to get on the streetcar and they have to cut it off when it’s packed full. A larger vehicle…
- Streetcar bunching and breakdowns are a major problem as far as I can tell. TTC operates some very long routes, and since the vehicles can’t pass eachother or anything else that gets in their way, all of the cars have to turn back before the breakdown until the thing is cleared. Streetcars have their charm, but this would not be a problem with electric trolley buses.
So, I think the big lessons from the first week are that it’s possible to train car drivers to be more competent around the humans, bike lanes do NOT ever make me feel more safe, and streetcars are definitely less reliable than buses.
That’s what I got for today. Now back to working on that real-time app!
Another in a series of posts that need finally to either die or exit my draft folder by publication. This one was composed sometime in the summer of 2014. -Nate
I gather myself in the presence of others though not in their company. They pass me by, a harmless goomba on their screen. Rush hour is the quietest. A thousand throbbing glimpses of privacy flash by, a thousand people I need never meet. Rarely one car breaks its windows, and like that horror movie trope, the tv speaks to me: a friend slows down to become human for a moment so quickly again gone, rushed away in the pounding surf.
A lonely mountain, perhaps, is where some simple people seek solitude but I’m too lazy for that or perhaps too near a substitute. I find my quiet in the inhumanity of the car’s deafening rage. It’s not quiet so much I seek perhaps but loneliness in labor far from home, a break in scale, flying to the super- and inevitably sub-human. The best walks aren’t what the urbanists would tell you. They’re too long, at rush hour or in the middle of the night, along highways and train tracks, hopping fences and stepping in shit. They’re death-defying, smelly, lonely, silent and loud.
I crouch beneath an underpass and no one sees me and I am alone.
This post was written in the winter of 2014, but for some reason I got distracted and never posted it. Now I’m cleaning house, and here it is! In case you were wondering why it’s about winter weather…
About twice a week, I find myself waiting for the #17 at 13th and Main, heading up to UC for the day. The #17 works well for me since the geography department is on the west side of campus anyway, though in the winter more often than not I find myself wishing for a bus, any bus, for the love of god, when is the bus coming? My hands are freezing! I find myself here almost every day, but about twice a week, like I say, I find myself in a particular situation: passed up by a bus that’s going the same place I’m going, its clean, brightly lit, warm interior mocking me through it’s big windows. I don’t care it’s it’s going to the other side of campus. I just want on.
The M+ has just passed by. My inclination is to run for it’s next stop, but my position on 13th street denies me the option.
Once I see the M+ coming up Main, it’s too late to run south to the courthouse stop, too far and still too late to run up to it’s next stop at Findlay market. This is why the M+ is marginally faster than the other buses. It doesn’t stop for people like me, people of course, not at it’s limited and clearly signed set of stops.
The 13th Street stop is the one closest to my house and it’s always my starting place when catching transit up to campus. I always look south when I get there, and if I don’t see anything coming, sometimes I’ll sneak toward the courthouse, stop by stop, never getting too far away in case a bus pops out of nowhere. (Sometimes I creep north, constantly looking back…do I have time to grab a baguette?!? I pay for it, already half-way out the door.) The courthouse stop, see, has better frequency toward campus since it works for both the #17 and the M+, two high-frequency lines going where I want to go. Since they don’t usually arrive at exactly the same time, their headways compound and we get some constructive interference.
But it’s more complicated than this. Because the schedules for the #17 and M+ don’t work together, aren’t coordinated, reliably interrelated, I never know which to catch, which will actually get me to Braunstein Hall first. Both are frequent enough that I wouldn’t bother looking at a schedule if I wanted either, and both are so often just a little late or early that it wouldn’t do me much good if I did. In the absence of real-time-location information…you know what? Let’s let this derailment happen. Why not?
Where the h*ll is that real-time data, SORTA? What’s the deal here? This is getting really frustrating, now that the real-time info is posted at half a dozen stops. You’ve missed at least three of your own deadlines for releasing it. Stop making excuses and get your shit together!!!! RAAAGHAHG!!!
*Phew* OK. Back on track. Without that real-time data, I’m essentially looking to ascertain the quantum state of the buses. Buses here are both a wave and a particle. Clearly working in a regular pattern, they still come in discrete chunks which can be discovered only by measurement and then never exactly predicted.
What’s a boy to do?
Stop fussing and wait an extra minute perhaps. That would be too simple though.
A big part of my problem here is that the schedules aren’t coordinated, meaning that they overlap and interact with each other in unpredictable ways. If they were coordinated, I could decide now which stop is usually the better one and stick to that decision.
In this particular situation, there’s not a good case to be made that these ones should be coordinated since they split off from each other once they get to the hill, but my dilemma illustrates a broader problem with the way SORTA has conceived of BRT: as a fast express line mostly redundant to a slow local service. Schedule coordination is impossible where lines are running at different speeds.
And this same problem becomes more dramatic when I consider other destinations. Lets say I want to get to Norwood, or once there, even further out to Kenwood. In the first case, I would have to take a bigger risk in walking toward the courthouse stop. The #4 turns east around the corner from the courthouse stop, meaning that I can’t even see it coming.
The best choice would necessarily be based on expected waiting times and expected travel times. A better-than-probabilistic decision can’t realistically be made during higher-frequency hours since the normal(in the non-statistical sense at least) delays, disrupt shorter and more-frequent trips more, relatively speaking. In the later case, I would most likely be presented with the same optimizing tactic that finds me sneaking south on Main Street. That is: walk to the nearest stop on Montgomery Road and once there, inch toward the closest higher-frequency stop, taking in any case whichever bus comes first. Once I know the position of one bus, the one having just arrived, I won’t typically wait around for the next since it’s position is unknown and possibly very distant. Assuming both came at once, and were both stopping, the choice would be easy: the faster one.
The problem here is one of lost potential. It’s not a bad situation by any stretch(I have two reasonably frequent-transit options! Yay!) but it could be better. Rather than having two transit lines in the same corridor running at ten-minute headways, one dramatically faster than other, we could have one line, significantly faster than what we have now, running more consistently, more frequently, and importantly: more simply.
Express lines, as SORTA have conceived them, split the baby.