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! :-)

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.

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…

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.

News on public transit routing in GNOME Maps

So, this time there's not any fancy new screenshots to showcase…

I've been updating the otp-updater project adding support for storing a configuration so that the script could be run without pointing out the list of GTFS feeds and path to the OpenTripPlanner wrapper script (for re-generating graphs) straight from the command line.
I also added a little README and a sample configuration and feed list so that hopefully it should be a little easier, should someone want to try this out in conjunction with the https://git.gnome.org/browse/gnome-maps/log/?h=wip/mlundblad/transit-routing transit routing WIP branch.

Meanwhile, Andreas Nilsson has been busy making some user interviews and compiled a set of user stories.

https://wiki.gnome.org/Design/Apps/Maps/PublicTransportation/Interviews
https://wiki.gnome.org/Design/Apps/Maps/PublicTransportation

Looking forward to see some nice mockups to set my teeth into now :-)

A little update on transit routing in Maps

So, I thought it is high time for a little update about the transit routing project in gnome-maps (thought I should make some post while we're still in April).
I talked a bit with Mattias Bengtsson before, and since he had been contemplating using OpenTripPlanner (OTP) for his GSoC project a couple of year ago and found it didn't scale too well for general turn-based routing, he was quite excited about my idea of combing GraphHopper and OTP, using OTP with just transit data (loaded from GTFS feeds).

The basic idea here (when in transit mode) is to first run a query against OTP and as a further step do a ”refinement“ by re-running the parts of the routes where OTP selects walking between two transit locations.

An additional step has proven nessesary, since OTP, when running without OpenStreetMap ”street data” will approximate the walking ”legs“ of the trip as a straight line, which can be too optimistic in some instances. Therefore we do an extra safe-calculation to see if a particular itinerary seems reasonable with respect to time needed for walking (this is needed when there's walking in the middle of an itinerary, and there's an upcoming transit section that needs to be ”caught”).

Anyway, some screenshots:

Here we can see an itinerary where there's some walking in the start, it also tries to recalculate walking parts in the start and end by using the actual starting points as selected in the routing pane, instead of relying on the ones returned by OTP, which are based on the nearest transit stop.
The reason the transit part of trip (the solid line) is “jagged“ is that the data used here doesn't include shapes for the transit lines, so in this case OTP will interpolate with intermediate stops passed by in between.

A bit more beatiful routes can be obtained using data from the bus company serving the island of Honolulu:

Currenly it is hard-wired to always show the first returned trip. Also, as you can see it still doesn't render any intructions lists and the combobox to select departing/arrival time is not hooked up to anything yet.

As before the code can be found in the wip/mlundblad/transit-routing branch.

Also, there's some bug that sometimes gives a segmentation fault in Clutter (possibly there's some race condition in the code I rewrote to allow dynamically creating routing layers, to allow showing the dashed and solid lines interchangably). Unfortunatly debugging these things from JS is not all that fun…

Experimenting some more with map layers

One of the new nice features of Maps 3.20 is the ability of loading map layers in GeoJSON, KML, and GPX formats.
As I wrote about earlier, I have been experimenting with transit routing support. For that I have been using OpenTripPlanner, which has a notion of ”routers” (or “graphs“ as it could also be refered too) being discrete graphs consisting of nodes and connecting paths (such as transit routes) making up separate transit networks.
I thought it might be useful to get a visual picture of the sample data, so I got the idea of building a little tool that pulls the router information from a running OTP instance and generates a GeoJSON representation.

The code can be found here: https://github.com/mlundblad/otp-routers-to-geojson

This script, which by the way is my second case of using GJS as a scripting language, is rather simple and just takes as the one and only argument a URL to a running OTP instance (i.e. http://localhost:8080/otp when running a local server on your machine) and writes the output on stdout.

The script will skip any case where the graph's bounding polygon only consists of two points (not sure if that really would happen in reality).

Loading a generated layer into Maps can result in something like this:

The big diamond-shaped graph is probably the result of some malformed data, as that stems from the national transit feed from Estonia.

I hope you find this useful! :-)

View your tracks in Maps

Thought I should mention another nice feature that we have landed for 3.20, thanks to the nice work done by Hashem. Namely that you can now load GPX tracks recorded using i.e. a smart phone into Maps.

In the layers popover there is now a button to load geographical annotated data, it also supports loading geometries in GEO-Json format and KML (the format used in Google Earth).

