Examining transit tracks on the map

Since last time I've implemented some more of Andreas' nice transit routing mockups.

After performing a search, the map view is zoomed and positioned to accomodate the starting and ending points, as can be seen here, and since at this point no itinerary is selected for further viewing, there are no trails drawn on the map yet.

After selecting an individual itinerary it is drawn out in detail as shown in the following shots:

And zooming in on the start, and you'll see the walking path in this case until reaching the first transit.

The little icons shown in the map marker for boarding locations will match the transit mode icon as shown in the overview list (buses in this case).

And in case the transit data has information about line colors this will reflect the trail segments on the map as well:

The next step on this journey (pun intended :) ) will be to allow expanding each leg of an itinerary to view the intermediate stops, and in case of walking, show the turn point instructions, and also being able to highligt these on the map.

Oh, and as a little word of warning, in case someone is planning on trying this out at home, there is currently a bug in the latest git master of OpenTripPlanner that makes useage without OSM data loaded in the server (as is what I have intended for GNOME usage, since we already have GraphHopper, and as OTP would probably not scale well loading many large regions worth of raw OSM data) querying for routes using pure coordinates doesn't work in that case, so I'm on a couple of weeks old commit right now.
I might wait until this is resolve. Or I might actually look into trying to query for transit stops near the start and finish point and use that when performing the actual query, which might actually yield better result when selecting a subset of allowed transit modes.

It is also probably time to start trying to find funding for a machine hosting an OTP instance for GNOME :-)

And that's that for today!

Rendering transit itineraries in Maps

Since last time, I've spent some time polishing up the rendering of transit itineraries a bit.

In this example, there are some routes with not that many legs, in this case we show the full route name (the route name can typically be a bit longer for i.e. trains).
Also, as you can see the route labels are now rendered with rectangles with nice rounded corners (when thinking about such "roundrects", I always remember this story: Round Rects are Everywhere ).
I had to dive into Cairo rendering to do this, as I couldn't find an easy way to do this with CSS styling (maybe it would have been possible to override the CSS provider somehow), but fortunately Cairo is accessible from JS, so I didn't have to involve C… :-)

The next screenshot shows some itineraries with many "legs", in this case the route labels have been omitted (but the information will of course be available when examining a specific itinerary).

Here we can see another case where some of the route labels have been "condensed", showing the operator name instead of the full route name (for the trains in this example).

In the following screenshot there's some routes with white as the route color, in this case (when the luminosity of color is above a certain threshold), a black outline is drawn around the route label to pronounce it a bit more.

And some itineraries in Brussels again… Also, the route label code has some contrast-checking safe-guard code, that should ensure good contrast, should some data feed contain bogus data.

And when "diving in" to an itinerary it will show the steps and transfers. Still missing is expand these steps to show intermediate stops passed in an itinerary leg, or directions for walking in those cases. Also, the path rendered on the map is still hard-coded to the first one found, it should be updated as the user views a specific itinerary. And yes, the positioning of the headsign labels are a bit off (right before preparing screenshots for this post, I saw that in some case the route label was truncated, so I tried mitigate that, but the result is not optimal so stay tuned).

And lastly, I added some animations for options toolbar GtkRevealer and the stack switching between the itinerary overview and "diving in" on an itinerary. So this prompts for a video:

So, that's it for today.

Transit routing starting to show some life-signs

Since last time, Andreas Nilsson produced some awesome mockups of public transit routing.

So, I ofcourse coudn't resist jumping on these awesome mockups and start implement it.

Right now it's at the point where it can render the ”overview list” of itineraries when performing a search. You can now also select a later departure time (or arrival time, for cases where that makes sense).

After performing a search, something like this can show up:

The route labels (line numbers) are still a bit rough, they should have some rounded corner and spacing, also the text size should probably be slightly smaller. I think the rounded corners and padding should be possible to achieve using a GtkLabel and a custom CSS style (and not having to implement a custom widget inheriting GtkDrawingArea and implement custom drawing using Cairo).
If the transit data feed gives back route color information, this is used here as well (unfortunatly the Swedish data doesn't currently include this). The colors in the screenshot above are fallbacks I put in (which might be adjusted later on).

STIB in Brussels, Belgium does however:

Currently the code is just using whatever colors would come with the data. These colors should probably be checked for good contrast (there's algorithms published by the W3C that we should be able to use for this), and bail out to a good default if the data is clearly less-than-optimal. Also, in case there's only a background color supplied, it should be possible to automagically compute a suitable text color.

Also, as you can see in the screenshots are the new nice icons Andreas made for the various transit modes.

For a more “exotic“ example:

Here you can see an itinerary with Portland's ”Aerial Tram” gondola lift. Also, as you can see here, the route labels gets pretty long (and ”shifts out” the routing side panel), on the TODO is deducing some more compact route labels for the overview view (i.e. using the agency name if it's shorter, or just cut it off and ellipsize). Another interesting point in this screenshot (which was taken just after the previous one) is that the times shown are in the local time zone of the area in question.

Here the departure time was set at approximatly the same time as the local time here when I took the screenshots, which then would give you a trip at that time (21:50) in Portland's timezone (and as can be seen, the gondola lift seems to have ended service for the day).

Oh, and another thing. I added an option to override the (for now hardcoded to using localhost) URL of the OpenTripPlanner instance. This could be used if you know of some publicly available server, or would like to run your own to test with on another machine (or in a VM).

Next up I will take a look at those label issues mentioned, and then move on to implement the “show a specific itinerary view” a.k.a. ”dive into a route” from the mockups.

And one last thing, the route being rendered in the map view is still hardcoded to the first itinerary in result list, this should ofcourse later on be changed so that it changes when you view the individual itineraries in detail.