I liked Pete’s diary at the first sight. However, when published, I was already decided about my next work. Last Thursday I finally found some time to look closer at this interesting topic. I spent night working on it. And I will share the results in this diary.

First, I will not write about the HOT tasking manager. Second, these are my opinions. Third, understand damn in the following text as the shortcut of Divide and map. Now.

The summary of my understanding of the original diary follows. I’ll append my thoughts, though. I made a few toots during the night, which can serve to track the time effort.

What is TM?

Questions:

• What the TM is?
• What mapping process is?
• What is the origin of a project?
• What is the ownership of a project?
• For who is TM for?

Problems:

• New mappers don’t understand (because they don’t have answers.)
• New mapper edits frustrate old mappers.

Consequences:

• Discourage new mappers.
• Learning process interruption.

Thoughts:

The damn project has advantage here, because the name says exactly what the project does. Using areas, squares, and commits notation improves the clearness, too.

As there are multiple clients, each of them targets different group of mappers. Therefore, it’s easier to improve client for newbie mappers without limiting the experienced ones.

Each commit to the area is stored and shown when requested (statistics page,) improving the understanding of the area history.

Project creators

Original problem:

• When TM was opened, the data quality was low due to poor project description.

Solution:

• Onboarding process. Making sure that managers fulfill the expectations of having skills to:

  • engage local communities and contributors,
  • respond the questions and info requests,
  • ensure the documentation of the project is on the wiki (in the case of organised editing,)
  • ensure that standards are met,
  • ensure that the mappers are able to do what requested.

Problems:

• One manager for many many projects.
• Responsibility for the onboarding process.
• Onboarding process strenghtening.

Thoughts:

The original problem is interesting here. With the damn philosophy and the code of conduct in mind, the solution must be different.

The damn project supports mappers by creating/maintaining/inventing tools that mappers may use for keeping the quality. In the OpenStreetMap, anyone can make a change, see it, and fix it. In the damn project, anyone can make a commit to an area, see all the commits, and make another commit to change the area.

Areas of interest for beginners

Problem:

• Bad categorisation of the project.

Solution:

• Onboarding process (see above) forbids categorisation of urban environment as the project for beginners.

New problem:

• The solution works for one situation only.

Thoughts:

Allowing anyone (authenticated to OpenStreetMap) to change the area helps here. As any change to the area is commit itself, reverting the change is easy peasy.

Project documentation

Problem:

• Onboarding process does not emphasise the importance of the project documentation or link.

Thoughts:

The same as above. The openess helps here. The support should come only after the area is created. It’s similar to reviewers helping new mappers by saying “Hello, thanks for mapping, and by the way – please, square the buildings.”

The special case of changing the area is adding the translation of the area description. Since the beginning of the damn project, this particular case of changing the area is possible directly from the web client.

Unclosed projects

Problem:

• Inactive projects hangs around for a long time.

Consequences:

• Incomplete data in the project’s area.
• Issues for new projects with overlapping area.
• Hard to find people involved in the project.

Thoughts:

I solved the technical part of this issue by the abandoned_areas.py script (see https://git.sr.ht/~qeef/damn-client.py)

The example output of the script:

$ ./abandoned_areas.py https://server.damn-project.org
Areas abandoned on https://server.damn-project.org since 2020-12-29T20:55:21.
In last 90 days:
- 7114 has only 1 commits
- 2245 has only 1 commits
- 7100 has only 2 commits
- 7102 has only 2 commits
Finished.

Anyone can change the area and see the area creator, so sending the message saying “Hi, the area is quite old, with low contribution rate, so I’m going to archive it in a week. Feel free to re-activate or send the message back if you need to keep it active.” is simple.

TM projects can overlap

Problem:

• Not possible to check if projects’ areas overlap.

Consequence:

• Multiple projects used by different groups of mappers mapping the same area.

Thoughts:

This is my favorite one. I was looking forward solving this issue for almost three months. Solved by the intersecting_areas.py script (see https://git.sr.ht/~qeef/damn-client.py)

The example output of the script:

$ ./intersecting_areas.py https://server.damn-project.org
testing https://server.damn-project.org:
- 2229 intersects with 2253 of https://server.damn-project.org
- 2253 intersects with 2229 of https://server.damn-project.org

(Of course, this script works for multiple instances of the damn server, too.)

Feedback

Problem:

• Not easy, nor intuitive.

Thoughts:

There is Join discussion link at the bottom of each web client page. The link forwards to the mailing list, so feedback is as simple as sending new email.

From the statistics page, it’s possible to write an (OpenStreetMap) message to anyone involved in the area history.

Local mappers

Problem:

• Find local contributors within project’s area and interact with them.

Thoughts:

This is the third and the last technical issue I found. I solved it in the web client’s statistics page. Along with all commits and commits authors, it’s possible to get the list of local mappers – OpenStreetMap contributors that haven’t used Divide and map. Now. when mapping in the same area. The result of the overpass query that uses the convex hull of all the squares is compared with the list of commits authors.

[out:json];
(
    node(poly:"convex hull coordinates here");
    way(poly:"convex hull coordinates here");
    relation(poly:"convex hull coordinates here");
);
out meta;

Conclusion

When reading my toots to track the time, I spent 1.5 hour reading, summarizing, and understanding the original diary. This is not fair to say, as I read the diary many times since published.

I’m ok with spending 2 hours for each of the three technical issues. I spent more than 2 hours writing this diary.

The only thing I’m sorry about is that I’m three months late.