This screenshot shows parts of a track recorded during a train trip (as you can see the track makes some jittery motions occasionally, but that is due to a bit shaky GPS reception).

Loaded layers shows up in the layers popover as shown below:

So now you can visualize trips and workout sessions directly in Maps. Also with shared-mime-info version 1.6 (which should be included in distros when shipping GNOME 3.20) double-clicking on a .gpx file should bring up Maps directly with the track loaded, as it registers itself as a mime handler for this mime-type.

The GPX track shown is awailable here https://cloud.gnome.org/index.php/s/G2YtwrveFo9RRjq
if you like something to play with.

A little teaser for future Maps

We've just entered the UI and string freeze for 3.20, we have a lot of new stuff coming up for Maps in 3.20 that I'm really excited about to see ”out the door”.

One thing that I've been wanting in Maps for a while is support for transit routing (for using public transportation options) in addition to our current ”turn-based” routing for car, bicycle, and walking powered by GraphHopper.

For a brief period in late summer took some time investigating the GTFS feed specification (for timetable data). The OpenTripPlanner project seemed rather fitting.

After a while of manually downloading some GTFS feed data and adding them to OTP's graph directory structure, I got a bit bored of that and wrote a little script to do the job https://github.com/mlundblad/otp-updater. It is quite crude and would probably need some better documentation (including a sample for the feed list configuration and such) and also currently requires quite a few command line parameters to point out the location for the OTP installation (used to run the graph rebuild command from there), these should probably be read from a global configuration by default…

Now, when things have calmed down a bit for 3.20 (and I wanted to try to keep main focus during my spare-time coding sessions getting the OpenStreetMap editing up to shape) I sat down and transformed the thoughts I've had in my head when it comes to integrating with an OTP server into a little proof-of-concept. The code is available in the https://git.gnome.org/browse/gnome-maps/log/?h=wip/mlundblad/transit-routing branch. The code is quite full of debug output code, is for the time being hard-wired to query an OTP instance running on localhost, and there's some duct tape here and there, but at least it does something…

OK, so enough of talking, now a little screenshot:

As you can here, there is now a new mode button to switch to transit mode. Currently, the only visible output is a raw debug dump of the JSON output from OTP. By the way, the blue route line shown in the screenshot is not actually from the transit routing, it's there since I first did the search using car mode and then switched to transit. And the reason it does a query also using the Estonian graph, seems to be some off coordinate in the data, I think.

I've also made a little list of feeds I've tried with here: https://wiki.gnome.org/Apps/Maps/Resources/GTFSFeeds

Running those feeds (plus a few more I had manually added before writing the updater script), the server takes around 7-8 GB RAM. So this would probably require a rather beefy machine to host the server.

Over and out for tonight! :-)

Maps shaping up for 3.20

So, we're soon approaching the UI freeze for GNOME 3.20. It's looking quite good when it comes to OpenStreetMap editing in Maps (among other things).

But first I thought I was going to show-case another improvement, namely the expanded place bubbles (show information about places you search for on the map).

This is what a place bubble will look like in 3.20 when you first open it, only the most basic information is visible, the name of the place, what it is (conveyed by the icon) and the street address. However if you click the ”more information button” (the dots), more stuff is revealed. Thanks Jonas for this!

Now we also show a link to the place's official website (if one is tagged in OSM, ofcourse) and likewise for the phone number (theoretically the phone number should turn into a clickable tel: URI link if you have an app installed that has registered a mime handler for that, but I didn't find have one, neither Empathy, Ekiga, or Skype seems to do it).

These fields are also possible to edit on OSM now, and if you copy a tel: URL from i.e. a web page, it would automagicall reformat it into the raw telephone number. Also note that the title of the editing dialog has been adjusted to better communicate the fact the changes are actually uploaded to the public OpenSteetMap database, and not stored locally or something like that. This was after user feedback we got after showing an earlier iteration.

If you click on the ”Add to OpenStreetMap” context menu item when not currently being zoomed in (right now to any of the two most zoomed-in levels), you get this notification with the option to zoom in to an appropriate level, centered on the position where you clicked.

Here we can see the POI type selection dialog, and this shows the types using the Swedish translation, so it probably looks like yibberish for a lot :-), but the reason I showed this is two-fold, first it shows how we get readily-translated names by parsing the data used by the iD web-based editor (thanks to Ole Laursen for that suggestion, by the way). Secondly, it shows a usage for another feature, namely how you can search for a value if happen to know the OSM tag used for that.

