The damn project helps mappers by dividing some big area into smaller squares that a human can map. This diary is about the work done in the third year since the publication.

And, to be honest, not much has been done. I had a little of time this year. Still, there are some interesting improvements.

Deployment and server

I will start with probably the most boring stuff: I worked on the documentation and tests. That is thankless work, but I believe it pays off in the longer term. In short – 35 files changed, 1675 insertions(+), 842 deletions(-) and you, as mapper, should not see the difference before/after.

In parallel, I worked on the refactoring deploy. I have moved some upkeep procedures already and I will slowly continue the work.

Notathons

The most motivating for me, I think, is a feedback with a request like “hey, we are working on this and we need that”. This time it was from guys organizing notathons. We improved the damn plugin for JOSM to download notes automatically and periodically. Also, when using the plugin, the changeset comment is (finally!) automatically set based on the area information.

Get inspired by issues of similar projects

I wrote already about damn project point of view on some issues. From that diary, I think that this issue is solved by option to Review newbie, or Map or review work of other mappers workflow.

Because there are not many issues with the damn project (I do not complain!) I sometimes look up interesting issues somewhere else. So, what is there?

First two here and here deal with locking of multiple tasks (squares in damn) for mapping or validation (review in damn). Locking of multiple squares goes against the principle of “divide and map” and therefore it is problematic, but there are valid use-cases. When you need to map multiple squares, merge them first (in mappy client). Do the same with the squares you want to validate, but it is probably better idea to set which mapper in the damn plugin for JOSM instead.

That second option is interesting. I have slightly extended the server’s API (CreateCommit it is), so when sending requests to map or review, it is possible to specify the mapper’s name. And it works for all types of requests. I mean… probably the most usable is “review recent [square] of mapper’s name”. But you can also “map nearest [square] of mapper’s name”. Just any combination of map/review recent/oldest/random/nearest can contain the mapper’s name.

Split task for validators is perfectly valid idea, so I have implemented it. The interesting part here is what it took to implement it: I had to change four lines of code in single file. Good design matters, in my opinion.

The last of the interesting issues is Revert All Tasks State by Specific Username. I will not implement such a functionality. However, I am willing to revert mapper’s work manually, when reported by at least two validators with significant contribution to the area. By reverting mapper’s work I mean adding new commits to specific area with to map (or other) type. It will be a single SQL query anyway.

Please, note that I have chosen only the issues I think are interesting and worth implementing.

Work for 2023

I will continue the work on the deploy repository; it’s current state is inconsistent with the documentation. I think I will perform another round of load testing next year, just to check the performance is still good.

I need to work on web clients. I will start with the client for (first-time) mappers, for finished areas, or with the manager. The goal for the next year is to distinguish clients by what mappers need instead of what clients can do. When clients are ready and the wording somehow fixed, there are still translations to do.

That’s it. If the damn project helps you, feel free to use it. Keep mapping!