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.
The damn project has advantage here, because the name says exactly what the
project does. Using areas, squares, and commits notation improves the
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.
Onboarding process. Making sure that managers fulfill the expectations of
having skills to:
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.
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.
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.
I solved the technical part of this issue by the abandoned_areas.py script
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
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.
This is my favorite one. I was looking forward solving this issue for almost
three months. Solved by the intersecting_areas.py script (see
$ ./intersecting_areas.py 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.)
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.
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.
node(poly:"convex hull coordinates here");
way(poly:"convex hull coordinates here");
relation(poly:"convex hull coordinates here");
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.