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!

The light at the end of the tunnel

So, we are now approaching a quite useful state when it comes to OSM editing of POIs in GNOME Maps.
Since my last blog post in Novemeber we now have a working sign-up using OAuth 1.0a.

 Sign in with e-mail address and password

 A verification form will be shown (this differs from the OAuth 1.0 protocol used by JOSM, by the way, which does this using only the login name and password, but OAuth 1.0a is the recommended protocol to use for OSM, as I understand it there has been security issues with the 1.0 protocol).

After entering the correct verification code the account will be signed in:

And now, for the first time in my entire life, I've implemented a circular button (for the edit button) :-)

The rest of the editing UI looks just like before:

Worth noting is that just like in the mockups, if you click on the edit button without first having signed in, the account setup dialog will show up, and on successful log in will proceed to the editing dialog automatically.

There has been some hair-pulling during this phase for getting the OAuth negotiation going.
Furthermore OSM is using a REST API with PUT (and DELETE, but we don't currently support deleting objects) HTTP request with data in the request body of the HTTP message. As it turned out, librest (which we use now for doing OAuth-authenticated calls, doesn't support setting the response body directly.
Luckily there is an overridable virtual function for serializing the request in the RestProxyCall class, so it was possible to write a custom proxy call class inheriting OAuthProxyCall (which in turns inherits RestProxyCall, and handles the OAuth authorization headers) with a serialization function to upload the OSM objects. Thanks to Christophe Fergeau for pointing me in this direction by the way!

And ofcourse the OAuth access token and token secret are stored in the keyring (using libsecret, so I think it should work with other implementations, such as KDE's kwallet, but I have only tested against gnome-keyring).

So, we are in a pretty decent state for the upcoming 3.19.3 development release next week. Will probably add some additional editable fields.
I guess you could see this as an early christmas gift.

Oh, and by the way, the earlier work-around with giving the credential via environment variables is history now :-)

Started on OpenStreetMap account setup

The start of adding UI for configuring an OpenStreetMap account in gnome-maps

So, haven't shared any news in a month or so…
Have been kinda busy lately polishing up the code for the editing dialog and low-level code for dealing with OpenStreetMap objects.

But the last few days some new stuff has been cooking up.
There's now an embryo of the account setup dialog for signing in to an OSM account. It doesn't actually do anything real yet (like actually signing in… :-) ).

There's an application menu entry for opening up the accounts dialog (it doesn't yet trigger when trying to edit a POI without an account, as there's no support yet for storing account details, and so on…).

When invoking the menu, the dialog will appear:

Clicking on the "Don't have an account…" link will actually take you to the page for signing up for an OpenStreetMap account in your default browser.
Entering an email address and a password will enable clicking on "Sign In" button:

Clicking on "Sign In" will start the spinner and gray the input widgets out:

… which will actually go on forever, as it currently stands, as there is no furher processing done at the moment (well you can ofcourse still close the dialog…).

So, the next step will be to boldly go into the uncharted (for me) territories of OAuth negotiation and dealing with system keyring (for storing client credentials).

So, that's that for now folks…

A little update on OpenStreetMap editing in gnome-maps

Since my last blog post, the awesome Allan Day produced a nice mock-up of OpenStreetMap editing in Maps

So, the last few days I have spent some time to turn (parts of) this mock-up into GtkBuilder .ui files and JS code.
Currently, it handles editing existing objects (the functionallity is corresponding to my previous implementation doing the editing in-place in the place popover).

And a few screenshots of the editing:

Opening an object in the editor.

Adding a new OSM tag

Entering some data, and the ”Next” button becomes selectable.

Clicking ”Next” takes you to the upload stage.

Enter a (optional) change comment, and click ”Done” to upload the change.

There is still no account setting (like in the mock-up), so the ”hack” with setting the environment variables is still needed.
Also, the “Remove” button is currently not hooked up to anything…

The plan for the upcoming time is to clean out some left-overs from the previous ”in-popover“ editing I had before and the implement remove functionallity.
And after that take a look at adding the account setup functionallity.

And here comes a little preview of what's currently available in the wip/osm-edit branch of gnome-maps.

This shows some actual live updating of OSM data.

A small screencast showing the current state of OpenStreetMap editing in gnome-maps.

Note how pasting a wikipedia link automagically reformats the link to the OSM wikipedia tag format.

Also note how the stored place (the data shown in the popover for the place) is updated after a successful edit.
You still need to supply your OSM username and password via environments variables, as there is no settings UI for this yet.