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.

… See full entry

The inspiration for this diary comes from the email sent to the HOT mailing list. I must say that I’m not involved in Missing Maps anymore, so I don’t currently use the HOT Tasking Manager (TM). Also, I’m the author of the competing project. That’s the disclaimer.

I will start with the point since when the HOT Tasking Manager became unacceptable for me. That was when mappers began to be forced to provide their email addresses. The reason was: just 4% of the mappers shared it.

The purpose of a Tasking Manager is to divide big area into smaller squares that a human can map. Then, let mappers communicate on what they are working on by changing the states of the squares. So, TM helps with a group mapping management.

However, the changes go to the OpenStreetMap. You don’t have to use Tasking Manager to update OpenStreetMap, but you (must) use OpenStreetMap when working with a Tasking Manager. OpenStreetMap itself provides communication channels for mappers, particularly changeset discussions and private messages.

Changeset discussion is used to discuss changes mappers do in the OpenStreetMap. Private messaging is used to send direct messages between mappers. In both cases a notification is sent by email.

We are almost there. So, why is the communication within the HOT Tasking Manager wrong? Because the HOT TM duplicates the communication about things it does not manage – changes to the OpenStreetMap. Because it allows group and automated messages/emails that are, by definition, depersonalized. Because it confuses beginner mappers about which communication channels are really important.

I would like to end with a proposal for the HOT Tasking Manager developers. Please, keep the functionality of the HOT Tasking Manager non-overlapping with the OpenStreetMap. Please, do leverage OpenStreetMap for the rest.

This diary post is inspired by the cleaning up after a task manager task. It shows how to do the clean-up steps for a Divide and map. Now. area.

The data quality matters. The proposal in the Johnwhelan ‘s diary is to run duplicated building script and JOSM validator when an area is finished on the whole area. The rest of his diary deals with how to get the area’s border geometry and the OpenStreetMap data into the JOSM.

Here are the steps to download the area’s geometry and the OpenStreetMap data when using the damn project:

1. Load the area’s geometry by navigating to the area in the JOSM damn plugin, then click Get area geometry button.

   It’s also possible to navigate to the area in the mappy (web) client, right click on arbitrary square and download area geojson, and open the downloaded file in the JOSM. It’s good idea to right click on the created area.geojson layer and Convert to GPX layer to make it read-only, which is the same result as when using the JOSM damn plugin.

2. Download the data from Overpass API, which is the second tab on Download map data … dialog. You can get the Overpass query by navigating to the area in the mappy (web) client, right click on arbitrary square and area overpass query. Then copy the query to the JOSM’s Download from Overpass API, Overpass query: field and click Download. Be sure you have enough RAM for big areas.

That’s all. It’s kind of fun I’m writing this diary just few days after my damn project developer’s “annual report”, but I didn’t make it sooner.

It’s two years since the Divide and map. Now. has been published. I would like to summarize the second year of the development.

What is it about? Divide and map. Now. – the damn project – helps mappers by dividing some big area into smaller squares that a human can map.

Why should I care? Divide and map. Now. is proven to handle a mapathon with 200 mappers. There are four clients available for mappers and multiple mapping workflows. There is deployment guide for admins. You may create new or modify existing areas, use RSS to track areas’ changes, and check abandoned or overlapping areas by Python3 scripts.

In 2021 I’ve refactored the server and load tested it. There is the API documentation that is stable for more than half a year now. The web clients were also refactored: the light is text-only web client for beginners, the panel is for advanced mappers and looks like it’s integrated into the iD editor, and the mappy web client has square-based graphical interface. The web clients include improved statistics that can show OpenStreetMap contributors that haven’t used Divide and map. Now. when mapping in the same area. The damn JOSM plugin was updated to the new API and loads temporary data stored in the server when available.

I’ve got inspired by the Tanga Building Footprints Import, mapping highways’ radars and mirrors, and documented the mapping workflows available in the different clients.

