If you’ve been surveying the OpenStreetMap (OSM) map notes in Indonesia, you’ve likely encountered a wave of “spam” or irrelevant notes. These aren’t usually malicious; rather, they are often misplaced private memos from third-party mobile applications that use OSM tiles.

Users often mistake the “Add a Note” feature for a personal notepad or a private “Save Location” tool. Some of these notes are even remnants of data synced from apps nearly a decade ago.

Why is this happening? Many apps integrate OSM. Users see a “Notes” button and assume it’s a private diary for their travels.

This list of spam keywords is not exhaustive. I will continue to update this diary entry as new patterns emerge from the Indonesian mapping community.

---

Jika Anda melihat catatan peta OpenStreetMap (OSM) di Indonesia, kemungkinan besar Anda akan menemukan “spam” atau catatan yang tidak relevan. Memo tersebut sering kali merupakan memo pribadi yang salah tempat dari aplikasi seluler pihak ketiga yang menggunakan tile OSM.

Pengguna sering salah mengira fitur “Tambahkan Catatan” sebagai catatan pribadi atau fitur “Simpan Lokasi” pribadi. Beberapa catatan ini bahkan merupakan sisa data yang disinkronkan dari aplikasi hampir satu dekade lalu.

Mengapa ini terjadi? Banyak aplikasi mengintegrasikan OSM. Pengguna melihat tombol “Catatan” dan menganggapnya sebagai buku harian pribadi untuk perjalanan mereka.

Daftar kata kunci spam ini tidak lengkap. Saya akan terus memperbarui catatan harian ini seiring munculnya pola-pola baru dari komunitas pemetaan Indonesia.

---

Gojek hari ini
Grab map
hp hilang
kediaman
tempat tinggal
Rumah Keluarga
rumah pak
rumah bu
rumah ... #mapsme
pak rt
pak rw
pak lurah
's house
's home
"ok"
Tetapkan titik alamat disini
Tetapkan catatan sesuai dengan titik alamat disini
cheap food
My Project
lokasi pekerjaan
lokasi survei
lokasi survey
Lokasi tanah
lokasi lahan
tanah dijual
lahan dijual
Not so nice
ini alamat yang benar
lokasi 1

Saya sedang memulai proyek untuk menambahkan tag name:id pada objek place=* di wilayah Jepang, Korea Selatan, dan Korea Utara. Tujuannya adalah mempermudah pengguna Indonesia dalam mencari dan mengenali nama tempat di Asia Timur sesuai dengan ejaan dan istilah administratif yang lazim (seperti Prefektur dan Provinsi).

Untuk saat ini, penyuntingan hanya dilakukan pada level Node. Objek berupa Relation (seperti batas administrasi) belum termasuk dalam cakupan kerja saya saat ini karena batasan workflow teknis.

---

Localizing place names (name:id) in Japan and the Koreas

I am starting a project to add the name:id tag to place=* objects in the Japan, South Korea, and North Korea regions. The purpose is to assist Indonesian users in searching for and recognizing place names in East Asia according to common spellings and administrative terms (such as Prefecture and Province).

For now, editing is only being performed at the Node level. Relation objects (such as administrative boundaries) are not yet included in my current scope of work due to technical workflow limitations.

A few days ago, I asked the community about converting general GIS polygons into OSM multipolygon relations. I’ve searched online but haven’t found a workflow that fits my needs. Specifically, I am looking for a way to handle three different levels of administrative boundaries where adjacent areas share a single boundary line connected via a relation.

My question on the OSM forum is still awaiting a solution: Link

However, someone from my local community mentioned that what I’m looking for is “topology.” While that is a broad GIS term, they clarified that TopoJSON is a specific format designed for this. There are many converters available to turn GeoJSON into TopoJSON.

Interestingly, I found that someone opened a ticket for a TopoJSON converter in JOSM back in 2020, but it hasn’t received a response yet: Link

I’m planning to update and expand the administrative boundaries for Bali in OSM. I’ve already prepared the multipolygons for admin_level 5, 6, and 7 using single shared ways for efficiency. By leveraging Google Sheets, I’ve also compiled a comprehensive list of Wikidata, Wikipedia links, and multilingual names to better serve Bali’s international profile.

However, the conflation process is proving to be a challenge. The existing data is quite a “nightmare” to clean up; many roads and waterways are currently shared with administrative relations, and landuse or natural features are glued to the boundaries. Time to start untangling!

Memetakan batas administrasi di Indonesia bisa jadi cukup rumit, terutama saat menghadapi nama wilayah yang serupa. Berikut adalah alur kerja (workflow) sederhana saya dalam menyiapkan data tersebut:

1. Sumber Data

Pertama, unduh data spasial resmi dari Peta Rupa Bumi oleh Badan Informasi Geospasial (BIG). Data ini berfungsi sebagai sumber geometri utama.

2. Ekstraksi Titik Lokasi (Place Nodes)

Karena data sumber berbentuk poligon, saya menggunakan QGIS untuk mengekstrak titik tengah (centroid). Titik-titik ini penting untuk membuat tag place=* yang mewakili pusat dari tiap wilayah administrasi.

3. Pentingnya Kode Kemendagri

Poligon tersebut mencakup kode referensi Kemendagri. Kode ini sangat vital untuk:

• Konflasi: Memastikan data cocok dengan set data lainnya.

• Identifikasi: Banyak desa (admin_level 7 atau 8) memiliki nama yang sama. Kode ini membantu membedakannya dalam satu Kabupaten atau Provinsi.

4. Pengayaan Metadata

Menggunakan alat spreadsheet dan teknik konflasi, saya mencocokkan data untuk menambahkan:

• Kode pos

• Tag wikidata dan wikipedia.

• Nama dalam berbagai bahasa (name:en, dsb).

5. Pengolahan Geometri

Sesuai dengan praktik terbaik (best practices) di OSM, saya mengubah poligon menjadi garis terpisah (polylines).

• Hal ini memungkinkan wilayah yang bertetangga untuk berbagi satu garis batas yang sama melalui relasi multipolygon.

• Setelah dikonversi, saya mengekspor hasilnya dalam format .geojson.

6. Pengetagan Akhir (Final Tagging)

Terakhir, saya menggunakan titik lokasi (place nodes) yang telah diekstrak sebelumnya untuk menyalin dan menempelkan tag yang relevan ke dalam relasi multipolygon baru di editor OSM.

Mapping administrative boundaries in Indonesia can tricky especially when dealing with overlapping names. Here is my simplified workflow for preparing this data:

1. Data Sourcing

First, download the official spatial data from Peta Rupa Bumi by Badan Informasi Geospasial. This serves as the primary geometry source.

2. Extracting Place Nodes

Since the source data is in polygon format, I use QGIS to extract the centroids (points). These points are essential for creating the place=* tags that represent the center of each administrative area.

3. The Importance of Kemendagri Codes

The polygons include Kemendagri reference codes. These are vital for:

• Conflation: Ensuring data matches across different sets.

• Identification: Many villages (admin_level 7 or 8) share the same name. The code helps distinguish them within a Regency or Province.

4. Enriching Metadata

Using spreadsheet tools and conflation techniques, I cross-reference the data to add:

• postal codes

• wikidata and wikipedia tags.

• Multilingual names (name:en, etc.).

5. Geometry Processing

To follow OSM best practices, I convert the polygons into independent ways (polylines).

• This allows adjacent areas to share a single boundary line via a multipolygon relation.

• Once converted, I export the result as a .geojson file.

6. Final Tagging

Finally, I use the previously extracted place nodes to quickly copy and paste the relevant tags into the new multipolygon relations in my OSM editor.