Christmas Maps

So it's that time of the year again and about time for an end-of-year post.

Some news in Maps for the upcoming GNOME 42.

Finally, we have added support for running development versions of Maps (such as from the Nightly Flatpak repo) in parallel with the stable ones

The develop one is distinguished by the “cogwheel” background in the headerbar, and also by it's ”bio-hazard” strip icon as seen above.

Also we've had an old feature request laying around about supporting a command-line option to initiate a search.

In the meantime in Evolution there was discussions about being able to launch a search using a configured map application, rather than just using the OpenStreetMap web-based search. In that issue it was suggested there is a draft maps: URI scheme that has been used by Apple Maps on iOS.

So I have implemented this is Maps, so that Maps will now register as a mime-handler for the maps: URI scheme. And you can then open URIs of the form something like:

maps:q=search%20query

This could be tested from the command line using the gio command

$ gio open maps:q=search%20query

 

I also took the opportunity to add a DBus action to perform search.

This can be tested using a command-line like the following:

$ gdbus call --session --dest org.gnome.Maps.Devel --object-path /org/gnome/Maps/Devel --method org.freedesktop.Application.ActivateAction 'search' "[<'search query'>]" "{}"

 or by using the d-feet DBus debugger

 (and even though the output states no return, Maps will actually launch, or activate the currently running instance with the search performed).

And I also implemented an old-school command-line argument -S with the same semantic (taking the search query as it's argument) as per the original feature request.

These will either show the search popover in Maps when there are multiple search results, or just open the place bubble with the place selected when the search was specific enough to have a single result (such as when searching for a contact's address).

 Furthermore, as a little refinement the routing instructions for turn-by-turn based modes now also makes use of the u-turn icons:

 There was also a corner-case bug introduced by me when refactoring the instruction types to decouple them the GraphHopper-specific codes, resulting in a bug in some cases with u-turns preventing the route to show up. This was spotted, and fixed by one of our newcomer contributors Marina Billes.

One thing missing when it comes to the instruction icons by the way is that we miss icons for “keep left” and “keep right”. So I've created an issue for that (https://gitlab.gnome.org/GNOME/gnome-maps/-/issues/410). (I first gave Inkscape a go, but I quickly realized icons attempt to draw looks more like deformed sausages :-) ).

 

Another thing that's been on my mind for a while is the default zoom levels we use when “going to” a place when selecting a search result. Currently we find a suitable zoom level based on the so called bounding box of a feature (when it's available in the result item). This means things like buildings and parks can usually be shown initially so that it fits in the present window. For other object that are mere nodes (just a pair of coordinates), we have used some presets based on the place types as defined by the geocode-glib library. But these are quite limited and only covers a few cases.

So I started playing with a WiP branch to select more fine-grained default zoom levels for more place types with a heuristic based on the types we get from the OSM data.

This way, e.g. the continents (which are represented in OSM as nodes) gets a better fit, and not just defaults to a fully zoomed-in (as a fallback) place somewhere in a rural area or such:

 

And also a few more distinct levels for different place “sizes”, such as hamlets so we don't have to resort to a “one size fits” all level more suitable for larger towns and cities:

 

And I guess that will wrap it up for this time!

Happy Holidays everyone!