I’ve implemented Python3 client with the scripts to find abandoned or intersecting areas based on the potential HOT tasking manager improvements and looked at the competing HOT Tasking Manager and SimpleTaskManager issues from the damn project point of view.

I’ve created the finished areas read-only service and announced the policy for finished areas.

… See full entry

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.

… See full entry

The idea to map radars and mirrors of the Czech highways was raised in the mailing list of the Czech community. One of the comments is questioning about how to track the work done–and that’s exactly the problem to be solved by the damn project. (Note that the idea to map radars and mirrors of the Czech highways is still just an idea and there are no further steps done yet I’m aware of.)

I already wrote two Get inspired by … diaries. These were the potential HOT tasking manager improvements and the Tanga Building Footprints Import. This diary discuss the use of the damn project for tracking the work done on highways.

Create area

The damn project helps mappers by dividing some big area into smaller squares that a human can map. How this applies to highways?

It’s possible to upload two kinds of GeoJSON boundary files to the damn manager. If the FeatureCollection has member ‘name’ then divide to squares function is NOT used. Moreover, I’ve updated the damn project to understand what to do with a feature containing a LineString geometry: create a “square” with the border around the LineString. (“Square” here means a square of an area of the damn project.)

So… when you download some highway=motorways within some interesting bounding box (I mean from overpass API in JOSM,) save as GeoJSON, and add name member, you are able to upload that as GeoJSON boundary file to the damn manager.

Note that I experimented with joining ways to make larger squares of an area. The JOSM damn plugin then refused to automatically download the OSM data of a square because the square was too large, and the data had to be downloaded manually.

Mapping

The mappy client may help to visualize the area. An example is area 2352 and it looks way better with background image switched off. The JOSM damn plugin, light client, or panel using map random square/map nearest square are better options, though.

… See full entry

As I’m not yet sure what will be included in the alpha version of the damn project, I’m getting inspired. This time by Tanga Building Footprints Import announced on the imports mailing list.

It looks like the buildings are already imported in the Tanga city, e.g. this one, but I’ve never done the import thing, so I can’t say.

In this diary, I’m going to introduce the example mapping workflow with the prepared data based on Tanga Building Footptrints Import using the damn project. Not everything is yet fully automated, so this diary is more like describing the proof of concept. However, I’m open to the needs of the future.

Create area

There is the dataset of the buildings available on the wiki page. I like that idea of huge GeoJSON file that includes the features with the corresponding geometries. As I’m not the import guy, I’m confused with _key_s in the properties (I mean these underscores of each key.) I need only building:yes tag, so I’ve renamed just those (note that notepad’s “Replace All” would do the same:)

sed -i 's/_building_/building/' buildings.geojson

I’ll create new area to work on. Therefore, I need the geometry of the whole area, where the buildings are. For that, I’ll use the damn-client.py scripts. (The shapely must be installed.)

cd damn-client.py
./convex_hull.py buildings.geojson > ch-buildings.geojson

The command took about a minute on my laptop. The ch-buildings.geojson can be used as the GeoJSON boundary file in the damn project’s manager.

Buildings of the squares

So I’ve area to work on divided to squares. Now, I need the GeoJSON files containing all the buildings of each square. I’ll use the damn-client.py scripts once again:

cd damn-client.py
./prepare_tmp.py https://server.damn-project.org 2351 buildings.geojson

… See full entry

This diary is about load testing. I find load testing useful mainly because of two reasons: 1. it shows multiuser access problems; 2. it shows how good is the implementation.

The idea is to simulate mapathon. A mapathon is an event where multiple mappers map the same (big) area. To manage the work, the area is divided into smaller squares. Then, each mapper asks the server to map or review a square, works some time on the square, and finally asks the server to mark the square as needs mapping, needs review, or is done.

