Wednesday, June 21, 2017

Midsommer Maps

So we just released the third development release of Maps in the 3.25 series (leading up to 3.26.0 in September).

Some new noteworthy new features and fixes made it in. We gained a couple of new keyboard shortcuts

Control and 1 and 2 to switch the view between street (the “ordinary” map) and aerial view (the shortcuts where inspired by Nautilus) and Control+o to open shape layers (we had a bug report suggesting adding this feature, which indicates it might not have been discoverable enough). Using the standard “open a file” shortcut makes sense, since that might be something you may try without thinking too much about it. And ofcourse it will also show up in the help overlay (as pictured above).

Furthermore, we now remember the mode of transport used for routing between runs, so it no longer reverts to car every time you start Maps (and it also uses the currently set mode when routing to a place from a marker bubble in the view).

Another annoying thing we've fixed is that we no longer reset the list of found itineraries when doing a transit route search and you click on “Load later alternatives” (or earlier) and no more results where found, instead we now show a notification and keep the previous results:

as can be seen in this screenshot showing results for a bus route which only runs on limited days.

We now also, thanks to work done by Robery Ancell, show religion information (for places of worship and book store for example) and information on the availability of toylets (when data is provided in OSM ofcourse). These can also be edited for POIs in OSM.

And it didn't stop there, after the release another feature implemented by Elias Entrup and Neha Yadav has landed. And that's that the search popover no longer just disappears when no results where found, but rather show an indication that nothing was found:

I also managed to do a little mess-up with the “remember the mode of transport” feature, so it was a little broken when currenly using transit and clicking the route button in a place “bubble”. So that has been fixed since in master.

And there was certainly some more things I have already forgotten :-)

Wednesday, May 10, 2017

Maps news

It´s been a while since the last post here, so I thought I should share some now.

3.24.2 was just released and right before the release a nasty crash-on-exit bug appeared. Actually, the bug has been in there ever since Maps gained the ability to show your contact´s addresses from GNOME Calendar/Evolution, but it was brought into daylight by the new version of GJS (our JavaScript engine, based on SpiderMonkey). The problem actually is that in the dispose vfunc of the ContactStore object (this is in our glue C code) we had forgotten to NULL out some pointer memebers when freeing the objects (with g_list_free and g_free) and dispose can be called multiple times and we probably got away before because GJS leaked these objects in the earlier versions. We got this bug report from Ubuntu by the way, in 17.04 the new version of GJS is already used. Thanks to Emmanuele Bassi for spotting this use-after-free bug, this is now fixed in the new version (and in master of course).

Other than this, things have been a bit calm lately. But I have some goodies as candidates for 3.26 functionallity.

The first I thought I should show involves using the Wikipedia tag data from OpenStreetMap and Wikimedia´s thumbnailing API to obtain thumbnails for the map bubbles shown for search results:

Another thing I have sometimes missed is keyboard shortcuts to switch between street and aerial view, so a couple of new shortcuts for that (I choose alt+1 and alt+2 to match the ones used in Nautilus to switch between icon and list mode):

And finally another idea we had before was being able to edit localized name variants in OpenStreetMap (this helps improving searchability for users in cases where the name of a place might differ a bit in different languages).

So, I modified the edit dialog a bit, so that instead of the delete button for the name field, there is now a “more stuff” button:

Clicking on it shows a page for editing variants of the name:

Here we have provisioning for giving an alternative name (such as a locally-known-as inofficial name for a place), older/historic names of places, and the name in the user´s language (I also added a static English name field, since the English name variant is often defacto used in OpenStreetMap as Romanized version in cases where the native name of a place is writtin in a non-latin script). This feature might need some designer feedback.

Another feature that might be cool that I have been thinking up a bit on is showing upcoming departures for public transit stops (and maybe nearby stops when using your current position). There is not yet any concrete implementation of anything here and this would also need some designer love.

And also, when speaking of transit, we´re still looking for options for hosting an OpenTripPlanner server instance (you still have to run your own and use either the service file override or using the debug environment variable), so if you happen to have some ideas here, it´s always welcome!

Tuesday, March 14, 2017

Approaching 3.24

So, we have just entered code freeze approaching the GNOME 3.24 release, which is scheduled for next week.
In Maps, I just released the final beta (3.23.92) tarball yesterday, but since I made a git mistake (shit happens), I had to push an additional tag, so if you want to check out the release using the tag (and not using a tarball), go for “v3.23.92-real”.
Right after the release I got some reports of Maps not working when running sandboxed from a Flatpak package. It seems that the GOA (GNOME Online Accounts) service is not reachable via dbus from inside the sandbox, and while this is something that should be fixed (for applications that needs this privilege when running sandboxed) we still shouldn't crash. Actually I think this might also affect people wanting to run Maps in a more minimalistic non-GNOME environment. So I have proposed a patch that should fix this issue, and hopefully we can get time to review this and get freeze exception for this as a last-minute fix.

Another thing I thought I should point out after reading the article on Phoronix after my last blog post about landing the transit routing feature, and I was perhaps a bit unclear on this, is that using the debug environment variable to specify the URL for an OpenTripPlanner server requires that you have an instance to point it to, such as running your own server or using a third-party server. We will not have the infrastructure in place for a GNOME-hosted server in time for the 3.24 release.

Looking ahead towards 3.26, I have some ideas both as proof-of-concept implementation and some thoughts, but more on that later!

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 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.