HOT Tasking Manager (TM), SimpleTaskManager (STM), and Divide and map. Now. (damn) are tools for collaborative mapping, with different philosophies and different approaches. In this diary, I discuss some issues of the first two from the perspective of the third one.

DISCLAIMER: I’m the damn project developer.

Which issues to consider: I filter out bug reports and issues that oppose the damn project philosophy. Then, I pick up issues I think are interesting and categorize them, describe the category, and provide some comments how the particular issues are or would be solved.

About naming: TM’s and STM’s project corresponds to damn’s area. TM’s and STM’s task corresponds to damn’s square. Where TM uses validation, damn uses review.

Solved by design

There are many issues of both managers that wouldn’t be an issues for the damn project because of it’s design. Let’s quickly recap that design.

There are areas divided to squares. Any change to an area is stored as commit. So, creating new area leads to creating new squares as well as new commit with to map type for each square. During collaborative mapping, new commits of different types like locked or done are added with area and square identifiers, always updating particular square of the area. It’s not possible to delete something.

Already implemented

Some functionality requested is already implemented in the damn project, or the problem described has different solution.

  • STM: Allow custom Changeset comment – the changeset comment can be set in the manager (web) client when creating new area and updated afterwards.

  • STM: JOSM: Download data based on task geometry – the square’s GPX boundary as well as OpenStreetMap data are downloaded automatically when using JOSM damn plugin.

  • STM: Notice to be responsible while mapping a task – there is notice on each area’s page of the light (web) client just before the I will map … and I will review … links.

  • STM: Create sub-tasks to specify which part of a task is done – splitting a square creates four new squares with borders dividing the original one. New commits with to map type are added for new squares and new commit with splitted type is added for the original square.

  • STM: Chat within project – there was chat in web client, then I dropped it during the refactoring, and finally re-added it again. It’s not much, it’s mainly for demonstration, but it works.

  • STM: Feature: GeometoryCollection – (multi)polygons, linestrings, or points are allowed geometries for features in a FeatureCollection of an area being created. From each feature new square is created.

  • TM: Feature Request - Remember sort oder on tasks screen – the use-case is to help validators who validate the ‘Least recently updated’ squares. The damn project uses locking policies to solve the original issue–it’s possible to request reviewing of recent, oldest, random, nearest, or newbie square.

  • TM: Filter Tasks by Username to Include All Users - Not Just Most Recent Mappers – on the area’s statistics page, it’s possible to see all the commits, i.e. all the changes to the area and all it’s squares. It’s possible to filter all the commits of a mapper or all the commits of a square.

  • TM: Add active and stale filter options to Manage Projects page – for this purpose, the Python script of the is used.

  • TM: Allow logged in users to create tasks without intervention – it’s the way to create areas according to the damn project philosophy.

  • TM: Define a setup to execute periodic functions – it’s the upkeep of the damn-deploy.

  • TM: undo undue split – it’s not possible to undo something in the damn project, but this issues has the solution. The issue, from the damn project perspective, is that a mapper splits the square, i.e. creates four new squares, a commit with to map type for each of the new squares, and new commit with splitted type for the original square. Then, splits one of the new squares again, i.e. creates four new squares, a commit with to map type for each of the new squares, and new commit with splitted type for the parent square. So the result is seven to map commits. In the mappy (web) client, it’s possible to merge squares, i.e. from the seven splitted squares create new square with the same boundary as the original square has, corresponding commit with to map type for that square, and seven commits with merged type for the seven splitted squares.

  • TM: Track Split Tasks – showing all commits or square’s commits on the statistics page of an area does the trick.

  • TM: RSS feed of projects – see

  • TM: Submit task and jump right next to another one – with JOSM damn plugin, there is no need for opening the web browser (except for authentication for the first time.)

  • TM: Let mappers translate project description – this is my issue, contributing an idea to the HOT Tasking Manager. Translating the description by mappers is implemented in the light (web) client since the beginning.

  • TM: Improve integration with AI-assisted mapping – in a web client, iD and RapiD can be switched. On the own instance, the default editor can be set.

Boring (client) stuff the server is ready for

The server’s API is ready for a lot of things clients don’t do, because I’m not a frontend developer, nor enjoying work on the clients. The following issues could be solved easily, because it’s possible to download all the commits of an area and all the information is within these commits.

An example what is done in the web client: area’s statistics page shows hours left when mapping or reviewing the same speed as in the last hour/3 hours/day/week/overall.

Some ideas to get inspired

As mentioned in the beginning, I filter out bug reports, issues that oppose the damn project philosophy, and even more. Therefore, the issues listed in this diary is not–and is not meant to be–complete. However, it’s nice to get inspired. There are some interesting ideas in the both managers I get inspired by:

Login to leave a comment