How long will HOT Task artifacts be left to rot in OSM?

Communities Indonesia
, , , ,
1

Sampai kapan sisa HOT Task dibiarkan membusuk di OSM?

English translation below

image
image1168×853 149 KB

image
image1280×652 127 KB

image
image1458×861 134 KB

image
image1260×872 134 KB

image
image1298×891 288 KB

Halo rekan-rekan komunitas OpenStreetMap, terutama komunitas Indonesia,

Saya ingin membuka ruang diskusi mengenai kualitas data bangunan hasil dari HOT Tasking Manager di Indonesia. Berikut adalah poin pemantik yang sebelumnya juga sempat saya sampaikan di grup Telegram komunitas:

Jujur, saya kurang suka konsep Hot Task yang fokusnya hanya “bikin data” tanpa diimbangi validator. Apalagi kalau pemetaannya terbuka untuk siapa saja, kualitas data seharusnya tetap diperhatikan. Tidak semua kontributor punya kemampuan yang sama, sementara mapper yang sudah berpengalaman juga belum tentu mau berkutat di Hot Task. Akibatnya, sampai sekarang masih bisa ditemukan artefak atau bangunan dengan geometri buruk yang merupakan hasil Hot Task.

Kalau memang tidak ada mekanisme QA yang jelas, menurut saya lebih baik menggunakan atau menunggu data resmi dari pemerintah seperti BIG atau BNPB ketika tersedia, atau ada pemetaan secara internal dari berbagai organisasi relawan yang memang memiliki proses QA sendiri. Terlebih lagi, Hot Task tetap merupakan bentuk organised editing dan tidak lepas dari Organised Editing Guidelines (disetujui pada 2018), yang salah satunya secara jelas menyebutkan perlunya rencana post-event clean up untuk memvalidasi hasil edit, terutama jika melibatkan kontributor baru. Bahkan, edit yang bermasalah dapat dipulihkan, dan masalah yang berat atau berulang dapat berujung pada pelarangan individu maupun organisasi untuk melakukan editing.

Sayangnya, diskusi pemantik ini di grup Telegram terkesan berjalan cukup alot karena respons yang masuk sebagian besar hanya dari Pak Benny. Oleh karena itu, saya membawa isu ini ke forum resmi OSM Indonesia agar bisa mendapatkan sudut pandang yang lebih luas dari rekan-rekan anggota komunitas lainnya.

Beberapa hal yang ingin saya tanyakan kepada forum:

  1. Bagaimana pandangan rekan-rekan mengenai penanganan data/artefak bangunan hasil HOT Task atau Organised Editing yang tidak sempat tervalidasi setelah tanggap darurat selesai?

  2. Apakah usulan pembentukan aksi pembersihan (clean-up drive) khusus untuk merapikan geometri bangunan buruk hasil tasking lama di Indonesia dinilai perlu?

  3. Langkah seperti apa yang ideal agar tasking-tasking mendatang tetap menjaga kualitas data tanpa mengorbankan kecepatan pemetaan darurat?

Transkrip percakapan lengkap dari Telegram mengenai isu ini juga telah saya sertakan pada balasan di bawah sebagai bahan dokumentasi

English

Hello fellow OpenStreetMap community members, especially the Indonesian community,

I would like to open a space for discussion regarding the quality of building data resulting from HOT Tasking Manager projects in Indonesia. Below is the initial prompt that I previously shared in the community’s Telegram group:

To be honest, I am not a fan of the HOT Task concept when it focuses solely on “data creation” without being balanced by validators. Especially given its open-entry nature, data quality should still be taken into account. Mapping skills naturally vary across contributors, while experienced mappers might not always choose to participate in HOT Tasks. As a result, artifacts or buildings with poor geometry resulting from HOT Tasks can still be found to this day.

Without a clear QA mechanism, it might be more effective to rely on official government datasets from agencies like BIG or BNPB when available, or leaning on internal mapping efforts by organizations with dedicated QA teams. Furthermore, HOT Tasks are still a form of organized editing and fall under the Organised Editing Guidelines (approved per in 2018), which clearly mention the need for a post-event clean-up plan to validate edits, especially when involving new contributors. In fact, problematic edits can be reverted, and severe or repeated issues can lead to bans for individuals or organizations from editing.

