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
done are added with area and square identifiers, always updating particular square of the area. It’s not possible to delete something.
STM: Task change history – these are commits exactly.
TM: Update total task count on task deletion – it’s not possible to delete any square or commit. Deleting square would mean to add commit of
deletedtype for related square. Then, count squares with the last commit different from the
TM: Improve task lock error handling on frontend – if a mapper tries to lock a square (e.g. for mapping,) a client requests server (e.g.
map random,) which performs atomic database query for all the area’s squares with the last commit that is not
locked(e.g. with type
to map,) and in the same atomic database query adds new
lockedcommit for the square. Described error is not possible in the damn project.
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
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 maptype are added for new squares and new commit with
splittedtype 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
FeatureCollectionof 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
abandoned_areas.pyPython script of the damn-client.py 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: 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 maptype for each of the new squares, and new commit with
splittedtype for the original square. Then, splits one of the new squares again, i.e. creates four new squares, a commit with
to maptype for each of the new squares, and new commit with
splittedtype for the parent square. So the result is seven
to mapcommits. 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 maptype for that square, and seven commits with
mergedtype 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: Submit task and jump right next to another one – with JOSM
damnplugin, 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:
TM: Validation enhancement to step thru selected tasks individually – an idea for a client–probably JOSM
damnplugin–enhancement. The server is ready for this kind of feature requests.