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!