Unfortunately, the discussion around this prompt in the Telegram group felt rather stagnant, as the responses mostly came only from Benny. Therefore, I am bringing this issue to the OSM forum to gather broader perspectives from other community members.

A few questions I would like to ask the forum:

  1. What are your thoughts on handling building data/artifacts from HOT Tasks or Organised Editing that were not validated after the emergency response concluded?

  2. Do you think proposing a dedicated clean-up drive to refine poor building geometry from past taskings in Indonesia is necessary?

  3. What would be the ideal approach for future taskings to maintain data quality without compromising emergency mapping speed?

I have also included the full transcript of the Telegram conversation regarding this issue in the reply below for documentation purposes.

1 Like
2

Benny:

Tergantung sudut pandang ya. Dikebanyakan kasus kejadian bencana, Tasking yang diinisiasi HOT sangat membantu.

Dalam konsep 72jam pasca bencana, kecepatan itu diatas segalanya, ketepatan minggir dulu sejenak.

Makanya kenapa banyak humanitarian actors berlomba2 membuat algoritma terbaik untuk memetakan bangunan terdampak. Ini berjalan beriringan dengan output dari Tasking yg sudah dikerjakan oleh kontributor.

It depends on your perspective. In most disaster scenarios, taskings initiated by HOT are immensely helpful.

Under the 72-hour post-disaster principle, speed takes priority over everything—accuracy takes a back seat for a moment.

That is why many humanitarian actors race to develop the best algorithms to map affected buildings. This runs side by side with the output generated from taskings done by contributors.

3

Benny:

QA biasanya dikerjakan oleh organisasi2 yang memang menggunakan data tersebut, ketika proses rehab rekon sedang berjalan.

Memang tidak serta merta apa yg sudah dipetakan langsung wajib divalidasi. Butuh waktu dan proses

QA is usually handled by the organizations actually using the data once the rehabilitation and reconstruction phase is underway.

Naturally, mapped data doesn’t instantly require immediate validation. It takes time and a process.

4

Benny:

Data BIG itu sumbernya <2020an. Kecuali dibeberapa wilayah, seperti Sulawesi, itu 2025an. Dan ini bisa dianggap baseline.

Tugas BIG hanya menyediakan basemap, mengenai dinamika dilapangan ya tupoksi masing2

BIG (Geospatial Information Agency) data dates back to before 2020. Except in a few regions like Sulawesi, where it’s around 2025. This can be considered a baseline.

BIG’s main role is simply providing the basemap; handling ground dynamics falls under the respective duties of each involved party.

5

Respons saya:

Validasi memang butuh waktu, namun seperti yang kita lihat bahwa bangunan-bangunan (yang buruk) hasil dari Hot Task masih ada artefaknya hingga sekarang, artinya validasi telah ditinggalkan. Lalu bagaimana konsensus bangunan yang buruk tersebut sekarang?

My response:

Validation certainly takes time, but as we can see, artifacts of poorly mapped buildings from HOT Tasks still persist to this day—meaning that validation has effectively been abandoned. So, what is the current consensus on handling these poorly mapped buildings?

6

Benny:

Ya semua ada strength and weaknessnya lah. Ga mungkin semua akan sempurna.

Semangat OSM sendiri adalah gotong royong, pasti ada yg riding the wave, tetapi merasa sipaling OSM. Contoh konteks GT.

Kalo dikit2 dibatesin, dengan tujuan supaya hasilnya sempurna, ya OSM ga akan serame sekarang.

Terkait bangunan buruk, kamu bisa mengusulkan pembentukan “Task Force” di Indonesia yang tugasnya fokus terkait hal ini. Atau bisa mulai action membersihkan, sebagai contoh nyata. Banyak jalan lah.

Well, everything has its strengths and weaknesses. You can’t expect everything to be perfect.

