H3 vs Geohash: Hitung di Grid, Laporkan di Batas Wilayah

#Pakai H3 atau geohash?

Pakai grid yang sesuai dengan pertanyaannya, lalu laporkan di batas wilayah yang sudah dipakai bisnis. Geohash lebih cocok ketika sel harus berpindah sebagai teks biasa lewat tabel, konfigurasi, dan spreadsheet. H3 lebih cocok ketika yang diukur adalah pergerakan, aliran, atau supply terhadap demand antar-sel yang bertetangga. Keduanya tidak menggantikan distrik, zona, atau area layanan yang menjadi tanggung jawab seseorang.

Saya pernah memakai keduanya. Di Grab, setiap booking membawa geohash 6 karakter, dan pendapatan dihitung per geohash. Di analisis taksi NYC, saya mengukur supply dan demand di sel H3, lalu menggabungkannya ke zona taksi. Grid-nya berbeda, polanya sama: hitung di grid, laporkan di batas wilayah.

#Apa itu geohash dan H3?

Keduanya membagi peta menjadi sel ber-ID, dalam beberapa tingkat detail. Perbedaannya ada di bentuk, cara kerja ID, dan perilaku tetangganya.

	Geohash	H3
Bentuk sel	Persegi panjang	Heksagon (plus 12 pentagon di setiap resolusi)
ID	String base-32 pendek, misalnya qqguyb	Indeks 64-bit, biasanya ditampilkan sebagai string hex 15 karakter
Tingkat	Presisi 1–12; setiap tingkat memecah sel menjadi 32	Resolusi 0–15; setiap heksagon punya 7 anak
Sel tipikal di kota	Presisi 6 ≈ 1,2 km × 0,6 km	Resolusi 8 ≈ 0,74 km²
Tetangga	8, dengan dua jarak berbeda (sisi dan sudut)	6, semuanya berjarak sama
Induk dan anak	Anak tepat berada di dalam induk	Anak kira-kira menutupi induk
Tanpa library	Bisa: pencocokan prefix di kolom teks	Butuh library H3 atau ekstensi database

Buka ukuran penuh

Buka ukuran penuh

#Kapan geohash lebih cocok?

Ketika ID sel harus berpindah lewat sistem biasa. Geohash hanyalah string, jadi muat di kolom database mana pun, bisa di-join seperti key lainnya, dan bisa ditempel di spreadsheet atau file konfigurasi. Sel dengan prefix yang sama biasanya letaknya berdekatan, jadi LIKE 'qqguy%' adalah filter awal yang murah.

Itulah sebabnya geohash cocok untuk operasional di Grab. Tabel booking membawa geohash titik jemput, tabel lookup memetakan setiap geohash ke sebuah area, dan pendapatan bisa dijumlahkan per sel untuk mengarahkan promo tepat ke blok yang membutuhkannya. Tim non-GIS bisa meminta daftar sel untuk zona layanan baru, dan untuk itulah tool geohash self-service saya dibangun.

Trade-off-nya perlu diketahui:

• Tetangganya tidak seragam. Tetangga di sudut lebih jauh daripada tetangga di sisi, sehingga analisis yang menghaluskan atau membandingkan sel bersebelahan jadi miring.
• Prefix bisa menyesatkan. Dua sel di kedua sisi garis grid besar bisa bertetangga di lapangan, tetapi hampir tidak punya prefix yang sama.
• Lompatan antar-tingkatnya besar. Setiap kenaikan presisi melipatgandakan jumlah sel 32 kali, jadi naik dari 6 ke 7 adalah lompatan besar dalam ukuran tabel.
• Cakupannya harus lengkap. Kalau tabel lookup kehilangan satu sel, booking di sel itu diam-diam hilang dari laporan, seperti dibahas di artikel celah poligon.

#Kapan H3 lebih cocok?

Ketika analisisnya tentang pergerakan dan kedekatan. Setiap heksagon punya enam tetangga dengan jarak yang sama, sehingga membandingkan sebuah sel dengan cincin tetangganya, menghaluskan heatmap, atau menelusuri aliran di seluruh kota berperilaku sama di mana pun.

Ini penting di analisis NYC. Setiap sel H3 resolusi 8, sekitar 1.070 sel di seluruh kota, punya angka supply dan demand sendiri, dan selisihnya bisa dibandingkan secara adil dari satu sel ke sel berikutnya. Resolusi 8 cukup halus untuk memisahkan bandara dari sekitarnya, dan cukup kasar agar jumlahnya tetap stabil.

Trade-off-nya berbeda:

• Butuh tooling. ID-nya berupa integer 64-bit; perlu library H3 atau ekstensi database untuk membuat dan membacanya.
• Anak tidak tepat bersarang. Tujuh heksagon anak kira-kira menutupi induknya, jadi agregasi lintas resolusi mendekati, tetapi tidak sempurna.
• Ada pentagon. Setiap resolusi punya 12, hampir selalu di atas lautan, jadi jarang berpengaruh untuk analisis kota, tetapi kode tidak boleh mengasumsikan enam tetangga secara membabi buta.

#Kenapa tidak pakai batas administratif saja?

Karena batas administratif digambar untuk pemerintahan, bukan untuk pengukuran. Ukuran dan populasi distrik serta zona sangat bervariasi, jadi metrik per distrik bisa berubah hanya karena batasnya berubah, bukan karena ada yang terjadi di lapangan. Distrik pedesaan yang luas dan blok kota yang padat bukan satuan yang setara.

Tetapi di batas wilayah itulah akuntabilitas berada. Tim kota memegang kota, sales manager memegang wilayah, lead operasional memegang area layanan. Tidak ada yang memegang heksagon 882a100d2bfffff. Laporan yang hanya berbasis grid menghasilkan angka yang adil tetapi tidak punya pemilik.

#Bagaimana menggabungkannya?

Hitung setiap metrik di grid, lalu gabungkan ke batas wilayah dengan penjumlahan, bukan rata-rata.

Buka ukuran penuh

-- Simplified illustration (not production code):
-- metrics computed per cell, then rolled up to the reporting boundary
with per_cell as (
  select cell_id,
         count(*) filter (where kind = 'demand') as demand,
         count(*) filter (where kind = 'supply') as supply
  from events
  group by cell_id
)
select z.zone_name,
       sum(c.demand) as demand,
       sum(c.supply) as supply,
       (sum(c.demand) - sum(c.supply))::numeric / nullif(sum(c.demand), 0) as unmet_rate
from per_cell c
join cell_to_zone z using (cell_id)
group by z.zone_name;

Ada dua aturan yang lahir dari kesalahan yang pernah saya lihat di kedua proyek:

• Jumlahkan dulu, bagi belakangan. Merata-ratakan rasio per sel membuat sel yang sepi dengan satu booking bisa mendominasi seluruh zona. Di analisis NYC, versi awal melakukan persis hal itu dan menghasilkan rasio yang tidak masuk akal, sampai rasionya dihitung dari jumlah yang sudah ditotal.
• Jaga tabel sel-ke-batas tetap lengkap. Setiap sel di dalam batas pelaporan harus ada di tabel pemetaan, atau aktivitasnya hilang dari laporan tanpa error apa pun.

#Mana yang sebaiknya dipilih?

Pertanyaanmu	Lebih cocok
Sel mana yang masuk zona layanan atau geofence ini?	Geohash
Ke mana promo diarahkan, digabung dengan tabel booking?	Geohash
Di mana supply tidak memenuhi demand, dan bagaimana menyebar ke tetangganya?	H3
Bagaimana lalu lintas atau pergerakan mengalir di kota?	H3
Bagaimana performa tiap kota atau distrik bulan ini?	Batas wilayahnya, dihitung dari grid mana pun

Kalau sebuah tim sudah berjalan dengan satu grid, pertahankan, kecuali pertanyaannya benar-benar butuh kekuatan grid yang lain. Berganti grid berarti membangun ulang setiap tabel lookup yang bergantung pada grid lama, dan itu migrasi tersendiri.

#FAQ

#Apakah H3 lebih akurat daripada geohash?

Tidak ada yang lebih akurat; keduanya membagi ruang dengan cara berbeda. H3 memberi tetangga yang seragam, lebih baik untuk kedekatan dan pergerakan. Geohash memberi ID string yang sederhana dan bersarang tepat, lebih baik untuk lookup dan konfigurasi.

#Presisi geohash berapa yang setara H3 resolusi 8?

Kira-kira presisi 6 sampai 7. Sel presisi 6 berukuran sekitar 1,2 km × 0,6 km, lebih besar dari rata-rata heksagon H3 resolusi 8 yang sekitar 0,74 km², sementara sel presisi 7 jauh lebih kecil, sekitar 150 m × 150 m.

#Apakah keduanya bisa dipakai dalam satu proyek?

Bisa. Pengaturan yang umum: geohash untuk tabel operasional dan konfigurasi, H3 untuk analisis, dan keduanya dipetakan ke batas pelaporan yang sama.

#Referensi

• H3 resolution table, dokumentasi H3
• Geohash, Wikipedia
• Menemukan $81,6 juta permintaan taksi tak terlayani di NYC dengan H3 dan PostGIS, di situs ini
• Saat Celah Poligon Menjadi Celah Pendapatan, di situs ini

Terakhir diperbarui: 30 Oktober 2026.