As you can see in the screenshot above, the ”hostel” tag value gets expanded to the title using the translation. Also, beneeth the search entry you can see the list of recently used types, selecting one of these will immediatly select that type and go back to the editing mode.

Here's how it looks when adding a new place, also this dialog title was adjusted to better reflect that stuff is added to the public OpenStreetMap database.

Before I forget, I should also mention the awesome work done by our Outreach participants.
Amisha Singla has been working on support for printing routes (with instructions) and Hashem Nasarat working on support for loading cust geojson map layers.

So, there's quite a lot of new features here. To those who regularily claim that ”GNOME just removes features in every new release” I would mention that Maps has grown by probably around 5000 LoC just for the OSM editing functionallity.

Borrowing POI types and translations from the iD OpenStreetMap editor

So, in a previos blog post I got comments from Ole Laursen and Zeeshan (zeenix) about why not fetching translations for location (POI) type names from the web-based OSM editor.
At first I was a bit sceptical, since our type concept will be a bit simplified (hiding the various tags that we consider as forming a ”POI type” under a single ”Type” selection).
But I got a little ”itch” for trying it out and managed to write a little script that mines this data from a git clone of iD and spits out a ”condensed“ JSON file with the type mappings with the translated names of tags.

And it works like this:

Editing an object with no type set currently, and it shows “None“ (as it would also do when creating a new location).

Clicking on the type button takes you to the type selection dialog. Start typing, and it will show matches (it should also fall back to matching the raw non-translated title if a translation for your current language is not added for a specific type, or there is no translation at all, as usual). As a little courtesy to nerdy OSM mappers, you can also type the name of a raw OSM tag value (such as ”bicyle_parking”) and it will show matches for this as well (this only works for tags that are included in the preset data from iD that are collected by the script though).

 

 

And selecting the type takes you back to the editor as before, with the type set to the one selected before.

Oh, and to be on the safe side, the type selector is only shown for existing objects if the type is already set to one of the defined types (and not for cases where there is a combination of tags, such as a place being defined as both an amenity and a shop, like say, a supermarket with a pharmacy department). This is done as a precausion to avoid any cases where tags would be overwritten in a non-obvious or hidden way. For objects where none of the type tags are defined, the selection will be permitted, and shows the initial ”None“ state.

A little helping hand when adding OpenStreetMap POIs

Since the last blog post I spent some time curing the ”amnesia“ of the POI type selection view. So, now it will show a list of (up to ten) most recently used types. And it will also save this list between runs.

Clicking one of the types in the list will select it and return to the editing view.
The list of available types is still very short and mostly interesting for testing purposes still. I might try to import some data from the iD editor. There is also some lookup code doing linear searching that might not scale so well, and possibly I might have to find a better solution for that, but I wanted to start out simple and not get lost in premature optimizations.

Another thing that will probably need some love is the search algorithm, currently it will only match the beginning of the type titles. While this probably works quite well for most cases in English, it might be awkward for languages with another word ordering, where for example different types of shops could start with the same string…

Add your local joint to the map

Add your local joint to the map

The last couple of weeks I've been busy implementing support for adding locations (POIs) to OpenStreetMap using GNOME Maps.

A new menu item for adding a location is added to the context menu, clicking it would show the account dialog if you havent already signed in, just as when editing an already existing location.

Otherwise (or after a successful log-in), the editing dialog on a new empty object will be shown:

By clicking the ”Type“ button, it is possible to choose the location´s type:

By starting to typing, suggestions for types will be shown.
It is currently a very limited set of object types that are supported. We will still want to keep it to a fixed set (rather than being able to edit the “raw” OSM tags) as we want to get localization support.

  

One thing that isn't currently yet implemented from the mockups is the recent types list, where recently used types should be available to choose from.

Another thing that I have been considering is allowing to edit the type of existing objects.
As the type concent that I have implemented here is a quite simplified variation of OSM´s free-form tag format, I had been a reluctant to this, but it might be feasable to allow it in case the object has just one of the various standard tags (amenity, shop, leisure, and so on) that we would base our type concept on set, and if that tag has a value that we have in our list (and thus can potentially show in a translated form, and even for the English or non-covered translation-case, not show lower-case-with-underscores form).

That was that for this time!

And 3.20 is starting to be visible on the horizon!