The core spirit of OSM itself is mutual cooperation (gotong royong). Naturally, there will be people riding the wave, yet acting like ‘Mr. OSM’. For instance, in the GT context.

If we keep putting restrictions on everything just to achieve perfection, OSM wouldn’t be as active as it is today.

Regarding poorly mapped buildings, you could propose forming a ‘Task Force’ in Indonesia specifically focused on this issue. Or you could take action and start cleaning them up yourself as a concrete example. There are many ways to go about it.

7

Respons saya:

Paragraf pertama sampai ketiga sebenarnya sudah saya jelaskan di awal: “Tidak semua kontributor punya kemampuan yang sama,…” dan justru karena itu kualitas data perlu diimbangi dengan mekanisme validasi. Jadi menurut saya, pembahasannya tidak perlu diarahkan ke akun tertentu atau sampai mengarah pada account shaming seperti yang salah satu disebutkan. Kritik saya dari awal memang lebih kepada mekanisme, kualitas data, serta bagaimana kita merespons ketika ditemukan data dengan kualitas yang buruk.

Untuk paragraf terakhir, ini memperjelas pernyataan bahwa “QA biasanya dikerjakan oleh organisasi yang memang menggunakan data tersebut”. Kalau memang demikian, dengan masih adanya bangunan-bangunan buruk hasil Hot Task sampai sekarang, apakah artinya proses validasi terhadap data tersebut memang belum terjadi, atau ada mekanisme lain yang belum saya pahami? Hal ini juga sepertinya ditegaskan lagi dengan pernyataan “Terkait bangunan buruk, kamu bisa mengusulkan pembentukan Task Force”.

Ketika solusinya kemudian adalah mengusulkan pembentukan Task Force untuk membersihkan bangunan-bangunan buruk tersebut, menurut saya ini menunjukkan bahwa masih ada pekerjaan validasi atau QA yang belum tertangani. Sebenarnya itu bukan masalah yang perlu kita tutupi; justru bisa menjadi bahan untuk memperbaiki proses ke depannya.

Terkait pernyataan “sebagai contoh nyata, jalan”, menurut saya contoh nyatanya justru dari bangunan, seperti yang sudah saya lampirkan dalam screenshot sebelumnya. Artefak bangunan dengan geometri yang buruk tersebut masih ada sampai sekarang, sehingga menurut saya itu sudah menjadi contoh konkret dari persoalan kualitas data yang sedang kita bahas.

Karena saat ini memang sudah ada artefak bangunan buruk, saya berencana mentranskrip percakapan ini ke forum OpenStreetMap sebagai dokumentasi dan bahan diskusi dengan topik “Pembersihan Bangunan Buruk Hasil Hot Task”. Harapannya bukan untuk menyalahkan pihak tertentu, tetapi supaya ada dokumentasi mengenai masalah yang tersisa dan bagaimana penanganannya. Terima kasih juga kepada Pak Benny atas usulan tersebut. Semoga diskusi ini dapat menjadi bahan perbaikan, khususnya terkait mekanisme validasi hasil Hot Task di Indonesia ke depannya.

My response:

I actually addressed paragraphs one through three earlier: ‘Contributors naturally come with varying levels of mapping experience…’ and precisely because of that, data quality needs to be balanced with a proper validation mechanism. Therefore, I don’t think the discussion should be directed at specific accounts or lead to account shaming, as was mentioned. My critique from the beginning has been focused on the mechanism, data quality, and how we respond when poor-quality data is found.

Regarding the last paragraph, it clarifies the statement that ‘QA is usually handled by the organizations actually using the data.’ If that is the case, given that poorly mapped buildings from HOT Tasks still persist today, does it mean the validation process for these data has not taken place yet, or is there another mechanism I might have overlooked? This also seems to be reinforced by the suggestion, ‘Regarding poorly mapped buildings, you could propose forming a Task Force.’

When the proposed solution is to set up a Task Force to clean up these poorly mapped buildings, I believe it highlights that there is still unhandled validation or QA work. This isn’t something we need to hide; rather, it serves as constructive feedback to improve our processes moving forward.