I use locust.io to load test the damn server. The test file is part of the repository. There is 80 % of mappers, 20 % of reviewers, and 2 testing areas. Each mapper/reviewer works for 30 - 60 seconds, then waits for 30 - 60 seconds, and then works again. All the mappers are spawned within the first minute. The test is stopped soon after there is 0 % to map for both of the areas.

damn-project.org runs on $5/month VPS with 1 GB RAM, single 2.2 GHz vCPU, and 25 GB SSD disk.

100 mappers handled The first round of load testing gives the idea about the server after the refactoring. The average response time for 100 mappers is 270 ms. Not bad, I would say.

• Locust results for 100 mappers
• Utilization for 100 mappers

It’s a bit worse when testing 200 mappers, though. I’ve stopped the test after 20 minutes.

• Locust results for 200 mappers
• Utilization for 200 mappers

Some improvements Two years ago, I decided that there must be some better solution for the problem of dividing a big area into smaller squares. I found that there is PostGIS extension to PostgreSQL so I decided to go with it. Two year later (now,) I’ve discovered database indexes.

Also, I’ve read part of the documentation and set postgres parameters.

Finally, I switched gzip on.

… See full entry

In the beginning of the year, I’ve been refactoring the Divide and map. Now.. I’ve already wrote about the clients and about the improvements. In this diary, I would like to share some details about how the server looks like now.

The damn project distributed architecture is depicted below. I’ll write about the api and db bubbles, where db is the PostgreSQL database with the PostGIS extension and the api is the python FastAPI application.

Damn server API

Automatically generated documentation of the API is useful for the developers of clients. There are some not so much interesting endpoints dealing with authentication and authorization, users updates, or squares GPXs. I will elaborate on /areas, /geometries, /area/AID, /area/AID/commits, and /area/AID/squares endpoints here.

… See full entry

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.

… See full entry

I’ve been refactoring the Divide and map. Now. last two months. (No surprise, I’ve plan it.) The most beautiful work was done on the server and the database. I will cover that in more technical diary later.

In this diary, I want to summarize how the clients look like now.

Client + panel

The (lightweight) client keeps with the common mapping workflow: Map -> Review -> Done. It’s meant to load fast with the minimum data transfer. It tries to avoid rushed clicks of newbie mappers by putting the phrases of “needs more mapping”, “is ready for review” or “split the square” into the sentence. Newbie mappers may click “let reviewers know” as I’ve already wrote.

… See full entry

Divide and map. Now. helps mappers by dividing some big area into smaller squares that a human can map.

It’s been a year already since I announced the damn project, so it’s time to summarize the first year of development.

For mappers

I finally managed to make the manager manager-friendly. There is news for the client, too. Along with mapping random or recent squares, a mapper can choose to map the nearest square. Moreover, reviewers can review a newbie square.

I added background OpenStreetMap for the squares. When you click on a square, you may lock that square manually. When you lock multiple squares, you can merge them.

A mapper can share the link to an area or a square. A mapper can download the client and open it on the computer (saving 96KB of bandwidth next time.)

I fixed bugs of the damn plugin reported by #OSMWorldDiscord guys (Thanks again!) and added the “lock & open in JOSM” link to the client.

I wrote a new client. Wondering, how the integration without integration to iD editor looks like? Open the panel and check it out.

For communities

Divide and map. Now. has a separate repository for the deployment. You need to change seven rows in the config files (five rows with security and OpenStreetMap OAuth tokens, one row with the domain, one with the email address) and create one empty file. And you are ready to go.

I was wondering what is missing in the basic setup. I mean – the minimum you need to run is the server. You probably want a client and manager, too. That’s all. You know – the damn project helps mappers …

However, you are part of a community changing the world. The client and manager are OK, but you probably want to tell others about the community.

… See full entry

I am writing (again) about the Divide and map. Now. The idea of the project is to divide up a big area to organize mapping better. In this note, I will share how I was thinking about the mapping workflow from the beginning, how I finally improved it, and how I hesitated but broke the workflow in the end. And I am sure I did right.

