Latar Belakang

Di kebanyakan perkebunan, data produksi, pupuk, dan sampel daun tersimpan sebagai tabel — terpisah dari peta block itu sendiri. Ketika seorang manager melihat "Block B01 yield turun 68,9%", angka itu tidak langsung menjawab pertanyaan yang sebenarnya penting: apakah ini masalah satu block, atau gejala awal dari sesuatu yang lebih luas di sekitarnya? Tabel tidak bisa menjawab itu — peta bisa.

Plantation Spatial Explorer dibangun untuk menjembatani dua dunia yang biasanya terpisah ini: data spasial (batas Estate dan Block) dan data operasional (produksi, pupuk, sampel daun), digabung jadi satu WebGIS interaktif yang bisa langsung menunjukkan di mana masalah terjadi, seberapa parah, dan apakah itu kasus terisolasi atau pola bersama dengan block tetangganya — tanpa manager harus scroll tabel satu per satu.

Data dan Metodologi

Data : Dua kategori data digabung lewat kode BLOCK yang sama: data spasial (1 Estate ±458 ha, 30 Block di 2 divisi) dan data operasional (produksi FFB bulanan, dosis & status pupuk, hasil sampel daun/LSU). Seluruh data — spasial maupun operasional — adalah data sintetis milik perusahaan fiktif yang dibuat dengan bantuan AI untuk keperluan demonstrasi bootcamp, bukan data perkebunan nyata.

Sumber & arsitektur : Data diambil dari MAPID API, dengan fallback otomatis ke GeoJSON/JSON lokal kalau API tidak tersedia — sehingga aplikasi tetap berfungsi penuh secara offline. Seluruhnya berjalan di sisi client (Vite + Vanilla JavaScript, MapLibre GL JS untuk rendering peta, Turf.js untuk komputasi spasial, Chart.js untuk visualisasi) — tanpa backend, tanpa database. Pilihan Vanilla JS (bukan React/Vue) disengaja: supaya setiap baris logika bisa ditelusuri langsung, tanpa lapisan abstraksi framework.

Metode analisis : Performa yield tiap block diklasifikasikan relatif terhadap rata-rata estate memakai ambang deviasi ±15% — bukan angka mutlak, karena "normal" itu relatif terhadap konteks estate masing-masing. Tiga metode spasial (semua lewat Turf.js) menjawab tiga pertanyaan berbeda:

• Block Benchmark — nearest-neighbor: bandingkan satu block dengan block matang terdekat yang sebanding.

• Nearby Analysis — radius/buffer search: rangkum cakupan data operasional dalam jarak tertentu dari satu block.

• Performance Cluster — deteksi klaster: cek apakah under/over-performance suatu block juga dialami tetangganya dalam radius yang sama, membedakan anomali terisolasi dari pola sistemik.

Hasil dan Analisis

Dari 30 block dengan data yield di periode terakhir, 8 block (±27%) berada signifikan di bawah rata-rata estate, dan 11 block (±37%) signifikan di atas rata-rata — artinya hanya sekitar sepertiga block yang benar-benar "normal". Angka rata-rata estate tunggal (KPI "Yield to Date") sama sekali tidak menunjukkan sebaran ini — justru Attention List yang secara otomatis memunculkan daftar block bermasalah (contoh: satu block tercatat -68,9% dari rata-rata) inilah yang mengubah satu angka KPI jadi daftar tindakan konkret.

Thematic map Production memakai skala warna merah-ke-hijau (rendah → tinggi) dengan block belum matang (TBM) dibiarkan transparan — bukan ikut diwarnai merah — karena yield mendekati nol di block TBM bukan sinyal performa buruk, melainkan memang belum waktunya panen. Tanpa penyesuaian ini, peta akan salah membaca block muda sebagai "bermasalah".

Nilai tambah spatial analysis paling terasa saat menjawab pertanyaan "isolated case atau pola sistemik?" — menjalankan Performance Cluster pada block yang di-flag Attention List langsung menggambar radius pencarian dan menandai tetangganya yang senasib (kalau ada), sesuatu yang mustahil dibaca dari tabel manapun tapi langsung terlihat di peta dalam satu klik. Fitur Ringkasan Eksekutif kemudian mengemas semua insight ini — KPI, chart, Attention List — jadi satu halaman print-ready untuk dibawa ke rapat, tanpa server, murni snapshot dari apa yang sedang ditampilkan.

Kesimpulan

Plantation Spatial Explorer membuktikan bahwa mengaitkan data operasional ke lokasi spasialnya bisa mengubah cara membaca performa kebun — dari "block mana saja yang turun" (butuh baca tabel manual) menjadi "block mana yang butuh perhatian, kenapa, dan apakah ini pola yang lebih luas" (langsung terlihat di peta). Ini dicapai tanpa backend, tanpa database, dan tanpa satu pun dependency di luar kebutuhan inti — bukti bahwa WebGIS yang berguna tidak harus rumit secara infrastruktur.

Sebagai proyek demo/bootcamp, keterbatasannya jujur diakui: data sintetis (bukan kondisi kebun nyata), tanpa automated test suite, dan beberapa ide pengembangan — perbandingan terhadap target/budget yield, optimasi untuk penggunaan lapangan di HP, dan mode offline/PWA untuk area bersinyal lemah — sudah dipertimbangkan tapi belum diterapkan, jadi arah pengembangan lanjutan yang jelas untuk iterasi berikutnya.

Akses Project Link

Github : https://github.com/hdrsml/Final-Project-Plantation-Spatial-Explorer

Dashboard : https://hdrsml.github.io/Final-Project-Plantation-Spatial-Explorer/index.html

Daftar Pustaka

1. 1.
   MapLibre GL JS Documentation. https://maplibre.org/maplibre-gl-js/docs/

1. 2.
   Turf.js — Advanced Geospatial Analysis. https://turfjs.org/

1. 3.
   Vite Documentation. https://vitejs.dev/

1. 4.
   MAPID API & MAPID Academy. https://mapid.io

1. 5.
   Butler, H., et al. The GeoJSON Format, RFC 7946, IETF, 2016. https://datatracker.ietf.org/doc/html/rfc7946

1. 6.
   Esri World Imagery Basemap. https://www.arcgis.com/home/item.html?id=10df2279f9684e4a9f6a7f08febac2a9