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.

Presenting a new little project

I have been playing around with the idea of implementing supporting public transportation routing in gnome-maps (in addition to the current support for car, bike, and pedestrian routing supplied by GraphHopper).
I thought OpenTripPlanner (OTP) seemed to be suitable for the task.
After looking at possibly using "GTFS manager" from geOps for downloading GTFS feeds, I found it didn't work quite as I had in mind (i.e. keeping the "zipped-up" incarnations of .zip files in its cache, while OTP builds its internal graph objects directly from the .zips), I took some inspiration of borrowed some code from it and came up with a new little project that I called "otp-updater": https://github.com/mlundblad/otp-updater

It can currently handle peeking at a standalone feed_info.txt (as is supplied by trafiklab.se) to avoid having to download the entire GTFS feed to see if there's been an update, it will also try to make an HTTP HEAD request to get a peek at the "last-modified" header of the feed, if that is supported by server.
Upon finding an updated GTFS feed, it will copy it to your OTP instance' repo and trigger a rebuild of the corresponding graph.

There is currently not much documentation (apart from the help text). Also the CSV parser should probably be made to handle # comments and some things like that. I might also add support for a global configuration file so that command line argument won't be nessary to use all time, and some things like that.

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.