The mapping workflow

The workflow copies a mapathon. Many guys are mapping one area. Few of them are reviewing the work of colleagues. They are locking squares of the area to avoid rewriting the data under their hands.

Since the beginning, it’s possible to lock random or recent square. Mapping guys lock random squares. The reviewing guys lock recent ones to provide feedback to the mappers as soon as possible.

Implementation details
----------------------

Feel free to skip code notes if you are not interested in the code.

There is some background I need to share before showing the SQL query: 

- The server is RESTful.
- Changes to squares work the same as git commits.

(It means that the first commit of any square is `to map`. Then mapper locks a random square adding the `locked` commit to the database. When finished, the mapper adds the `to review` commit. Then the `locked` commit is added again by a reviewer who finally adds the `done` commit.)

The important thing is that no one can delete a commit. Just add. Also, there is no square state. Square consists only of area identifier, square identifier, and border. If you need to know the square's "state," you need to look at the square's last commit.

Finally, the query to map random square is:

    WITH last AS (
	SELECT DISTINCT ON (sid) cid, sid, aid, type, author
	FROM current_commits
	WHERE aid=$1
	ORDER BY sid, cid DESC
    ),
    tomap AS (
	SELECT *
	FROM last
	WHERE type='to map'
	ORDER BY RANDOM()
	LIMIT 1
    )
    INSERT INTO current_commits (sid, aid, author, type, message)
    SELECT sid, $1, $2, 'locked', 'I am mapping'
    FROM tomap
    RETURNING sid

… See full entry

It started by @gustavo22soares’ question on Mastodon (not archived.) My answer was:

@gustavo22soares Hi. If the question is about #damn – there is no delete area function. (It was not needed to demonstrate the concept and there is no consensus about “what after delete?”)

Regarding the name – feel free to use tags for this purpose.

After 2 weeks, there is still no delete area function. Sorry. However, we did something after all.

The damn client may be translated (and it is translated from English to Czech and Portuguese.) Areas may be filtered by tags. There is button to switch between grid and list view. And finally, the damn client supports multiple OpenStreetMap web editors. (No, there is no support for JOSM. Use the damn plugin instead.)

The defaults can be changed easily when deploying – and it was the intention.

And the last thing: I updated the server. (Because I was not satisfied with the function returning the list of the areas.) After the update, I stressed the server a little bit. It was definitely NOT load testing, but I just could not resist.

I run load testing with locust.io on the damn server, and I think it’s usable for mapathon with 100 mappers.

The damn server is part of the Divide and map. Now. – the damn project I have published at the beginning of the year. And I am still interested in the performance. I was wondering if I can simulate a mapathon event.

Setup

I run the damn server on $5 per month VPS of do.co. The server runs Debian 10.2 x64, 1 vCPU, and 1GB / 25GB Disk. There is nothing special about the deployement I described in the last diary.

For load testing, I prepared the area. I uploaded a big area (JOSM measurement plugin says it’s 42 852 square km) with the damn manager, that split it to 654 squares.

Then, I simulated a mapathon in the locust file. The “participating” test mapper can choose from:

1. Get the area and all its commits. (In fact, all commits wouldn’t be used in a real client twice, since since for an area is implemented.)

2. Request a random square for mapping. If the square is available, work on it for between 1 and 5 seconds and then stop with need more mapping (30 %), split the square (10 %), or ready for review (60 %). (In the brackets, there is a probability of stop reason used.)

3. Request a random square for review. If the square is available, work on it for between 1 and 5 seconds and then stop with need more mapping (30 %), please, review again (10 %), or done (60 %).

When (1), (2), or (3) finishes, wait for between 1 and 2 seconds and choose again. (2) and (3) are chosen five times more often than (1).

Testing 100 mappers

I tested for ten minutes. There were ten new mappers per second until a maximum of 100 mappers.