As for the statement ‘as a concrete example, highways (roads),’ I believe the concrete example lies in the buildings themselves, as shown in my previous screenshot. Those building artifacts with poor geometry still exist today, making them concrete proof of the data quality issues we are discussing.

Since these building artifacts are already present, I plan to transcribe this conversation to the OpenStreetMap forum as documentation and a topic for discussion under ‘Cleaning Up Poor Building Geometry from HOT Tasks.’ The goal is not to blame any specific party, but to document the remaining issues and discuss how to address them. Thank you as well to Pak Benny for the suggestion. I hope this discussion leads to improvements, especially regarding the validation mechanism for HOT Tasks in Indonesia going forward.

8

Saya setuju ide memberikan terjemahan Bahasa Inggris agar semakin banyak yang terlibat diskusi ini.

Terima kasih @FajrAl sudah mengangkat isu ini dengan bukti yang kuat. Keluhan ini sangat valid. Sisa-sisa geometri yang buruk dari HOT Task masa lalu memang menjadi beban bagi komunitas lokal, dan mengandalkan asumsi “organisasi pengguna data akan memperbaikinya nanti” terbukti keliru di lapangan.

Namun, sekadar membentuk Task Force manual untuk membersihkan data ini bukanlah solusi jangka panjang. Mengapa komunitas lokal yang harus bekerja keras membersihkan kekacauan yang ditinggalkan oleh Project Manager yang tidak bertanggung jawab? Kita harus menyelesaikan ini di tingkat sistem dan kebijakan perangkat lunak (Tasking Manager), bukan sekadar menyapu masalahnya di OSM.

Sebagai informasi, diskusi mengenai isu-isu ini rutin dilakukan di HOT Quality Control & Assurance Working Group (QA WG). Ini adalah grup publik yang tidak eksklusif (terbuka untuk siapa saja di komunitas OSM), dan sering membahas tantangan operasional semacam ini (referensi OSM Wiki). Berdasarkan catatan rapat mereka, sebenarnya sudah ada beberapa inisiatif penyelesaian yang dibahas. Sayangnya, pelaksanaannya butuh dorongan lebih tegas dari komunitas.

Saya kepikiran tiga solusi struktural berikut:

1. Hentikan Data Buruk dari Sumbernya (Wajib Sandbox)
Saat ini, banyak pemula langsung memetakan data live saat krisis. QA WG telah merekomendasikan agar Tasking Manager Sandbox diubah dari sekadar fitur eksperimental menjadi prasyarat wajib bagi kontributor baru. Ini memberikan lingkungan yang aman bagi mapper untuk berlatih tanpa memasukkan error ke dalam data live OSM. Komunitas harus mendesak agar gerbang keamanan ini diaktifkan secara permanen.

2. Akuntabilitas Project Manager (Penangguhan Akses)
Saat ini memang ada upaya Project Gardening—mengarsipkan proyek lama yang terbengkalai. Masalahnya, mengarsipkan proyek di Tasking Manager tidak menghapus bangunan buruk di OSM. QA WG sepakat bahwa Project Manager harus tetap terlibat memantau kualitas output. Solusi nyatanya: Jika seorang Project Manager menelantarkan proyeknya berbulan-bulan tanpa validasi penuh, hak mereka untuk membuat proyek baru di platform HOT harus ditangguhkan otomatis (suspended) sampai proyek lamanya divalidasi atau di-revert.

3. Pengetatan Akses Validator Berbasis Tim
Validasi yang buruk sama bahayanya dengan pemetaan yang buruk. Sedang ada pembahasan di QA WG bahwa mapper tingkat intermediate sebaiknya tidak diizinkan melakukan validasi mandiri kecuali mereka tergabung dalam tim khusus (named team) yang diawasi. Ini akan mencegah validasi massal yang asal-asalan.

Daripada berdebat siapa yang salah di masa lalu atau melempar beban perbaikan ke komunitas lokal, mari kita gunakan thread ini untuk merumuskan desakan komunitas. Jika pedoman Organised Editing OSMF mewajibkan adanya rencana pembersihan, maka Tasking Manager harus memiliki sistem yang secara otomatis memblokir pihak-pihak yang melanggar pedoman tersebut.

