Monday, March 15, 2021

Maps and GNOME 40

 As we have just pushed out the release-candidate before the GNOME 40 release next week I thought it would be appropriate with a little summary of the news for 40.

The first big visual update this cycle has been the new updated “place bubbles” redesign by James Westman:

 


This has already been covered in earlier postings, but still earns mentioning when summing up.

I also made some tuning to the way we present the information for places. The title will now show the place' name in the user's language, when that is available in the OpenStreetMap data. Also it will show the place' native name, as locally written, when they differ:


The other big update has been further improvements of the interface' adaptiveness for mobile (narrower) displays, also by James. When selecting a place marker from a search result when in mobile mode, instead of showing the popover style we use for desktop, a ”place bar” at the bottom now appears:

And when clicking/tapping on this bar, a dialog (which will fill the entire space on smaller displays) appears:

Though not yet used by Maps, there's also been a lot of progress made on the new map rendering library libshumate, based on GTK 4 that is set to replace libchamplain and which will let us move away from depending on Clutter and thus also allow migrating from GTK 3.

James Westman and Georges Basile Stavracas Neto. The demos accompanying the library has been consolidated into a single demo application and also gained a Flatpak manifest, which means the demo can be run directly from the GNOME Builder IDE, allowing to “run” the library direcly when making changes. Georges also implemented so called ”kinetic scrolling” (meaning the view has keeps some inertia when you give it a ”push”, which greatly improves the feeling of smoothness as it doesn't stop abruptly, moving one step further towards providing a matched look-and-feel to what we currently have with libchamplain.

 


James also implemented a test tile source, which can be showcased using the drop-down menu in the demo app. This test source shows the background tile indexes (the TMS tile coordinates, https://wiki.openstreetmap.org/wiki/TMS ) which can be handy for debugging, as well as serves as an example of writing a custom tile source implementation.

 

And as always, stay tuned for coming updates on the progress towards GNOME 41 and other stuff coming!

Cheers!

 

 

Sunday, February 28, 2021

Excursions: Driving on the wrong side

I think it's about time for the next installment in the Excursions series.

One area I was always interested in this a long time back has been transportation-related infrastructure like roads and rail. And a fact that comes up quite naturally along that is the “sidedness” of traffic in different countries. Today a majority makes use of right-hand traffic, but this has changed over the cause of time. It is sometimes said the prevalence of right-hand traffic in Europe (and the Western world in general) is related to Napoleon and him wanted to keep England “at arms length”. This seems to quite disputed though…

But rather that going through various countries handedness here. I thought we should look at something more interesting and quirky. Because as it turns out, it's not always the case that the standard is entirely the same within a single country.

For the first example we could take the United States. Driving on the right, right?

Well, mostly, but there's an exception as it turns out:

The territory The US Virgin Islands is actually left-hand traffic.

Wikipedia 

https://openstreetmap.org/relation/286898

Here we can see a map view of the capital city Charlotte Amalie, and on the follow view we can clearly see LHT on a dual carriageway street:


And talking about the United Kingdom (LHT, and remember the Napoleon remarks…). Despite being a well-known LHT example, especially in a European context, there's a part of the UK practicing RHT. Namely Gibraltar:

Always sharing land border with Spain this was more practical it seems…

Another quirky feature in Gibraltar is the level-crossing with the runway on the airport on the main road (connecting with Spain) Winston Churchill Avenue (Wikipedia)

It has crossing gates and lights, pretty much like on a railroad crossing… except when it's ringing, a Boeing 737 might zip by…


Next we go east to Hong Kong. Under British influence Hong Kong practiced left-hand trafic. And this has been kept also after 1997. Thus on the borders to mainland China contraptions like these can be seen to facilitate switching sides:


And not far from there we have a similar situation in Macao. When Macao was a Portuguese colony from the 16th century until 1999. And while Portugal itself switched from LHT to RHT in 1928, in Macao LHT continued, and it has been retained. A similar “trafic carousel“ as in the Hong Kong case can be seen at the mainland side of the Lótus Bridge (Wikipedia).


On the more quirky historical case is a road near the lake Björkvattnet (geo:64.608587,13.700729;crs=wgs84;u=0) in Jämtland in Sweden. While Sweden was LHT until 1967, neighboring Norway had been practicing RHT since a long time before. So when a new road was built between Kvelia and Tunnsjø (in Norway), the shortest and most conveniant option was to build the road for a stretch through Sweden. But imposing left-hand trafic on this single and at the time not connected to other roads in Sweden seemed inconvenient. So this road (and residents living there) was just practising RHT. And the only connections where through Norway anyway (the Z822 road leading to Gäddede and connecting to the rest of the Swedish road network was not built until some time after 1967, I think I read some discussions on this and when the roads where built at some forum, but I can't find those again…).


And also speaking of quirks, we also have the Punte Umberto I bridge in Rome https://openstreetmap.org/relation/5679034

Wikipedia 

The bridge itself is actually LHT (fortunately, maybe, there's a median fence).

And while speaking of countries switch sides, it seems historically it's been most common switching from LHT to RHT. But there's case of the opposite as well. After WWII Okinawa was occupied by the United States and RHT was practiced there, but in 1978 (six years after control of the islands was returned to Japan) they switched back to LHT.

https://openstreetmap.org/relation/4556086

Arguably this could be seen more as a case of reverting back to how it was before and getting back to the standards in the rest of the country. But still a bit interesting, I think.

And there is actually plans for a country as a whole to switch from RHT to LHT. And this is in Rwanda. The motivation would be that neighboring countries are predominantly LHT, so besides benefits of being similar to neighbors, prices of used vehicles with the steering wheel on the right side are generally lower.

 

Here's a map view from the capital Kigali:

https://openstreetmap.org/node/60485579

 

And by the way, if you use GNOME Maps, you can paste the openstreetmap.org URLs and geo: URIs directly into the search bar to go to these places.

 

So, let's see what we should explore next time!

Tuesday, December 22, 2020

Christmas Maps

 So, it's that time of year again. And even if this year is a lot different than usual in many ways I thought we should still follow the tradition of summing up some of the last updates to GNOME Maps in 2020 (and before the first beta of what will be part of GNOME 40, in the new versioning scheme).

The biggest change that was landed since the release of 3.38 has been the redesigned ”place bubbles” by James Westman. James has already written an excellent blog post highlighting this. But I still want point this out here as well. The bubbles now feature larger thumbnails with images from Wikipedia when places are tagged with Wikipedia articles in OpenStreetMap (and the article features a title image), utilizing the MediaWiki API. This feature has been present for some time, but with the redesign the thumbnail are larger and has a more balanced and prominent place. Furthermore a short summary of the Wikipedia article is also shown (in the language preferred by the user's locale settings, if the article is translated to that language in Wikipedia). The details are also shown in a nicer list view-style with icons to give visual cues.


And this is not all there is to it either. James has been starting work on making these adaptive so they can adjust to smaller (narrower) screen sizes, such as on phones:


This is something we hope to finish up in time for GNOME 40.


James also implemented better handling for cases where website URLs are malformed in OSM (such as one missing the proptocol, e.g. https:// or http://), skipping showing the link instead of presenting a link which will not work. Along with this the dialog for editing places in OSM will highlight a malformed website field (and the code has provisioning for adding other validators further on, e.g. for phone numbers).



Another thing that had bothered me a bit lately is how we render opening hours. Before we displayed them in a single line:


As can be seen here the line wrapping happens in a very awkward place right between a day and it's time interval.

So I took the opportunity now that we have the list with separators to do some restructuring rendering it a grid to get a cleaner look:


I also re-implemented the rendering of times using the localization API from EcmaScript (JS) that we get via GJS. For example this is how it would look in Persian:

Also since the last time we've had some new contributors. Ravi Shankar improved the detection of invalid URLs and Anubhav Tyagi has improved loading of shape layer files (GeoJSON, GPX, and KML) by replacing synchronous file I/O with asynchronous while loading and also an update to show a dialog asking the user for confirmation when loading files larger than 20 MB since it can takes some time to load (and parse).

And last, but not least, Maps old-timer Jonas Danielsson contributed a fix to normalize phone numbers in the links shown for phone number when an app is installed that can handle tel: URIs. This allows the Calls app on e.g. the PinePhone to use these links directly from Maps.

I think that was pretty much it for now!

And until next time, happy holidays and merry Christmas!

Tuesday, November 10, 2020

Excursions: The Seven Bridges of Königsberg


Making a little test with a new kind of blog post format where I explore some interesting fact related to geography and some history and fact around it.

For this first one I was going to take a look at the mathematical problem involving the bridges of Königsberg (present day Kaliningrad).

I have an old mathematical chart that I got from my father:



 
I used to study this a lot growing up and I recently was a bit curious as to when it was actually issued. The chart was issued by a company called Original-Odhner (https://sv.wikipedia.org/wiki/Original-Odhner, there is no English article in Wikipedia for it…) and doing some more research I found a mention of this chart in an old issue of a technical magazine called “Teknisk Tidskrift” from 1959 (http://runeberg.org/tektid/1959/0026.html) where the chart is mentioned as being recently published, so that should put it around 1959, or perhaps 1958.
 
In any case, up near the top left corner there is a description of this topological problem outlined above:
 

  So, the subject of this post is the problem with the seven bridges of Königsberg in what was back in Leonard Euler's days in the 18th century Prussia (nowadays Kaliningrad, today a Russian enclave surrounded by Lithuania and Poland). In those days the two islands of city was connected by seven bridges and a common passtime of the recidents was to try to come up with a way of performing a walk crossing all the bridges, but only cross each bridge of time (https://en.wikipedia.org/wiki/Seven_Bridges_of_K%C3%B6nigsberg)
 
Euler managed to prove in 1736 that this is a mathematically impossible problem. Part of the solution involved the abstraction of the problem into one of a pure graph. Thus ignoring the choice of paths in areas on land and the islands, between the bridges. Being irrelevant (for the solution of this specific problem). And this is a very important observation. The same principle applies for the algorithms we use today for finding shortest or quickest routes. By treating the way segments as edges in a graph with weights (corresponding to e.g. distance, time required, or other significant parameters ranking preferred characteristics) ignoring things like the actual bends and twists between each intersection where a choice of direction needs to be taken.
 
To conclude this, we could take a virtual excursion to present-day Kaliningrad.
 

  The central island that the town center in Euler's days, is now a park (it was devastated during WWII)


Of the original seven bridges of the old puzzel, five remain in their position today (only two seems to be the original ones from 1736). And incidentally one can actually make an equivalent walk today, using the present day bridges.


Hope you liked this form of post, and maybe somebody has ideas for other places and stories to explore!

Sunday, October 18, 2020

Maps in GNOME 3.38

 It's been a while since the last blog post and it's been a while since 3.38.0 was released, and in fact there was already the stable on-schedule 3.38.1 release. On top of that a sneaky asynchronous programming bug showed up that in some circumstances such as high-latency connections, or fast typing can give out-of-sync search results I cut an extra 3.38.1.1 patch release.

But now to the summary of the 3.38 user-facing changes. I think all of this has been covered in previous posts, but I guess it's always nice with a bit of a summary.

For one thing, we now have a night mode, utilizing Mapbox' dark tile set:

 





Another feature that had been requested for quite some times was hybrid aerial mode (showing labels for street names, names of places and so on):


And thanks to work by James Westman the first step towards an adaptive UI (for e.g. smaller screen scenarios) has been implemented where a bottom action bar appears “taking over” some of the buttons from the header bar, leaving the search entry and main menu in narrow mode.

And video of the feature in real life says more than pictures here:


We had also planned to make the routing sidebar adaptive for 3.38, enabling it to take over the view (with a back button, as in other similar phone-enabled UIs) when in narrow mode, by utilizing the adaptive widgets from libhandy. But unfortunately some issues showed up under Wayland with some graphics driver (related to Clutter), so we had to roll back this before the release.

And stay tuned for updates on upcoming stuff for GNOME 40!

Wednesday, July 1, 2020

Summer Maps

Since it's been a while since the last post, I thought I should share a little update about some going ons with Maps.

There's now a new night mode, utilizing Mapbox' dark street tile set:











































Another thing that has been requested from time to time is showing labels on the satellite mode (“hybrid” aerial). Originally the plan was more along the line of rendering vector tile data on the client-side and have this rendered as a separate layer on top of the regular “vanilla” aerial tile set. But since vector tile support has not materialized yet, another idea has been to take advantage of Mapbox' hybrid raster tiles (”satellite-streets” as they call them). So I decided to implement that, to finally have this feature:

 So, when selecting the aerial view, a checkbox appears allowing to switch on the hybrid mode.

Another thing I have missed for a while was having some sort of regression testing, e.g. some form of unit tests. I decided to roll a custom quite simplistic solution consisting of a small bit of Meson “code” to dynamically build launch scripts invoking GJS on each of a set of .js files and have the Meson test clause execute them, as can be seen here: https://gitlab.gnome.org/GNOME/gnome-maps/-/tree/master/tests.
It currently only have a few test cases, but it's a start, I guess :-)

Furthermore I took some time to make the rendering of various places where numbers and times are shown to use the locale-depending formatting functionallity in ES (JavaScript) to get rid of some remaining places that still used hard-coded %d-like format strings, resulting in always using western-style digits, as can be seen in the following after this, using a Persian (فارسی) locale:


But, maybe we should keep the most most exiting thing til last… a little over a year ago I started a new project (libshumate) with the intention of trying to build a GTK 4 implementation of a libchamplain-like API for rendering map tiles (and markers and such). Lately Corentin Noël (tintou) took up the ball and has managed to get up to a state where it's working enough to actual display stuff (and scroll and zoom around):

This is the simple “launcher” demo from within the project, actually displaying a map in a GTK 4 world.
And since everything is GTK widget, you can use the GTK Inspector to look around at the internals for testing/debugging:

And “everything is a widget”, like the actual tiles, so you can for example toggle off visibility of a single map tile, since it's just a regular GTK widget, like so:


I'm very impressed with Corentin's work!
It's very exiting, I think it's at a point where it should probably be possible to do WiP work using in Maps (but for now probably with only barebones rendering of actual map view working).

Sunday, March 29, 2020

Maps in GNOME 3.36

There's been quite a while since the last blog post. Since then 3.36.0 was released, and also the first update for the stable 3.36 branch, 3.36.1 has been released.
As I've written about before one of the main features in 3.36 is the support for trip planning for public transit using third party services, as shown here from Paris:


We also support a few other areas for now, such as TriMet in Portland, Sweden (using the Resrobot API), and the Switzerland using the opendata.ch API. A full list is available on a sub page to https://live.gnome.org/Apps/Maps

Another feature implemented by James Westman is that the current location marker should no longer flicker when you have live-updating (e.g. when you have an actual GPS receiver on your device).

James has also implemented the first step towards a responsive UI that can scale to phone and narrow tablet portrait displays, this was finished after the UI change freeze before 3.36, so it will have to wait until 3.38


Oh and another thing, in these times when physical traveling is not an option browsing around in Maps application is another way to explore. And don't forget take advantage of the interlinking with Wikipedia from the OpenStreetMap database (Maps will show a link to a Wikipedia article for a place if available when you press the “Show more“ three-dots icon in a place info bubble). And if it's missing you can always add it yourself.

Be safe everyone!