• Median Response Time: 2900 ms
• Average Response Time: 6052 ms
• Min Response Time: 177 ms
• Max Response Time: 70272 ms
• Requests/s: 12.10

The total request count was 7 310. And there was no error!

Testing 500 mappers

… See full entry

At the beginning of the year, I released Divide and map. Now. – the damn project. I present it as the proof of concept that HOT Tasking Manager can be done better.

The damn project consists of multiple repositories – server, client, manager, plugin, and deploy. Damn deploy repository contains setup used for running instance of server, client, and manager. The only changes to master branch of the damn deploy repository are secrets in .env file and email address in traefik.yml.

Why is there a separate repository for deployment? It complies with the philosophy of do one thing and do it well. The team of administrators deploying the project shouldn’t care about the development of the server or any client.

Why am I writing this? I already wrote about the improvements to the client since the damn project release. And the development continues! I like to improve things. I think that deployment is essential. Finally, there is Ray Kiddy’s comment on gitter:

Thinking more about it, I am interested in seeing something that is easy to provision and get running. So I used “flexibility” as a code word for the ability to bring up new damn instances, at will, and without much hassle.

So I was thinking about how to deploy easier.

How to deploy

I believe that if I want to describe something, the best is start from scratch. So, here we go.

Setting up virtual private server

At do.co, I created new Debian 10 droplet, just $5/mo. In the time of publication, this droplet is already down, and testing instances do not work. See https://www.damn-project.org/ for running available instances I am not willing to shut down.

Then I added test-server.damn-project.org, test-client.damn-project.org, and test-manager.damn-project.org DNS A records pointing to the IP address of the droplet. Now, I can ssh root@test-server.damn-project.org.

Prerequisites

All the deployment is in damn deploy repository. The howto is in readme file. So, I will just follow the readme.

… See full entry

So we organized an online mapathon. I want to share what we planned, how it worked, our feedback, and my thoughts about how we should continue.

When I say we I mean core team. By definition, the core team are people who go to a pub after a mapathon. Maybe, it would be better to say that: The Missing Maps is mainly about mapping. However, somebody has to take care of the mappers…. And that’s we, the core team.

In Prague, there are Missing Maps mapathons every last Tuesday of a month (we have an exception in December), and we were not willing to give up on March’s one.

What we planned

We found that we had about 30 registered participants. We do the introduction to mapping in iD editor, we teach the JOSM basics, and we explain how to validate to advanced mappers.

The plan was to have one global chat, video stream for introduction talk, video chat for mapping groups, and video stream again for final talk(s). All of the communication channels must be accessible without registration for participants. Moreover, video chat for mapping groups should be instantly creatable to maximize flexibility.

We needed leaders of mapping groups. Fortunately, there are plenty of capable mappers in the core team. The idea was to limit the capacity of a mapping group (to about 6 - 7 people) to achieve comfort communication.

We got prepared with Introduction to Tasking Manager and iD editor video (in Czech) and written down mapping process (in Czech, too). The video length is limited to 5 minutes. I think it increases the probability that the participants would watch it.

Now about technologies. We used the Freenode IRC channel as the global chat. Participants can connect easily over Kiwi IRC client, just specifying their names. (You can add server and channel after /next/ in the link.) We used Zoom for the introduction and final talks. And we used Jitsi for video chat of mapping groups.

… See full entry

I released Divide and map. Now. – the damn project at the beginning of the year. Also, I presented the damn project at FOSDEM. I was pretty nervous, and I have to work on my presentation skills. The talk was too chaotic, I know. Anyway – now, I want to present changes in the damn client since the release.

Inspired by tasking manager stats, I implemented mapping and review rates. The damn project is ready for these upgrades. All kinds of statistics can be computed from the commits.

The mapper can map or review a random square of an area. Square to map/review selection is server-dependent. I am going to implement something like map the nearest square in the future. However, I think that the decision about a square to map should still be on the server. The user should say something like: “Hey, I am willing to contribute with mapping something like this,” and the server replies: “Good, try this one.” I don’t think that the manual square lock is a good idea.