Thank you @FajrAl for raising this issue with strong evidence. This complaint is entirely valid. The remnants of poor geometry from past HOT Tasks are indeed a burden on the local community, and relying on the assumption that “data-using organizations will fix it later” has proven false on the ground.

However, simply forming a manual Task Force to clean up this data is not a long-term solution. Why should the local community have to work hard to clean up the mess left by unaccountable Project Managers? We need to solve this at the system and software policy level (Tasking Manager), rather than just sweeping the problem away inside OSM.

For context, discussions regarding these exact issues are routinely held in the HOT Quality Control & Assurance Working Group (QA WG). This is a public, non-exclusive group (open to anyone in the OSM community), and they frequently debate these operational challenges (OSM Wiki reference). Based on their meeting notes, several structural solutions have already been discussed. Unfortunately, the broader community needs a firmer push harder to implement them.

Let’s push for these three structural solutions:

1. Stop Bad Data at the Source (Mandatory Sandbox)
Currently, many beginners map live data immediately during a crisis. The QA WG has recommended transitioning the Tasking Manager Sandbox from an experimental feature to a mandatory prerequisite for new contributors. This provides a safe environment for mappers to practice without introducing errors into live OSM data. The community should push for this security gate to be activated permanently.

2. Project Manager Accountability (Access Suspension)
There is currently an effort called “Project Gardening”—archiving old, abandoned projects. The problem is, archiving a project in Tasking Manager does not delete the bad buildings in OSM. The QA WG agrees that Project Managers must remain involved in the quality of the project’s output. The concrete solution: If a Project Manager abandons a project for months without full validation, their right to create new projects on the HOT platform should be automatically suspended until their old project is validated or reverted.

3. Strict Team-Based Validator Access
Poor validation is just as dangerous as poor mapping. The QA WG is currently discussing that “intermediate” mappers should not be allowed to validate independently unless they belong to a supervised, specific team (named team). This will prevent reckless mass validation.

Rather than debating past fault or shifting the cleanup burden onto the local community, let’s use this thread to build a unified community push. If the OSMF Organised Editing Guidelines require a clean-up plan, then the Tasking Manager must have a system that automatically blocks those who violate those guidelines.

8 Likes
9

Terima kasih atas responsnya @adiatmad. Jika dicermati kembali, penjelasan Anda sebenarnya sangat tepat untuk menjawab pertanyaan nomor 3 mengenai langkah preventif yang ideal agar tasking mendatang tetap terjaga kualitasnya:

  1. Langkah seperti apa yang ideal agar tasking-tasking mendatang tetap menjaga kualitas data tanpa mengorbankan kecepatan pemetaan darurat?

Mengenai pertanyaan nomor 2, Anda menyebutkan bahwa membentuk tim aksi pembersihan (clean-up drive) manual oleh komunitas lokal bukanlah solusi jangka panjang karena membebani komunitas atas kesalahan Project Manager. Namun, jika aksi pembersihan tidak dilakukan dan kebijakan sistem belum diterapkan pada proyek lama, artefak bangunan buruk tersebut akan tetap bertahan di OpenStreetMap.

Hal ini juga berkaitan dengan poin Akuntabilitas Manajer Proyek yang Anda sampaikan:

“If a Project Manager abandons a project for months without full validation, their right to create new projects on the HOT platform should be automatically suspended until their old project is validated or reverted.”

Seingat saya, sekitar tahun 2020/2021, HOT Task di Indonesia sempat menggunakan situs tersendiri di tasks-indonesia.hotosm.org (yang saat ini sudah ditutup). Pada periode tersebut, proyek yang berjalan dominan pada pemetaan bangunan yang belum ada per kabupaten atau kota (missing buildings). Mengingat situs tersebut kini sudah ditutup, bagaimana kebijakan akuntabilitas ini bisa diterapkan pada proyek-proyek lama? Apakah masih memungkinkan untuk meminta validasi atau pemulihan data (reversion) untuk tasking yang sudah diarsip?

