Welcome to the summary of work done in the fourth year of Divide and map. Now. – the damn project that helps mappers by dividing a big area into smaller squares that people can map together.
Four years ago, the damn project was developed to constructively criticize the HOT Tasking Manager. (HOT stands for the Humanitarian OpenStreetMap Team.) I see that the limitations of the HOT Tasking Manager persist, that it is not getting better, and that the developers of the HOT Tasking Manager can still benefit from constructive criticism.
In this diary, I will first recap the functionality and scope of the damn project. Then I will write about the work in 2023 and the work for 2024.
Functionality and scope
To understand the damn project, let us break it down into four main components, each of which has its own repository: the server, the web clients, the JOSM damn plugin, and the deployment guide. The deployment (for sysadmins) brings up the damn project. The damn server (for backend developers) contains the core service – JSON API to the PostGIS database. The JOSM damn plugin connects to the damn server so that mappers do not have to open the web browser to contribute to OpenStreetMap when using the damn project. Finally, the web clients repository (for frontend developers) contains the code base for multiple web clients.
The features available to mappers are divided into the JOSM damn plugin and the web clients, as the damn project serves multiple groups of mappers and recognizes these groups.
Novice mappers use the mapper client, which allows them to map some square. They can choose between the random, newest, oldest or nearest (to last) square of the area they are mapping. A lightweight web client for somewhat advanced beginners is the mapper’s panel – a slim web page that appears on the right side of the monitor and pops up the iD editor on the rest of the monitor. When using map-review-done square state transitions, it is not possible to review squares using mapper clients.
Reviewers, experienced mappers who care about quality, will use the JOSM damn plugin in most cases. They can map or review (random, newest, oldest and nearest) squares. There is also the option to review newbie squares, but to enable this workflow, beginners must identify themselves in the mapper client. Next, reviewers can review the work of a particular mapper by requesting a (random, newest, oldest and nearest) square of that mapper (to map or review). Also, the JOSM damn plugin can automatically download notes, which is meant for notathons.
If JOSM is not an option, there’s the panel client – a lightweight web client for experienced mappers that can do almost everything the JOSM damn plugin can do. It also allows mappers to use a wide range of editors, including mobile editors like Vespucci, for field mapping.
Finally, area managers use manager client to create and update areas. They also use mappy client to view the area on the map and prepare the area for mapping – for example, to split or merge squares. Area managers can also use the intersecting areas website and track their areas with RSS, which can be connected to the fediverse.
This is the summary of the functionality of the damn project, which enables multiple square’s state transitions and different mapping workflows, highlighting the needs of specific groups of mappers.
Divide and map. Now. is a collaborative mapping tool. Our goal is to develop the best collaborative mapping tool, but nothing more.
It is not possible to create campaigns in the damn project, as there are already established guidelines for organized editing campaigns in OpenStreetMap. We recommend following the guidelines for organized editing and using permanent links to the areas that are part of the campaign.
It is not possible to send messages to other mappers via the damn project. It is always better to use the existing infrastructure. So use direct OpenStreetMap messages or changeset discussions to notify a mapper.
It’s not possible to create groups in the damn project, but there’s the OpenStreetMap user groups wiki where we can get inspired.
Work in 2023
What has happened in 2023?
First of all, we have finished refactoring the damn deploy. The instructions are simpler and clearer. The subdomains has better names. There is a new www template. The web clients can now be rebuilt faster. Docker containers no longer need to be restarted after the web clients have been rebuilt. It is simpler to install systemd services. And it has been proven again to be performant; proven by load testing.
There are some new API endpoints of the damn server and by default the list of commits or squares returns a maximum of 1024 items. These changes were necessary to support large areas, i.e. areas with 300 000 squares.
We have unified the code base of the web clients, all web clients now use a common repository. We have also added a permanent link for areas, which can be used for example in the changeset comments. When the area is finished and made read-only, the area identifier will be used for another area in the future. Therefore, it is better to use the permanent link in cases where a permanent link is expected.
There have been minor improvements to the JOSM damn plugin. We have added an option to load multiple imageries, including WMS ones, a button to manually lock squares and we now use JOSM’s Transifex for translations.
It’s not much, but the steady improvement is obvious.
Work for 2024
And what about the work for 2024?
OAuth 1.0a will be obsolete at some point in the future. No need to rush, but it will happen. We see this as an opportunity to rethink our approach. Currently, the damn server uses OAuth 1.0a for OpenStreetMap and sends a JWT to the (damn) client upon successful authorization. We are thinking about offloading authentication to another service so that the damn server really only serves one purpose. It would also be nice to have access to the OpenStreetMap messaging API from the damn clients so that mappers can discuss using changeset discussions. We still need to think about that.
Another challenge is large areas and detailed geometries (of squares). The load testing was performed for average areas with up to 1024 rectangular squares, which is the default (maximum number and shape) of squares that the damn project uses when creating new areas. We need to prove that large areas and detailed geometries work for the damn project or limit their creation. For example, loading the intersecting areas web page now takes up to 20 seconds! That’s not good!
A lower priority is the integration of the creation of background map images into the damn_upkeep of the damn server and the never-ending work on JavaScript web clients.
And finally – the last, the best, the most important – we listen to the ideas of the mappers. The issues raised by the community are always a priority for us. However, we are not so much interested in feature requests. We are interested in the problems that mappers have when using their workflow and we do our best to solve these problems and implement the workflows.