Wednesday, February 15, 2017

Transit routing has landed!

So, at FOSDEM a bit over a week ago, me, Jonas Danielsson, Mattias Bengtsson, and Andreas Nilsson talked about plans for landing the transit routing feature and we started doing some patch reviewing over some beers on Saturday evening.

Thanks to a lot of awesome reviewing work done by Jonas, this work has finally landed in master!

As always when merging such a long-living branch where I have been dwelling for about a year or so almost feels like saying farewell to an old friend.

Though, until we have sorted out some infrastructure for running OpenTripPlanner, you would have to use the debug environment variable OTP_BASE_URL (or modify the service file) as I have described in earlier blog posts.

Another feature that I intend to squeeze in before we release 3.24 is the ability to reverse routes. This is something that came up during Andreas' user interviews, one user had a use-case of going into town to meet up with friends and finding a suitable route home later in the evening. I realized our current UI is a bit awkward for this (even though you can drag and drop the entered places/addresses).

So with this new feature you get a handy button to reverse what you just searched for:


Searching for a route.


After clicking the reverse button (the up/down arrows)

Looking at one of trips

So, until next time, map along! :-)

Wednesday, February 1, 2017

Next stop: Brussels

On Friday I'm leaving for Brussels and FOSDEM!

Looking forward to be back again after missing out on last year´s incarnation and meeting familiar faces in real life once again, listening to interesting talks, both those relevant to work-related activities and personal interests, as well as general techie stuff, as I usually tend to end up at some “unexpected“ talk. Especially in the afternoon when getting a bit of fatigue and just staying around after the previous talk (which I had planned to attend) :-)

When it comes to Maps, I also have some good news. Just in time for FOSDEM I have managed to set up a temporary OpenTripPlanner server instance for the event so that people can test things out with the transit-routing branch.

The server has the base URL http://tricholoma dot update dot uu dot se:8080/otp

(replace dot with a . obviously, as I wanted to at least make it somewhat less likely for automated bots to generate extra load)

Beware that this server is not behind an HTTPS proxy (which should be the case for a real server, so that the user´s activity isn´t leaked to a potential third party).

As before, use the OTP_BASE_URL environment variable (or use a modified service file as described in an earlier post).
The server is currently loaded with transit data for the whole of Belgium.


A little screenshot showing a plausible trip from ULB to Grand Place after on Saturday afternoon.

And last, but not least I would like to thank my employer PrimeKey Solutions AB for sponsoring my trip and http://www.update.uu.se for kindly letting me run the demo server on their hardware.

Wednesday, December 21, 2016

Nearing end of year

So we're approaching the end of 2016, and I thought I should probably give a little update as it was a while since last time now…

As can be seen in the screenshot below, the route labels will be expanded a to fill out the available space instead of getting ellipsized when there is no headsign label, as is the case for the Staten Island Ferry in the example


I have also implemented support for printing the selected route (and since Andreas was a bit busy I went ahead and did some design work in a best-effort way):



We also changed the default color for routes (when the agency-provided data doesn't specify a color for a route) to black to be a bit more neutral (and match the default color of the route lines on the map.


Another new feature I implemented after an idea by Jonas is that now the transit route mode button is disabled if no route service is available. The idea is that we want to prepare for being able to land this feature in master and possibly enable the functionallity afterwards when we get infrastructure available (running OpenTripPlanner).
I implemented this by piggy-backing on the downloaded service definition we use for the tile server.
So, as soon as the service is available we can add a definition to the downloaded service file, and Maps clients will pick it up.
If you want to try this, and run your own local copy of OTP, you can copy the default service definition file from data/maps-service.json
and add the following JSON snippet:

"openTripPlanner": {
        "baseUrl": "http://localhost:8080/otp"
    }

at the end (before the closing } ).

Now you could run with something like:

MAPS_SERVICE=<path to modified service file> $PREFIX/bin/gnome-maps

You can also still use the OTP_BASE_URL override environment variable (as before) and it will also unconditionally enable the mode.

Hopefully we will be able to land it to master in a not-too-far distant future in time for 3.24.

And happy holidays everybody! :-)

Tuesday, September 27, 2016

Planning a trip

So, I promised an update on the transit routing a while back.
And as they say about dog food, and how you should eat your own…

Tomorrow I'm going on a conference, and what better way than to plan the trip using your own stuff :-)




Here I have entered the time a which I would at the latest want to arrive and entered the start and destination, so I've gotten some alternatives. Notice how now the trips are ordered by arrival time, and in reverse time order (so to speak). This was a behavior that one of Andreas' test panel persons commented on: ”This is different from Google, but I actually like it better this way!“.


I have now selected a trip that is among the fastest (and has fewer changes).


Clicking on the little expand reavler button on a leg of the trip shows the intermediate stops the train makes on the way. This is especially useful when your a bit unsure where to get off so that you can make a note of the stop just before (I well know this already in this case, though).

And clicking on the last section of walking to the destination will zoom in to this part of the map.
Now I used the export functionallity to save down the map view to my phone (currently there's a little bug in libchamplain where the path layers aren't exported along, but thankfully Marius have made a patch for it).

Speaking of exporting, since last time I have also made the print button only show up when selecting a particular trip.
However, currently the print layout implementation for this mode is only stubbed out and just shows a header with the start and destination names.
Hopefully Andreas' will get around to cook up some nice mockups for that soon, bearing the same good quality as the ones used for rendering the sidebar itinerary views.
This will also be useful, either to make an actual paper printout, or to export to i.e. PDF to view on a mobile device, for example.

And that's pretty much what has happened since the last blog post in June on this subject that comes to my mind.

Monday, September 12, 2016

Maps marching towards 3.22

Long time since the my last blog post, but here we go… 

So, I just rolled the 3.21.92 release of GNOME Maps. This is final beta release before the next stable (3.22.0).

The most noteworthy change will ofcourse be the new tile provider, replacing the discontinued MapQuest tiles, courtesy of Mapbox!
We have also backported this to prior stable versions to keep things working in current distribution releases, and for the future we will also have the ability to swich tile sources without patching release versions, as Maps now fetches a service definition file. And maybe (if time and effort permits) we might expand into the territory of client-side rendering of vector data, which opens up some possibilties, such as rendering various layers of interesting stuff such as a specific type of point-of-interests, like "show all restaurants in this area".

Another nice feature, thanks to Marius Stanciu's work in libchamlain, is that we can now render the map continously around the globe (at longitude 180°), thus we're no longer pretending there's an edge of the world, but rather aknowledge what Eratosthenes predicted around 200 BC :-)

Unfortunatly we will not see support for public transit routing for 3.22…
We still need somewhere and something to run our OpenTripPlanner instance on, and this summer getting basic tile service back on has ofcourse been prio one.

But stay tuned, and I will cook up a little status update of the stuff me and Andreas has been up to in this department too…

Thursday, June 16, 2016

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!

Wednesday, June 8, 2016

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.