Oleh karena itu, saya rasa pertanyaan nomor 1 dan 2 masih sangat relevan untuk didiskusikan kembali dengan komunitas:

  1. Bagaimana pandangan rekan-rekan mengenai penanganan data/artefak bangunan hasil HOT Task atau Organised Editing yang tidak sempat tervalidasi setelah tanggap darurat selesai?
  2. Apakah usulan pembentukan aksi tim pembersihan (clean-up drive) khusus untuk merapikan geometri bangunan buruk hasil tasking lama di Indonesia dinilai perlu?

English

Thank you for your response @adiatmad. Looking at it closely, your points provide a great answer to question #3 regarding ideal preventive measures for future taskings:

  1. What would be the ideal approach for future taskings to maintain data quality without compromising emergency mapping speed?

Regarding question #2, you mentioned that manual clean-up drives team by the local community are not a long-term solution, as they shift the burden of unaccountable Project Managers onto the local mappers. However, if no clean-up drive is conducted and system-level enforcement is not retroactively applied, these poorly mapped building artifacts will simply remain on the map.

This ties into your point about Project Manager Accountability:

“If a Project Manager abandons a project for months without full validation, their right to create new projects on the HOT platform should be automatically suspended until their old project is validated or reverted.”

From what I recall, around 2020/2021, HOT Tasks in Indonesia used a dedicated instance at tasks-indonesia.hotosm.org (which has since been decommissioned). During that period, the focus was largely on mapping missing buildings per regency/city. Given that this platform is now closed, how would PM accountability apply to these legacy projects? Is it still technically feasible to enforce validation or data reversion for archived tasks from closed instances?

Because of this, I believe questions #1 and #2 remain open for further community input:

  1. What are your thoughts on handling building data/artifacts from HOT Tasks or Organised Editing that were not validated after the emergency response concluded?
  2. If local community clean-up drives are not the recommended path, what would be the most appropriate mechanism to clean up the existing poor building artifacts currently live on the map?

Thank you very much

10

Do you have any links to the organised edit wiki pages and community consultation for the organised edits that added these buildings? I’m curious what was discussed at the time around cleanup.

2 Likes
11

Searching for one of the street names in the pictures at the top, and looking for an “unlikely shaped” building there, I can see that it was “Edited over 5 years ago”, witg changeset comment “#hotosm-project-9377 #missingmaps #indonesia #redcross #climatechange”, and it was that user’s 17th changeset. Their last edit was over 4 years ago.

I don’t think that chasing up exactly what happened 5 years ago is helpful; what would be is stopping that happening again now (and separately to that, tidying up implausible things added 5 years ago).

Are people contributing changesets with only hashtags now? That’s a pretty good indicator that they haven’t received much (or any) training.

A web search doesn’t find that actual HOT challenge (which may be because their website isn’t great - it doesn’t make searching easy), so it would be speculation how good instructions given to new users were at the time, but current challenges should be searchable and it should be possible to see whether instructions were comprehensive or not.

1 Like
12

HOT has archived tasks in the past and they had planned to do it again in october. Badly, history is lost. I dont think that we can consult the archives. See [HOT] 564 published HOT Tasking Manager projects will be archived in bulk on 6 October 2026

13

Ah begitu ya, apa boleh buat. Bangunan-bangunan tersebut sepertinya memang hanya bisa dibersihkan dengan cara sekalian diperbarui bangunannya di peta.

Semoga HOT Task ke depannya bisa menjadi lebih baik lagi sesuai dengan saran perbaikan yang disampaikan oleh @adiatmad dalam tanggapannya di sini.

Ah, I see. I guess that’s just how it is. It seems those buildings can really only be cleaned up if they are updated and remmapped as part of ongoing maintenance.

I truly hope future HOT Tasks improve and incorporate better data quality mechanisms, as suggested by @adiatmad in his response here.

14