I moved the essentials procedures to the damn client library and implemented a workaround for the geometry of two and fewer points. Just mark such square done automatically.

I speeded up the whole client! (For developers: if you want, you may test it on your own – git checkout v0.1.0, then back to git checkout master.) Also, I changed the design slightly. I am not a designer, so I am doing small changes as I feel it.

I added squares map. It indeed helps mappers to imagine the remarkable work done.

The next is the mappers’ score. There is a list of mappers and reviewers with their corresponding number of squares done. And the last upgrade – it’s finally possible to logout (for developers: delete JWT token stored as a cookie; the default cookie expiration is one year), and there is a user’s last week statistics. It would be possible to load all the user’s commits and compute overall statistics, but it takes quite long.

… See full entry

What?

There is a place to be mapped. The area is usually too large for one guy. Involving a team of mappers is, therefore, evident. And there is an excellent approach to solving big problems called divide and conquer. Therefore Divide and map. Now. – the damn project.

The goal is to split a large area to squares a human can map. Then, lock a square, work on it, and mark ready for review. Lock again, review the square, and mark as done. The project is here to avoid overwriting work between mappers.

If this sounds familiar, you probably know the HOT’s Tasking Manager. (HOT stands for the Humanitarian OpenStreetMap Team.)

Why?

There are issues with the HOT Tasking Manager. Mainly performance issues. Then, slowly forgetting about essential functionality. Unwanted updates as the necessity of email address (I really hate this!). And only one repository for the whole project.

These are technical issues, however. What about community issues? Why Google disk when there is OpenStreetMap wiki? Why Slack where you must be invited and logged to (just!) see the history? Why all these sign-up Google forms to contribute? I will try to guess an answer – because HOT is a company (even non-profit) and does not know how to be an open community.

Before you ask “If you are so smart, why you do not contribute to Tasking Manager?”, I tried 1, 2, 3, 4. However, there is no real discussion about the future of the Tasking Manager. The future is already decided; openness means that you can see the source code and fix bugs. Nothing more.

Who?

Let’s talk about the potential damn community. It starts with mappers. I will split mappers to novices, experts, reviewers (or validators), and mentors. Mappers are the most critical and the largest group, so the tool they use should be efficient, stable, and comfortable.

… See full entry

To be fair, we were validating. We validated 5% of the tasks and invalidated 4%. So we went over 9% of the tasks. In 2 hours. With the group of 5 people. And one of us was validating for the first time.

The point is that the validation is not fixing. The validation is approving.

I would like to note our small contribution from Prague. Inspired by London Missing Maps mappers, we started small mapathons this summer. These mapathons are for advanced mappers, we use JOSM, and this time, it was a validation time. I went over multiple sources describing how to validate. I used OSM wiki as a primary source. Then LearnOSM, MissingMaps, and browsed multiple links pointed out by these sources. I attended HOT validation training webinar. I found out these pieces of information bloated, so I stripped them and picked up what I consider helpful.

There are fewer validators than mappers. If validators want to keep up with mappers, they need to validate faster than the mappers are mapping.

Our group was validating buildings with the following workflow:

• Find out if you are going to invalidate task, usually because of not-orthogonalized buildings, missing buildings, lousy geometry, or buildings mapped with bad imagery.

• Orthogonalize all the buildings with 4 nodes:

  • Ctrl + F and find buildings nodes:4 inview.
  • Press Q.

• Upload changes and invalidate task with the comment why.

Of course, if there is no problem and everything is mapped as described in instructions, just browse the square and find out if everything is really ok. MarkSeen plugin can help here. If there is one building with wrong dimensions or bad rotation, fix it (Utilsplugin2 and X for resizing help here a lot). If you find out the second one, invalidate. Validating is approving, remember?

… See full entry