Biar diskusi yang seru ini ada progresnya, saya udah nambahin komen di sini: Require a validation plan, people responsible for validation · Issue #1380 · hotosm/tasking-manager · GitHub. Nggak nyoba buat ngerangkum semuanya di komen itu sih, cuma sekadar nuangin ide saya dari diskusi kita ini.

To move things forward from this fruitful discussion, I added a comment here: Require a validation plan, people responsible for validation · Issue #1380 · hotosm/tasking-manager · GitHub. I’m not trying to summarize everything in that comment, just capturing my idea from this fruitful discussion.

15

Archived projects are publicly viewable, changing a project’s status from Published → Archived does not affect its public viewability. Old projects can be searched for by changing the unique project ID at the end of this URL: https://tasks.hotosm.org/projects/9377

Informed by the changeset comment tracking tag: #hotosm-project-9377

Or searched for on this page with the ‘All Projects’ filter active: https://tasks.hotosm.org/explore?omitMapResults=1&status=PUBLISHED%2CARCHIVED

1 Like
16

Sam, there’s three problems with that

  1. Sometimes we can’t view the page on the TM without logging in. This might not be the case for archived tasks but it’s also essential we can view the documentation of ongoing organized edits
  2. The documentation seldom or never has the information required to by the organized editing policy. In particular I’ve never personally seen a HOT task with an explicit link to the discussion with the community for that organized edit.
  3. The organized edit policy requires that organized edits are documented on the wiki. Sending someone to the tasking manager is not a replacement for that.

@SomeoneElse you’re right that a 4 year old edit isn’t the best in some ways, but I doubt the situation has gotten any better. We also need a plan to fix these four year old edits and that should really happen before the actors involved do more organized edits. Because I wanted to take a look at a more recent edit I commented on

3 Likes
17

That’s a really good example of the sort of problem that we see on a day to day basis.

It’s by a prolific contributor (6k edits over 4 years) but the changeset comment has no human readable content it it, just hashtag gibberish.

It’s impossible to find out more about what this person might have been asked to do (and by whom) because there’s no direct link from their changeset to that. The nearest we have is “#hotosm-project-66897”, which via a bit of futzing about on HOT’s website you can probably relate to https://tasks.hotosm.org/projects/66897 but alas

Screenshot_20261016_132337
Screenshot_20261016_132337957×270 8.21 KB

It’s worth mentioning that “contacting the project manager” is actually what I normally want to do with most poor quality HOT edits in the first place, since the mapper is usually only obeying (poor quality) instructions, is just sat in a schoolroom doing this for 1 hour a week and really isn’t expecting this website to “talk back” to them.

@SColchester in this example, how do we find out what activity this person is engaged in, and who asked them to take part in this organised edit? How do we see the textual instructions that they are following?

2 Likes
18

Given that this edit is clearly not following the organized editing guidelines can the DWG stop it? I can’t see behavior changing otherwise.

19

To be clear we don’t know whether this edit is contrary to the organised editing guidelines because we don’t know the path that led this user to make this edit. It absolutely might have been an organised edit but it might also have been an edit by a prolific mapper using a private imagery source unrelated to any organisation. We know that there is gibberish in the changeset comment but don’t know what that means or who asked them to write that.

We also know that https://www.openstreetmap.org/way/1568796637 does not look out of place based on iD’s imagery; although the shape doesn’t quite match and most structures like this are rectangular, which this person’s edit isn’t.

In this particular example the DWG hasn’t received an email report and there’s nothing in our issue queue for it, so we’ll tend to concentrate on the reports that we have directly received first.

If the community wanted the DWG to search out potential problems by some criteria (which might include “changesets with only #gibberish in the comment” or “changesets with #gibberish that appears to refer to a project that no-one has permission to access”) then we absolutely could do that, but the direction to do so would really have to come from the community. In a case like this (adding a flat-roofed shed to a small town half way between Harare and Bulawayo) I’m not sure that it would be justified, but there clearly is a problem (described well at the top of the thread) that it’d be great if we could deal with after 4 days rather than 4 years.

– Andy (from the DWG)

1 Like
20

There’s 300+ changesets indicating they are part of the same edit. It’s an organised edit.

I’ll write up an email report then.