# DBANGLE — Panduan Lengkap \n ## 1. Ringkasan Eksekutif (Executive Summary) DBANGLE adalah platform geospasial terpadu yang dikembangkan untuk mendukung pembangunan berkelanjutan di Kabupaten Lebak, Banten. Dengan visi mewujudkan Kabupaten Lebak yang maju, mandiri, dan sejahtera, DBANGLE memanfaatkan teknologi informasi geospasial untuk mengintegrasikan data desa, penduduk, dan statistik guna mendukung perencanaan pembangunan yang efektif dan efisien. Platform ini dirancang untuk memudahkan akses informasi bagi masyarakat dan pemerintah, sekaligus mendorong kolaborasi antar Organisasi Perangkat Daerah (OPD) serta partisipasi aktif masyarakat. ### Fitur Utama DBANGLE menawarkan sejumlah fitur unggulan yang menjadikannya solusi komprehensif untuk pengelolaan data geospasial: 1. Peta Interaktif: Menyediakan peta tematik dengan fitur zoom, pan, dan layer control yang responsif, mencakup 25 kategori seperti telekomunikasi, pertanian, pariwisata, dan kesehatan. 2. Data Terintegrasi: Platform ini menggabungkan data desa, kependudukan, dan geospasial dalam satu sistem untuk kemudahan akses dan analisis. 3. Validasi Data: Sistem validasi otomatis memastikan akurasi dan konsistensi data melalui proses berlapis dari tingkat desa hingga kabupaten. 4. Analisis Spasial: Menyediakan alat analisis untuk mendukung perencanaan pembangunan dan pengambilan keputusan berbasis data. 5. Kolaborasi OPD: Memfasilitasi kerja sama antar OPD untuk pengelolaan data yang lebih efisien. 6. Ekspor Data: Data dapat diekspor dalam berbagai format untuk kebutuhan pelaporan dan analisis. 7. Akses Mobile: Platform responsif yang dapat diakses melalui berbagai perangkat, meningkatkan fleksibilitas penggunaan. DBANGLE telah berhasil memetakan lebih dari 340 desa di 28 kecamatan di Kabupaten Lebak, dengan lebih dari 1.000 data geospasial yang dikelola oleh 50+ surveyor aktif. Platform ini mendukung implementasi One Map Policy Kabupaten Lebak, memastikan data geospasial yang terpadu dan akurat. Kolaborasi dengan berbagai pemangku kepentingan, termasuk Pemerintah Kabupaten Lebak dan Balai Pemdes Yogyakarta, memperkuat komitmen terhadap digitalisasi desa. DBANGLE berencana untuk memperluas cakupannya menjadi platform geospasial tingkat provinsi Banten, mengintegrasikan data dari seluruh kabupaten untuk perencanaan pembangunan yang lebih komprehensif. Pengembangan fitur lanjutan, seperti analisis prediktif berbasis kecerdasan buatan, juga sedang dipertimbangkan untuk meningkatkan kapabilitas platform. DBANGLE adalah wujud inovasi dalam pengelolaan data geospasial untuk mendukung pembangunan berkelanjutan di Kabupaten Lebak. Dengan fitur-fitur canggih dan komitmen terhadap akurasi data serta kolaborasi, platform ini menjadi alat penting bagi pemerintah dan masyarakat dalam mewujudkan visi pembangunan desa yang berbasis teknologi dan partisipasi aktif. \n \n ## 2. Konteks dan Tujuan ### Konteks DBANGLE (Desa Membangun Lebak) adalah platform geospasial yang dikembangkan untuk mendukung pembangunan berkelanjutan di Kabupaten Lebak, Banten, sebuah wilayah dengan lebih dari 340 desa yang tersebar di 28 kecamatan. Kabupaten Lebak menghadapi tantangan kompleks dalam pengelolaan data desa, termasuk fragmentasi informasi, kurangnya integrasi data antar Organisasi Perangkat Daerah (OPD), dan keterbatasan akses terhadap informasi geospasial yang akurat. Sebelum kehadiran DBANGLE, data desa sering kali tersimpan dalam format manual atau sistem terpisah, yang menyebabkan inkonsistensi, duplikasi, dan kesulitan dalam pengambilan keputusan berbasis data. Selain itu, rendahnya literasi teknologi di kalangan petugas desa dan keterbatasan infrastruktur digital di wilayah pedesaan memperparah tantangan ini. Konteks pembangunan Kabupaten Lebak juga dipengaruhi oleh kebutuhan untuk mendukung One Map Policy, sebuah kebijakan nasional yang bertujuan menyediakan data geospasial terpadu untuk perencanaan pembangunan. Sebagai wilayah dengan potensi besar di sektor pertanian, pariwisata, dan sumber daya alam, Lebak memerlukan sistem yang mampu mengintegrasikan data kependudukan, infrastruktur, dan potensi desa untuk mendukung pengambilan keputusan yang lebih tepat. Misalnya, data geospasial dapat membantu mengidentifikasi lokasi ideal untuk pembangunan fasilitas kesehatan, sekolah, atau irigasi, sekaligus memetakan area rawan bencana seperti banjir atau longsor, yang sering terjadi di wilayah ini. DBANGLE lahir dari kolaborasi antara Pemerintah Kabupaten Lebak melalui Dinas Pemberdayaan Masyarakat dan Desa, Kasubag Tapem Sekda Lebak, Balai Pemdes Yogyakarta, dan pengembang teknologi lokal, dengan dukungan dari berbagai pemangku kepentingan seperti akademisi dan komunitas desa. Platform ini dirancang untuk menjawab tantangan digitalisasi desa, sekaligus meningkatkan transparansi, akuntabilitas, dan partisipasi masyarakat dalam pembangunan. Konteks ini diperkuat oleh meningkatnya kesadaran akan pentingnya data-driven governance, di mana keputusan berbasis data dapat mengoptimalkan alokasi sumber daya dan mempercepat pencapaian tujuan pembangunan berkelanjutan (Sustainable Development Goals/SDGs) di tingkat lokal. Faktor lain yang membentuk konteks DBANGLE adalah perkembangan teknologi informasi, khususnya GIS (Geographic Information System), yang memungkinkan pengelolaan data spasial dengan lebih efisien. Dengan lebih dari 1.000 data geospasial yang dikumpulkan oleh 50+ surveyor aktif, DBANGLE menjadi solusi strategis untuk mengatasi kesenjangan digital di wilayah pedesaan. Platform ini juga mendukung visi nasional untuk mempercepat transformasi digital di sektor publik, sebagaimana diatur dalam Peraturan Presiden tentang Percepatan Transformasi Digital Nasional. Selain itu, konteks sosial-ekonomi Kabupaten Lebak, dengan mayoritas penduduknya bekerja di sektor pertanian dan UMKM, menuntut adanya sistem yang dapat memetakan potensi ekonomi desa, seperti lokasi pasar, lahan produktif, atau destinasi wisata. DBANGLE hadir untuk menjembatani kebutuhan ini dengan menyediakan platform yang tidak hanya teknis, tetapi juga inklusif, memungkinkan petugas desa dengan keterbatasan teknologi untuk berkontribusi dalam pengelolaan data. Dengan demikian, DBANGLE menjadi bagian dari upaya besar untuk memberdayakan desa melalui teknologi, sekaligus mendukung pembangunan yang berpusat pada masyarakat. ### Tujuan Tujuan utama DBANGLE adalah menciptakan ekosistem data geospasial terpadu yang mendukung pembangunan desa secara berkelanjutan di Kabupaten Lebak, dengan visi jangka panjang untuk memperluas cakupannya ke tingkat provinsi Banten. Secara spesifik, tujuan platform ini dapat dirinci sebagai berikut: 1. Integrasi Data Geospasial dan Kependudukan: DBANGLE bertujuan untuk mengintegrasikan data desa, kependudukan, dan geospasial dalam satu platform terpusat. Dengan menyediakan data yang terstandarisasi dan tervalidasi, platform ini memastikan bahwa semua pemangku kepentingan, mulai dari OPD hingga masyarakat, memiliki akses ke informasi yang akurat dan terkini. Hal ini mengurangi fragmentasi data dan mempermudah koordinasi antarinstansi. 2. Mendukung Perencanaan Pembangunan Berbasis Data: DBANGLE dirancang untuk menjadi alat bantu dalam perencanaan pembangunan yang berbasis data. Dengan fitur analisis spasial, platform ini memungkinkan pemerintah daerah untuk mengidentifikasi prioritas pembangunan, seperti pembangunan infrastruktur, pengelolaan sumber daya alam, atau mitigasi bencana. Misalnya, peta tematik dapat digunakan untuk memetakan distribusi fasilitas kesehatan guna memastikan akses yang merata bagi masyarakat. 3. Meningkatkan Kolaborasi Antar-OPD: Salah satu tujuan kunci DBANGLE adalah memfasilitasi kolaborasi antar OPD melalui shared workspace. Dengan sistem ini, setiap OPD dapat mengakses dan mengelola data sesuai kewenangannya, seperti Dinas Pertanian untuk data lahan atau Dinas Pariwisata untuk potensi wisata. Kolaborasi ini meningkatkan efisiensi dan mengurangi duplikasi kerja. 4. Memberdayakan Masyarakat Desa: DBANGLE bertujuan untuk meningkatkan partisipasi masyarakat dalam pembangunan melalui akses informasi yang transparan. Dengan peta interaktif dan data yang mudah diakses, masyarakat dapat memahami potensi desa mereka, seperti lokasi sumber daya atau peluang ekonomi, sehingga dapat berkontribusi dalam perencanaan pembangunan. 5. Mendukung One Map Policy: Platform ini bertujuan untuk mewujudkan One Map Policy di Kabupaten Lebak dengan menyediakan peta geospasial terpadu yang mencakup berbagai sektor, seperti pertanian, kesehatan, pendidikan, dan pariwisata. Hal ini memastikan bahwa semua pihak menggunakan referensi data yang sama, mengurangi konflik kepentingan dan meningkatkan akurasi perencanaan. 6. Meningkatkan Kapasitas Digital Desa: DBANGLE bertujuan untuk meningkatkan literasi digital di kalangan petugas desa melalui pelatihan dan antarmuka yang ramah pengguna. Dengan lebih dari 340 desa yang telah terjangkau, platform ini membantu petugas desa mengelola data secara mandiri, sekaligus meningkatkan kapasitas mereka dalam menggunakan teknologi modern. 7. Skalabilitas dan Inovasi: Dalam jangka panjang, DBANGLE bertujuan untuk menjadi model bagi platform geospasial di tingkat provinsi Banten. Dengan rencana pengembangan fitur seperti analisis prediktif berbasis kecerdasan buatan, platform ini diharapkan dapat memberikan wawasan yang lebih mendalam untuk mendukung kebijakan pembangunan yang lebih cerdas. Untuk mencapai tujuan ini, DBANGLE menggabungkan teknologi GIS, validasi data berlapis, dan pendekatan inklusif yang melibatkan masyarakat dan pemerintah. Dengan fokus pada akurasi, aksesibilitas, dan kolaborasi, platform ini tidak hanya menjadi alat teknis, tetapi juga katalis untuk transformasi digital di tingkat desa, mendukung visi Kabupaten Lebak yang maju, mandiri, dan sejahtera. \n \n ## 3. Kebutuhan Pengguna dan Persona ### Pengguna DBANGLE.id 1. Masyarakat (Partisipan) #### Fungsi Masyarakat mengakses informasi publik melalui peta interaktif DBANGLE, seperti lokasi fasilitas umum, potensi ekonomi, atau area rawan bencana. Mereka menjelajahi data desa, memberikan umpan balik melalui fitur komentar, dan mengunduh data publik untuk keperluan pribadi atau kelompok, seperti kelompok tani atau UMKM. Fungsi utama mereka adalah memanfaatkan data untuk mendukung inisiatif lokal dan berpartisipasi dalam musyawarah desa, misalnya dengan mengidentifikasi peluang usaha berbasis peta potensi desa. #### Manfaat Masyarakat mendapatkan akses mudah ke informasi transparan melalui peta tematik yang intuitif, membantu pengambilan keputusan seperti memilih lokasi usaha atau menghindari area rawan bencana. Aksesibilitas mobile mendukung penggunaan di wilayah pedesaan dengan koneksi terbatas, meningkatkan partisipasi dalam pembangunan desa. Data potensi ekonomi mendukung pengembangan usaha, seperti memetakan pasar, meningkatkan kesejahteraan. Transparansi data membangun kepercayaan terhadap pemerintah, mendorong akuntabilitas dan pembangunan inklusif. 2. Surveyor Desa (Admin Desa) #### Fungsi Surveyor desa menginput data kependudukan, infrastruktur, dan potensi geospasial, seperti koordinat fasilitas atau luas lahan pertanian, melalui formulir digital. Mereka memperbarui data secara berkala, seperti perubahan jumlah penduduk, dan berkolaborasi dengan masyarakat untuk verifikasi lapangan. Fungsi lainnya termasuk menerima notifikasi untuk revisi data dan memantau kemajuan input melalui peta desa. #### Manfaat Surveyor desa menghemat waktu dengan formulir digital dan validasi otomatis, mengurangi kesalahan dan meningkatkan efisiensi. Pelatihan meningkatkan kapasitas digital mereka, sementara mode offline mendukung kerja di lapangan. Data akurat meningkatkan kredibilitas desa, menarik lebih banyak anggaran atau proyek. Manfaat ini memberdayakan surveyor untuk berkontribusi pada pembangunan desa, meningkatkan kualitas hidup masyarakat. 3. Admin Kecamatan (Verifikator Tahap 1) #### Fungsi Admin kecamatan memverifikasi data dari surveyor desa, memeriksa akurasi dan konsistensi, seperti koordinat geospasial. Mereka menandai data bermasalah, memberikan catatan revisi, dan meneruskan data lolos ke admin kabupaten. Fungsi lainnya mencakup analisis sederhana melalui grafik atau peta, koordinasi dengan surveyor, dan pengelolaan data dari beberapa desa di kecamatan. #### Manfaat Dashboard analitik mempermudah verifikasi cepat, mengurangi beban kerja manual. Notifikasi otomatis meningkatkan responsivitas, sementara koordinasi antar desa mendukung perencanaan lokal, seperti distribusi bantuan. Manfaat ini meningkatkan kualitas data kecamatan, mendukung kebijakan lokal yang lebih baik, dan meningkatkan kinerja admin serta kepuasan masyarakat. 4. Admin Kabupaten (Verifikator Final) #### Fungsi Admin kabupaten melakukan validasi akhir data dari kecamatan, menggunakan analisis spasial untuk mendeteksi anomali. Mereka mengintegrasikan data ke peta terpadu, mengelola hak akses untuk OPD, dan menghasilkan laporan komprehensif. Fungsi lainnya termasuk pemeliharaan sistem, seperti backup data, dan koordinasi dengan admin kecamatan untuk resolusi isu. #### Manfaat Data terintegrasi mendukung perencanaan strategis, seperti alokasi infrastruktur, mengurangi pemborosan anggaran. Audit trail memastikan transparansi, dan fitur pelaporan menghemat waktu. Manfaat ini mendukung One Map Policy, meningkatkan reputasi kabupaten, dan memungkinkan fokus pada inisiatif pembangunan, dengan potensi kolaborasi provinsi. 5. Organisasi Perangkat Daerah (OPD) (Pengguna Data) #### Fungsi OPD mengakses data tematik untuk perencanaan sektor, seperti pertanian atau kesehatan, dan melakukan analisis spasial, misalnya perhitungan luas lahan. Mereka berbagi data melalui shared workspace, menghasilkan laporan kustom, dan mengintegrasikan data dengan kegiatan operasional untuk mendukung implementasi kebijakan. #### Manfaat Data spesifik meningkatkan efisiensi program, seperti identifikasi lokasi proyek irigasi. Interoperabilitas dengan perangkat lunak GIS mengurangi biaya riset, dan kolaborasi antar-OPD mengoptimalkan sumber daya. Manfaat ini meningkatkan efektivitas kebijakan sektor, membawa dampak positif pada pembangunan dan kesejahteraan masyarakat. 6. Pemerintah Provinsi (Pengguna Data/Penentu Kebijakan) #### Fungsi Pemerintah provinsi mengakses data terintegrasi untuk perencanaan regional, melakukan analisis lintas sektoral, seperti distribusi infrastruktur, dan menghasilkan laporan untuk alokasi anggaran. Mereka memberikan umpan balik untuk ekspansi platform dan mengintegrasikan data dengan sistem provinsi untuk kebijakan yang mencakup beberapa kabupaten. #### Manfaat Wawasan strategis mendukung kebijakan inklusif, seperti alokasi dana yang adil. Skalabilitas platform mengurangi biaya pengumpulan data, dan keamanan data memastikan kepatuhan regulasi. Analisis spasial membantu mitigasi isu regional, meningkatkan koordinasi antar kabupaten, dan mendorong pembangunan berkelanjutan di Banten. \n \n ## 4. Arsitektur Sistem DBANGLE.id (High Level) ### 1. Ikhtisar Arsitektur Arsitektur sistem DBANGLE (Desa Berdaya) dirancang untuk mendukung pengelolaan data geospasial terintegrasi di Kabupaten Lebak, Banten, dengan fokus pada skalabilitas, keandalan, dan kemudahan penggunaan. Sistem ini mengadopsi pendekatan berbasis web dengan pemrograman kompleks yang melibatkan berbagai bahasa pemrograman, termasuk PHP untuk backend server-side, JavaScript untuk frontend interaktif, dan potensi integrasi dengan Python untuk analisis data lanjutan. Arsitektur ini terdiri dari tiga lapisan utama: frontend, backend, dan basis data, yang saling terhubung melalui API dan skrip server-side untuk mendukung operasi pengguna seperti masyarakat, surveyor desa, admin kecamatan, admin kabupaten, OPD, dan pemerintah provinsi. Sistem ini di-host pada infrastruktur web standar, mungkin dengan dukungan cloud seperti AWS (meskipun tidak disebutkan secara eksplisit), untuk menjamin performa tinggi, keamanan, dan skalabilitas. Arsitektur DBANGLE menggunakan teknologi open-source untuk mengurangi biaya dan memungkinkan pengembangan komunitas, seperti Leaflet.js untuk peta interaktif dan PostgreSQL/PostGIS untuk pengelolaan data geospasial. Pemrograman kompleks melibatkan PHP untuk logika server-side, JavaScript untuk interaktivitas klien, dan SQL untuk kueri basis data. Sistem ini juga mendukung One Map Policy dengan menyediakan data terpadu dan akurat, sekaligus memungkinkan ekspansi ke tingkat provinsi Banten. Desain modular memungkinkan integrasi berbagai bahasa pemrograman untuk fungsi spesifik, seperti PHP untuk pengelolaan data dinamis dan JavaScript untuk visualisasi real-time. ### 2. Komponen Utama #### 2.1 Frontend Frontend DBANGLE adalah antarmuka pengguna yang dikembangkan menggunakan JavaScript dengan framework seperti React.js atau vanilla JS untuk memastikan responsivitas dan interaktivitas. Komponen utama frontend meliputi: - Peta Interaktif: Menggunakan Leaflet.js untuk menampilkan peta tematik dengan fitur zoom, pan, dan layer control. Peta ini mendukung 25 kategori data, seperti pertanian, kesehatan, dan pariwisata, dengan rendering real-time yang ringan untuk perangkat mobile. - Dashboard Pengguna: Dashboard yang disesuaikan untuk setiap pengguna dengan akses ke peta, formulir input, dan laporan. Framework seperti Bootstrap dan CSS Grid memastikan tampilan responsif di berbagai perangkat. - Formulir Input: Formulir digital untuk surveyor desa dengan validasi klien-sisi menggunakan JavaScript untuk meminimalkan kesalahan input. - Visualisasi Data: Grafik dan tabel interaktif berbasis library seperti Chart.js untuk analisis sederhana, seperti distribusi penduduk atau luas lahan. Frontend berkomunikasi dengan backend melalui permintaan HTTP ke skrip PHP, memastikan pemisahan logika presentasi dan pengolahan data. Cache lokal di JavaScript digunakan untuk mendukung akses offline sementara, khususnya untuk surveyor desa di wilayah dengan koneksi terbatas. #### 2.2 Backend Backend DBANGLE dibangun dengan PHP sebagai bahasa pemrograman utama untuk server-side scripting, yang menangani logika bisnis dan integrasi data. Untuk pemrograman kompleks, backend dapat mengintegrasikan dengan bahasa lain seperti Python melalui API atau subprocess untuk tugas analisis data. Komponen utama backend meliputi: - Server-Side Logic: PHP digunakan untuk mengelola permintaan dari frontend, seperti validasi data dan pengolahan input dari surveyor desa. File dengan ekstensi .php (misalnya, leuit_desa.php, validasi.php) menunjukkan penggunaan PHP untuk halaman dinamis. - Microservices-Like Approach: Meskipun berbasis PHP, arsitektur modular memungkinkan pemisahan fungsi, seperti manajemen pengguna, pengelolaan data, dan analisis spasial. Python dapat diintegrasikan untuk analisis prediktif menggunakan library seperti Scikit-learn atau GeoPandas. - Analisis Spasial: PHP berinteraksi dengan PostGIS melalui ekstensi PDO atau pg_query untuk operasi seperti perhitungan jarak, overlay peta, dan analisis buffer. - Ekspor Data: Skrip PHP menghasilkan laporan dalam format CSV, Excel, dan PDF menggunakan library seperti PHPSpreadsheet atau TCPDF. - Integrasi Eksternal: PHP API untuk mengambil data dari sumber eksternal, seperti data cuaca dari BMKG atau data pasar dari Dinas Perdagangan. Backend di-deploy pada server web seperti Apache atau Nginx, dengan load balancing untuk mendistribusikan beban lalu lintas, memastikan performa tinggi selama penggunaan puncak. #### 2.3 Basis Data Basis data DBANGLE menggunakan PostgreSQL dengan ekstensi PostGIS untuk menyimpan dan mengelola data geospasial dan non-geospasial. PHP berinteraksi dengan basis data melalui koneksi SQL. Struktur basis data mencakup: - Tabel Geospasial: Menyimpan koordinat, poligon, dan atribut spasial, seperti lokasi fasilitas atau batas desa, dalam format GeoJSON. - Tabel Kependudukan: Menyimpan data demografis, seperti jumlah penduduk, usia, dan pekerjaan, dengan indeks untuk kueri cepat. - Tabel Metadata: Menyimpan informasi tentang sumber data, waktu pembaruan, dan status validasi. - Audit Trail: Mencatat setiap perubahan data untuk transparansi dan akuntabilitas. Basis data di-host pada server database terkelola, dengan replikasi untuk keandalan dan backup otomatis harian untuk pemulihan bencana. Skema basis data dioptimalkan untuk mendukung analisis spasial kompleks, seperti kueri jarak atau overlap poligon, diakses melalui query PHP. ### 3. Alur Data Alur data dalam DBANGLE dirancang untuk mendukung validasi berlapis dan kolaborasi antar pengguna, menggunakan pemrograman kompleks di berbagai bahasa: - Input Data: Surveyor desa menginput data melalui formulir JavaScript, yang dikirim ke skrip PHP untuk validasi otomatis. - Verifikasi Tahap 1: Admin kecamatan memeriksa data via PHP, menandai isu, dan meneruskan data lolos ke admin kabupaten. - Verifikasi Final: Admin kabupaten melakukan validasi akhir dengan PHP dan PostGIS, mungkin memanggil skrip Python untuk analisis lanjutan. - Akses Pengguna: Masyarakat, OPD, dan provinsi mengakses data melalui peta Leaflet.js, dengan data diambil via AJAX calls ke PHP. - Pembaruan dan Pelaporan: Data diperbarui secara berkala melalui PHP, dengan laporan diekspor menggunakan library PHP atau integrasi Python untuk pemrosesan data kompleks. Alur ini didukung oleh queue management di PHP atau integrasi dengan tools seperti RabbitMQ untuk pemrosesan asinkronus. ### 4. Keamanan dan Skalabilitas #### Keamanan - Autentikasi dan Otorisasi: PHP menggunakan session atau JWT untuk mengelola akses berdasarkan peran pengguna. - Enkripsi: Protokol HTTPS untuk komunikasi aman, dengan enkripsi data at-rest. - Audit Trail: PHP mencatat perubahan data untuk melacak aktivitas. - Perlindungan Data: Kebijakan compliant dengan regulasi untuk melindungi data pribadi. #### Skalabilitas - Web Infrastructure: Server PHP scalable dengan penambahan instance selama lonjakan penggunaan. - Modular Design: Integrasi berbagai bahasa memungkinkan pembaruan independen. - Caching: Menggunakan Redis atau Memcached di PHP untuk data sering diakses. - Ekspansi: Arsitektur mendukung integrasi data lintas kabupaten. ### 5. Integrasi dan Interoperabilitas DBANGLE mendukung interoperabilitas dengan standar seperti GeoJSON dan Shapefile, diakses melalui PHP. Sistem mengintegrasikan API eksternal via PHP cURL. Shared workspace memungkinkan kolaborasi, dengan data diakses melalui skrip PHP. Integrasi dengan bahasa lain seperti Python untuk analisis mendukung fungsi kompleks. ### 6. Performa dan Keandalan - Performa: Optimasi PHP dan indeks PostGIS memastikan respons cepat. - Keandalan: Backup otomatis dan replikasi basis data. - Pemeliharaan: Pembaruan melalui CI/CD untuk PHP dan komponen lain. ### 7. Rencana Pengembangan Arsitektur mendukung pengembangan seperti analisis prediktif dengan Python, ekspansi regional, dan fitur offline lanjutan. Arsitektur DBANGLE menggunakan pemrograman kompleks seperti PHP untuk backend, JavaScript untuk frontend, dan integrasi dengan Python serta SQL, menyediakan fondasi kuat untuk pengelolaan data geospasial. Ini mendukung kebutuhan pengguna sambil memastikan performa dan skalabilitas, mendorong transformasi digital berkelanjutan. \n \n ## 5. Teknologi (Tech Stack) ### Ikhtisar Teknologi yang digunakan DBANGLE dipilih untuk mencapai tiga sasaran utama: keandalan layanan publik, kemudahan pengembangan dan pemeliharaan jangka panjang, serta efisiensi biaya. Tumpukan teknologi (tech stack) ini bertumpu pada komponen open-source yang matang dan luas ekosistemnya. Backend mengandalkan PHP di atas Nginx, frontend menggunakan JavaScript (Leaflet.js, Bootstrap) untuk antarmuka peta yang responsif, basis data memanfaatkan PostgreSQL + PostGIS untuk operasi spasial, sedangkan integrasi mobile menggunakan Flutter untuk aktivitas survei dan verifikasi di lapangan. Seluruh komponen dirangkai melalui API yang konsisten dan terdokumentasi sehingga memudahkan kolaborasi antar OPD maupun integrasi ke sistem yang sudah ada. ### Backend: PHP + Nginx - Bahasa: PHP 8.x dengan gaya pemrograman prosedural terstruktur dan modul utilitas yang terpisah agar mudah diuji, serta PDO untuk koneksi basis data yang aman (prepared statements). - Server HTTP: Nginx dikonfigurasi sebagai reverse proxy dan static file server. Optimasi `client_max_body_size`, `fastcgi_read_timeout`, dan `fastcgi_send_timeout` diterapkan untuk mendukung unggahan GeoJSON berukuran besar dan proses analitik yang memerlukan waktu lebih panjang. - Pola Aplikasi: Setiap endpoint API berada pada struktur `api/v1/...` dengan penamaan yang jelas (mis. `auth/login.php`, `desa/verifikasi_peta_android.php`). File PHP memvalidasi input, memanggil fungsi model/data access, lalu menghasilkan respons JSON dengan skema konsisten `{ success, message, data }`. - Keamanan Server-Side: - WAF aplikasi sederhana untuk penyaringan pola isian yang berbahaya, rate limiting, dan header keamanan (CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy) yang disetel via Nginx/PHP. - Seluruh query database menggunakan prepared statements (PDO) dan normalisasi input. - Upload file dibatasi tipe dan ukuran; setiap berkas diperiksa, di-sanitasi nama filenya, dan dipetakan ke direktori tujuan yang ketat hak aksesnya. - Ekspor Data: Laporan CSV/XLSX/PDF dihasilkan melalui library seperti PHPSpreadsheet dan TCPDF; semua proses ekspor dilakukan streaming agar hemat memori. ### Frontend: JavaScript, Leaflet, Bootstrap - Pemetaan: Leaflet.js menyediakan peta interaktif ringan dengan layer kontrol, popup, filter, dan penyesuaian gaya (styling) berdasarkan properti GeoJSON. Untuk performa, data besar dapat dipecah per-kecamatan atau dipakai teknik tiling/cluster sesuai kebutuhan. - UI & Responsivitas: Bootstrap 5, CSS Grid/Flex, dan komponen utility sederhana dipakai untuk memastikan konsistensi tampilan desktop maupun mobile. Ikon peta dapat menggunakan Font Awesome atau SVG khusus. - Interaksi Data: Fetch API (`async/await`) digunakan untuk mengambil data dari endpoint JSON. Validasi isian formulir dilakukan di sisi klien untuk memberi umpan balik cepat, namun tetap diverifikasi ulang di server. - Aksesibilitas: Warna, kontras, ukuran font, dan navigasi keyboard dipertimbangkan agar sesuai praktik aksesibilitas dasar. Peringatan dan notifikasi menggunakan pola ARIA sederhana. ### Basis Data: PostgreSQL + PostGIS - RDBMS: PostgreSQL dipilih karena stabil, kaya fitur, dan mendukung transaksi kompleks. Pemakaian tipe data yang tepat (integer, numeric, text, jsonb) membantu kinerja dan fleksibilitas. - PostGIS: Ekstensi PostGIS memungkinkan operasi spasial tingkat lanjut seperti intersect, buffer, distance, dan area secara langsung di database, mempercepat analitik spasial dan menyederhanakan kode aplikasi. - Skema Data: Tabel geospasial menampung geometri (Point/Polygon/MultiPolygon) dan atribut; tabel referensi menyimpan metadata, kategori peta, serta status validasi (pending/verified/final). Indeks GIST/GiST dipasang pada kolom geometri untuk mempercepat kueri spasial. - Integritas & Kinerja: Constraint, foreign key, serta trigger ringan digunakan untuk menjaga konsistensi. Analisis terjadwal (`VACUUM`, `ANALYZE`) menjaga statistik dan kinerja kueri. ### Mobile: Flutter (Android) - Aplikasi survei memanfaatkan Flutter agar antarmuka dan logika dapat dikembangkan cepat, dengan dukungan offline sementara (menyimpan formulir/koordinat sebelum unggah). Integrasi kamera/galeri untuk bukti foto disimpan terkompresi dan diberi nama file yang konsisten. - Otentikasi: Login dua tahap (password dilanjutkan PIN 6 digit untuk desa) sesuai kebutuhan operasional. Token sederhana dapat disimpan di `SharedPreferences` dengan pengamanan dasar perangkat. - Unggah GeoJSON: `http.MultipartRequest` dipakai untuk mengirim file/metadata ke endpoint verifikasi; aplikasi mengecek respons JSON dan memberi umpan balik status unggah/validasi. ### API dan Kontrak Data - Format: JSON dengan header `application/json; charset=utf-8`. Respons mengikuti pola jelas: `success` (boolean), `message` (string), `data` (object/array). - Versi: Prefix `/api/v1` untuk menjaga kompatibilitas ke depan. Perubahan besar akan dinaikkan ke `/api/v2` tanpa mengganggu klien lama. - Skema GeoJSON: Data peta mengikuti `FeatureCollection` dengan `properties` minimal: kode wilayah, nama wilayah, kategori/FTYPE, dan atribut tematik lain. Validasi server memastikan struktur benar sebelum data dipublikasikan. - Dokumentasi: Daftar endpoint, parameter, contoh respons, dan kode kesalahan disajikan di dokumentasi internal, serta ditaut pada viewer dokumen agar mudah diakses OPD. ### DevOps: Deploy, Logging, Monitoring - Deploy: Nginx + PHP-FPM dijalankan pada mesin Ubuntu. Rilis dilakukan dengan strategi atomik (unggah ke direktori sementara, lalu `mv`) agar downtime nyaris nol. File statis di-cache oleh Nginx; invalidasi cache dilakukan bila ada pembaruan kritis. - Logging: Aplikasi mencatat akses penting, kesalahan, dan peristiwa keamanan ke berkas log terpisah (access log, error log, security log). Format log konsisten untuk memudahkan analisis dan audit. - Monitoring: Health check HTTP sederhana untuk endpoint kritis; dapat diperluas dengan Prometheus/Grafana atau alat setara bila dibutuhkan. Alert berbasis log/HTTP status membantu respons insiden cepat. - Backup & DR: Backup terjadwal untuk database dan berkas unggahan. Uji pemulihan (restore) dilakukan berkala agar rencana pemulihan bencana (DR) valid. ### Caching dan Performa - HTTP Caching: Header `Cache-Control` untuk berkas statis dan respons yang tidak sensitif waktu. Untuk data yang sering berubah, `ETag`/`Last-Modified` membantu mengurangi bandwidth. - Server-Side Cache: Redis/Memcached dapat digunakan untuk menyimpan hasil kueri berat (misal agregasi spasial per kecamatan) dengan TTL yang terukur. - Optimasi Kuari: Penggunaan indeks, pemilihan kolom, dan batasan ruang lingkup (misal filter kecamatan/desa sebelum operasi spasial mahal) menjadi prinsip utama. - Pengolahan Bertahap: Data besar dapat diproses batch/queue agar tidak memblokir request utama. Untuk kasus ekstrem, dipertimbangkan precomputed tiles atau vector tiles. ### Keamanan Aplikasi - Input Validation: Seluruh input divalidasi tipe, panjang, dan format. Hanya tipe MIME/ekstensi yang diizinkan untuk unggahan. - Output Encoding: Respons HTML (jika ada) di-escape; untuk JSON sudah diasumsikan data, namun tetap dibersihkan dari karakter kontrol berbahaya. - Session/Token: Cookie diberi atribut `HttpOnly` dan `Secure` pada HTTPS. Untuk token, gunakan expiry dan rotasi berkala. - Least Privilege: Kredensial database dibatasi haknya; direktori upload tidak dieksekusi; file permission minimal (`644` untuk file, `755` untuk direktori) dengan kepemilikan `www-data`. ### Standar Data & Interoperabilitas - Format: GeoJSON, CSV, XLSX, PDF sebagai format keluaran resmi; Shapefile dapat didukung melalui konversi. - Koordinat: WGS84 (EPSG:4326) sebagai standar tampilan; transformasi koordinat dilakukan di server bila diperlukan. - Metadata: Setiap layer menyertakan informasi sumber, tanggal pembaruan, penanggung jawab, dan status validasi (pending/verified/final_approved). ### Manajemen Versi dan Lingkungan - Versi Aplikasi: Penomoran rilis mengikuti semantik sederhana (major.minor.patch). Catatan rilis mencantumkan perubahan fitur, skema database, dan migrasi. - Lingkungan: Minimal terdapat `production` dan `staging`. Perubahan signifikan diuji di staging sebelum diangkat ke production. - Konfigurasi Rahasia: Variabel sensitif (kunci, password DB) disimpan di file konfigurasi yang tidak dipublikasikan dan hak aksesnya dibatasi. ### Alat Bantu Geospasial - Validasi & Perbaikan: Skrip server membantu memperbaiki GeoJSON umum (misal ring terbalik, properti wajib hilang, atau fitur di luar batas wilayah) agar konsisten sebelum dipublikasikan. - Batas Administratif: Layer batas desa/kecamatan resmi dipakai sebagai referensi untuk clipping/validasi sehingga data tidak keluar dari area Kabupaten Lebak. ### Aksesibilitas, i18n, dan UX - Aksesibilitas: Komponen form dan peta diberi label yang dapat dibaca screen-reader seperlunya. Warna legenda dan simbol dipilih agar tetap terbaca pada layar kecil. - i18n: Saat ini bahasa Indonesia; struktur UI disiapkan agar penggantian label/teks mudah bila suatu saat diperlukan bahasa daerah/Inggris. - UX: Waktu muat halaman dijaga ringan; daftar panjang dipaginasi; pencarian/filter disediakan untuk mempercepat temuan informasi. ### Ringkasan Tumpukan teknologi DBANGLE menyatukan PHP + Nginx untuk backend yang solid, PostgreSQL/PostGIS untuk kemampuan spasial yang kuat, serta JavaScript/Leaflet untuk pengalaman peta yang intuitif dan responsif. Flutter melengkapi kebutuhan pengumpulan data lapangan. Dengan praktik DevOps, caching, keamanan berlapis, dan standar interoperabilitas, platform ini siap berkembang dari skala kabupaten menuju provinsi tanpa mengorbankan keandalan dan kualitas data. \n \n ## 6. Skema Data dan GeoJSON ### Tujuan Bab Bab ini menjelaskan rancangan skema data DBANGLE serta standar GeoJSON yang dipakai untuk publikasi dan pertukaran data spasial. Fokusnya pada konsistensi atribut, hubungan antartabel, aturan penamaan, serta validasi agar data akurat, mudah dianalisis, dan ramah interoperabilitas lintas OPD. ### Prinsip Perancangan - Konsistensi: Atribut inti mengikuti penamaan seragam pada semua layer (contoh: `WADMKC`, `WADMKD`, `KODE_DESA`). - Minimalis namun kaya konteks: Atribut wajib terbatas, tetapi metadata menyediakan konteks (sumber, tanggal, penanggung jawab, status). - Terukur: Skema mendukung pertumbuhan data (340+ desa, 28 kecamatan) tanpa mengorbankan performa. - Valid dan dapat diverifikasi: Setiap entri melewati validasi skema dan spasial (geometri valid, berada dalam batas Kabupaten Lebak). ### Entitas Inti di Database (Relasional) 1. Wilayah Administratif - `desa` (id, `kode_desa`, `nama_desa`, `kode_kecamatan`, `geom` Polygon/MultiPolygon) - `kecamatan` (id, `kode_kecamatan`, `nama_kecamatan`, `geom` Polygon/MultiPolygon) 2. Referensi/Tematik - `kategori_peta` (id, `kode`, `nama`, `deskripsi`, `ikon`) - `layer_tematik` (id, `slug`, `nama`, `kategori_kode`, `tipe_geom` Point/LineString/Polygon, `skema_properties` jsonb) 3. Fitur Tematik (contoh: jembatan, poskamling, sawah) - `fitur_tematik` (id, `layer_slug`, `kode_desa`, `kode_kecamatan`, `properties` jsonb, `geom` geometry, `status_validasi` enum: pending/verified/final, `created_at`, `updated_at`, `source`) 4. Metadata dan Audit - `metadata_layer` (layer_slug, `sumber`, `versi`, `tanggal_pembaruan`, `kontak`, `lisensi`) - `audit_log` (id, `entitas`, `aksi`, `id_entitas`, `user_id`, `keterangan`, `waktu`) Relasi kunci: `fitur_tematik.layer_slug → layer_tematik.slug`; `fitur_tematik.kode_desa → desa.kode_desa`; `desa.kode_kecamatan → kecamatan.kode_kecamatan`. ### Standar GeoJSON di DBANGLE DBANGLE mempublikasikan data spasial dalam format GeoJSON dengan dua bentuk umum: - FeatureCollection berisi Point (contoh: pos kamling, rumah, fasilitas) - FeatureCollection berisi Polygon/MultiPolygon (contoh: pesawahan, batas administrasi) Semua berkas wajib UTF-8, CRS WGS84 (EPSG:4326), dan mengikuti struktur berikut. #### Struktur Umum ```json { "type": "FeatureCollection", "name": "nama_layer_atau_dataset", "features": [ { "type": "Feature", "properties": { /* lihat skema properties */ }, "geometry": { /* Point/Polygon/MultiPolygon */ } } ], "metadata": { "sumber": "DPMD Lebak / OPD terkait", "tanggal_pembaruan": "2025-09-15", "status": "verified | final", "versi": "1.0", "kontak": "admin@dbangle.id" } } ``` #### Properti Wajib (Semua Layer) - `WADMKC`: Nama kecamatan (string) - `WADMKD`: Nama desa (string) - `KODE_KEC`: Kode kecamatan (string) - `KODE_DESA`: Kode desa (string) - `FTYPE`: Kode/jenis fitur (contoh: `poskamling`, `jembatan`, `sawah`) - `NAMOBJ`/`NAMMAP`: Nama objek jika ada (opsional untuk titik tematik) #### Properti Opsional (Per Layer) - Poskamling: `JENIS`, `STATUS`, `PETUGAS`, `WAKTU_JAGA` - Jembatan: `BAHAN`, `PANJANG`, `LEBAR`, `KONDISI`, `TAHUN` - Sawah (Point): `LUAS_M2` (jika tersedia), `IRIGASI` (boolean/string) - Pesawahan (Polygon): `LUAS_HA`, `KOMODITAS`, `IRIGASI` Semua properti tambahan disarankan huruf besar dengan `_` sebagai pemisah, nilai numerik memakai titik sebagai desimal, dan satuan dicantumkan pada nama kolom jika perlu (`LUAS_M2`, `PANJANG_M`). ### Contoh Skema Properties ```json { "WADMKC": "Banjarsari", "WADMKD": "BINTANGSARI", "KODE_KEC": "360225", "KODE_DESA": "3602042015", "FTYPE": "jembatan", "NAMOBJ": "Jembatan Cibogo", "BAHAN": "Beton", "PANJANG_M": 24.5, "LEBAR_M": 3.5, "KONDISI": "Baik", "TAHUN": 2021 } ``` ### Contoh GeoJSON - Point (Poskamling): ```json { "type": "Feature", "properties": { "WADMKC": "Bayah", "WADMKD": "SAKETI", "KODE_KEC": "360230", "KODE_DESA": "3602302001", "FTYPE": "poskamling", "NAMOBJ": "Pos Kamling RT 03" }, "geometry": { "type": "Point", "coordinates": [106.26491, -6.95012] } } ``` - MultiPolygon (Pesawahan): ```json { "type": "Feature", "properties": { "WADMKC": "Cikulur", "WADMKD": "SUKAMAJU", "KODE_KEC": "360210", "KODE_DESA": "3602102003", "FTYPE": "sawah", "LUAS_HA": 12.34, "IRIGASI": "Teknis" }, "geometry": { "type": "MultiPolygon", "coordinates": [ [ [ [106.29,-6.95], [106.30,-6.95], [106.30,-6.94], [106.29,-6.94], [106.29,-6.95] ] ] ] } } ``` ### Aturan Penamaan Berkas dan Lokasi - Direktori publik: `assets/js/final_approved/` untuk berkas final; `assets/js/pending/` untuk menunggu verifikasi; `assets/js/verified/` untuk tahap menengah. - Pola nama: `deskripsi_layer_YYYYMMDDHHMMSS.json` atau `desa_{WADMKD}_{KODE_DESA}.geojson` untuk batas administratif. - Nama bebas spasi; gunakan huruf kecil dan `_` sebagai pemisah. Hindari karakter khusus. ### Validasi Data 1. Validasi Skema - Periksa keberadaan properti wajib (`WADMKC`, `WADMKD`, `KODE_DESA`, `FTYPE`). - Tipe data: angka untuk ukuran/panjang/luas, string untuk nama/kode. - Nilai enumerasi (mis. `KONDISI`: Baik/Sedang/Rusak) sesuai kamus data. 2. Validasi Spasial - Geometri valid (tidak self-intersect, ring tertutup untuk Polygon). - Koordinat berada dalam batas `Kabupaten Lebak` (intersect dengan layer batas). - Untuk layer Polygon sawah: area > 0 dan tidak keluar dari batas desa terkait (`KODE_DESA`). 3. Validasi Konsistensi - `KODE_DESA` harus cocok dengan `WADMKD` berdasarkan tabel referensi. - Duplikasi titik/fitur dicegah melalui kunci gabungan (`layer_slug`, `KODE_DESA`, `NAMOBJ`). ### Versi Data dan Status - Status alir: `pending → verified → final`. - Setiap perubahan besar menaikkan `metadata.versi` dan `tanggal_pembaruan`. - Riwayat perubahan dicatat di `audit_log` dan pada komentar pull data (bila ada proses PR internal). ### Ukuran Berkas dan Praktik Baik - Batasi ukuran per berkas ≤ 5–10 MB untuk performa browser; untuk dataset besar, pecah per kecamatan/desa. - Sederhanakan geometri (simplify) dengan toleransi kecil tanpa mengubah makna spasial. - Gunakan `number` untuk nilai numerik; hindari string numerik. ### Interoperabilitas dan Konversi - Ekspor ke CSV/XLSX menyertakan kolom koordinat (untuk Point) atau centroid (untuk Polygon). Untuk Shapefile, gunakan konversi server-side saat dibutuhkan. - Semua layer disajikan via API daftar berkas (`api/get_tema_files.php?tema=...`) agar aplikasi pihak ketiga mudah mengonsumsi. ### Contoh Pemeriksaan Otomatis (Server) - Struktur: periksa `type`, `features`, dan setiap `Feature` memiliki `properties` dan `geometry`. - Batas: intersect dengan `desalebak.geojson`; fitur di luar area di-drop atau ditandai `OUT_OF_BOUNDS` untuk ditinjau. - Statistik ringkas: jumlah fitur per kecamatan/desa, luas total (Polygon), dan sebaran kualitas data (missing fields). ### Penutup Dengan skema data yang konsisten dan standar GeoJSON yang jelas, DBANGLE memastikan data yang diterbitkan dapat diandalkan, mudah dipakai ulang, dan siap dianalisis lintas sektor. Pendekatan ini mendukung One Map Policy, meningkatkan kualitas keputusan berbasis data, serta memperkuat kolaborasi pemerintah dan masyarakat. \n \n ## 7. Sumber Data, ETL, dan QA ### Ikhtisar Bab ini menguraikan sumber data utama yang dimanfaatkan DBANGLE, proses ETL (Extract–Transform–Load) untuk menstandarkan dan membersihkan data, serta mekanisme Quality Assurance (QA) yang memastikan akurasi, konsistensi, dan keterlacakan. Tujuan akhirnya adalah menyediakan data geospasial dan non-geospasial yang siap pakai untuk perencanaan, analisis, dan publikasi publik. ### Sumber Data Utama 1. Data Administratif - Batas desa/kecamatan (resmi Pemkab/Big Data Kemendagri bila tersedia) - Kode wilayah (kecamatan, desa) dan referensi nama baku 2. Data Kependudukan dan Sosial - Statistik penduduk (jumlah, usia, pendidikan, pekerjaan) - Fasilitas publik (kesehatan, pendidikan, ibadah, pasar, poskamling) 3. Data Infrastruktur dan Lingkungan - Jaringan jalan, jembatan, sarana air bersih, irigasi - Area rawan bencana (banjir, longsor) dan tutupan lahan/sawah 4. Data Survei Lapangan (Android) - Titik/area hasil pengumpulan oleh surveyor desa (foto, koordinat, catatan) - Status verifikasi bertahap (pending → verified → final) 5. Data Eksternal - Cuaca/iklim (BMKG), harga komoditas (Dinas Perdagangan), dan sumber terbuka (OpenStreetMap) dengan atribusi yang sesuai. ### Prinsip Pengelolaan Sumber Data - Legal dan berlisensi jelas; menyertakan atribusi pada publikasi - Konsisten antar tahun versi dan lintas OPD - Data sensitif dilindungi dan hanya dirilis dalam bentuk agregat bila diperlukan - Dokumen metadata wajib: sumber, tanggal, penanggung jawab, cakupan, batasan pemakaian ### Alur ETL (Extract–Transform–Load) 1. Extract (E) - Ambil data dari file unggahan (GeoJSON/CSV/XLSX), API eksternal, atau basis data. - Gunakan skrip server untuk mengarsipkan berkas asli sebelum diproses (traceability). 2. Transform (T) - Standarisasi kolom: normalisasi penamaan (huruf besar + underscore), casting tipe (angka, string, boolean), penambahan kolom wajib (`WADMKC`, `WADMKD`, `KODE_DESA`, `FTYPE`). - Pembersihan geometri: validasi, perbaikan ring, simplify ringan jika perlu, dan clipping ke batas Kabupaten Lebak/desa. - Enrichment: join dengan referensi wilayah, hitung luas/centroid, isi nilai default yang hilang sesuai kamus data. 3. Load (L) - Simpan ke staging database/tabel sementara untuk QA. - Setelah lulus QA, ekspor ke GeoJSON final dan taruh pada `assets/js/final_approved/` disertai metadata. ### Pipeline Teknis - Penjadwalan: cron atau workflow manual terkontrol saat ada batch unggahan besar - Skrip utilitas: PHP untuk validasi cepat, Python opsional untuk transformasi berat (geopandas) bila diperlukan - Struktur direktori: `uploaded/` (mentah) → `pending/` (siap review) → `verified/` (lulus verifikasi) → `final_approved/` (rilis) - Penamaan versi: suffix timestamp `YYYYMMDDHHMMSS` untuk memudahkan rollback ### Quality Assurance (QA) 1. QA Skema - Cek properti wajib, tipe data, isi enumerasi, dan nilai null yang tidak diizinkan - Laporan ringkas jumlah fitur, kolom hilang, dan distribusi nilai 2. QA Spasial - Validasi geometri (no self-intersection, polygon closed) - Intersect dengan batas Lebak; fitur di luar area ditandai untuk dibuang/ditinjau - Konsistensi `KODE_DESA` dengan geometri (majority area di dalam desa yang sama) 3. QA Konsistensi dan Duplikasi - Kunci unik per layer (mis. `layer_slug + KODE_DESA + NAMOBJ`) - Deduplication heuristik untuk titik yang sangat berdekatan 4. QA Visual - Render sampel layer di peta uji, periksa simbol/label/legend dan popup - Cek performa (waktu muat, jumlah fitur per halaman/peta) ### Kamus Data Ringkas (Contoh) - `WADMKC` (string): Nama kecamatan - `WADMKD` (string): Nama desa - `KODE_KEC` (string): Kode kecamatan - `KODE_DESA` (string): Kode desa; prefiks nama desa dapat dipertahankan untuk konsistensi UI - `FTYPE` (string): Jenis fitur (poskamling, jembatan, sawah, fasilitas_kesehatan, dll.) - `LUAS_HA` (number): Luas hektar (Polygon) - `PANJANG_M`/`LEBAR_M` (number): Dimensi (jembatan/jalan) - `KONDISI` (enum): Baik/Sedang/Rusak (jembatan/jalan) ### Contoh Checklist QA Otomatis - [ ] Berkas UTF-8, CRS WGS84 - [ ] `type=FeatureCollection`, setiap `Feature` memiliki `properties` dan `geometry` - [ ] Properti wajib lengkap (`WADMKC`, `WADMKD`, `KODE_DESA`, `FTYPE`) - [ ] Geometri valid; Polygon tertutup; MultiPolygon tidak punya ring terbalik - [ ] Intersect dengan batas Lebak; buang fitur out-of-bounds - [ ] Nilai numerik bertipe number, bukan string - [ ] Metadata (sumber, tanggal_pembaruan, versi) terisi ### Tanggung Jawab dan Alur Persetujuan - Surveyor Desa: ekstraksi lapangan, unggah berkas mentah, lengkapi atribut - Admin Kecamatan: review awal, minta perbaikan jika atribut/koordinat bermasalah - Admin Kabupaten: validasi final, pengesahan metadata, publikasi - OPD Terkait: memberi masukan domain-spesifik (kamus data, rentang nilai wajar) ### Laporan ETL/QA Setiap batch ETL menghasilkan ringkasan: jumlah berkas, total fitur, jumlah perbaikan, fitur dibuang (beserta alasan), dan tautan berkas final. Laporan disimpan di `logs/` dan dapat dikirimkan sebagai notifikasi ke pengelola melalui email internal. ### Praktik Baik - Pisahkan data sensitif; terbitkan agregat bila perlu - Gunakan batas referensi resmi; hindari data luar area - Pecah dataset besar per kecamatan untuk kinerja - Terapkan standar penamaan file dan properti secara disiplin ### Penutup Dengan ETL yang disiplin dan QA berlapis, DBANGLE menjaga mutu data lintas siklus hidupnya—dari unggah lapangan hingga publikasi. Hasilnya adalah peta tematik yang akurat, konsisten, dan andal untuk mendukung perencanaan dan kolaborasi lintas OPD dan masyarakat. \n \n ## 8. Struktur Folder dan Penamaan ### Tujuan Bab Memberikan standar struktur direktori dan konvensi penamaan pada proyek DBANGLE agar pengembangan rapi, mudah dipahami lintas tim/OPD, meminimalkan konflik, serta memudahkan otomasi (deploy, backup, ETL, dan audit). ### Prinsip Umum - Sederhana dan konsisten: pola yang sama diulang pada modul berbeda. - Dapat diaudit: file sensitif dikelompokkan dan hak aksesnya tegas. - Terukur: siap menampung data/fitur baru tanpa merombak besar. - Ramah CI/CD dan backup: jalur direktori jelas untuk seleksi arsip. ### Struktur Direktori Tingkat Atas (Web Root `/var/www/dbangle`) ``` /var/www/dbangle ├── admin/ # Panel administrasi (kabupaten/kecamatan/desa) ├── api/ # REST-like endpoints (v1, util) │ └── v1/ │ ├── auth/ # login, logout, token │ └── desa/ # unggah/verifikasi Android, daftar berkas tematik ├── assets/ # Aset publik (css/js/img/data) │ ├── css/ │ ├── js/ │ │ ├── final_approved/ # GeoJSON/JSON siap tayang (final) │ │ ├── verified/ # lulus verifikasi (tahap menengah) │ │ ├── pending/ # antrian review │ │ ├── uploaded/ # mentah hasil unggah │ │ └── batas/ # batas administratif referensi │ └── img/ ├── docs/ # Dokumentasi (viewer HTML & per-bab .md.txt) │ └── kopi/ ├── includes/ # helper, keamanan, koneksi, utilitas PHP ├── config/ # konfigurasi aplikasi & database ├── scripts/ # skrip ETL/QA/maintenance (PHP/SH) ├── database/ # skema SQL & migrasi ├── uploads/ # unggahan non-GeoJSON (foto, lampiran) ├── public/ # file publik tambahan (pdf/html) └── vendor/ # dependency composer (jika ada) ``` Catatan: - Folder `assets/js/*` adalah jalur baku untuk data peta yang dikonsumsi frontend. Tahap data digambarkan oleh nama folder (uploaded→pending→verified→final_approved). - Folder `docs/` berisi viewer HTML yang menarik berkas `.md.txt` agar tidak diblokir server. ### Struktur Khas Modul Admin ``` admin/ ├── index.php ├── includes/ (khusus admin) ├── kabupaten/ ├── kecamatan/ └── desa/ ``` - Setiap submodul memiliki halaman daftar, detail, aksi (approve/reject), dan ekspor. ### Struktur API v1 ``` api/ └── v1/ ├── auth/ │ ├── login.php │ └── logout.php └── desa/ ├── verifikasi_peta_android.php ├── daftar_berkas.php └── ... ``` - Semua endpoint mengembalikan JSON dengan skema `{ success, message, data }`. - Penamaan endpoint pakai kata kerja/obyek singkat, huruf kecil, underscore. ### Konvensi Penamaan Berkas GeoJSON/JSON - Huruf kecil, gunakan `_` sebagai pemisah; tanpa spasi/karakter khusus. - Sertakan konteks: tema, wilayah, waktu. - Pola umum: `tema_kodewilayah_YYYYMMDDHHMMSS.json` - Contoh: `jembatan_3602042015_20250801145241.json` - Untuk batas administrasi: `desa_{WADMKD}_{KODE_DESA}.geojson` - File besar dipecah per kecamatan/desa agar ringan dimuat. ### Konvensi Penamaan Atribut (properties) - UPPER_SNAKE_CASE untuk kolom: `WADMKC`, `WADMKD`, `KODE_KEC`, `KODE_DESA`, `FTYPE`, `NAMOBJ`. - Satuan ditulis di nama kolom bila perlu: `PANJANG_M`, `LEBAR_M`, `LUAS_HA`. - Nilai enumerasi konsisten: contoh `KONDISI` → `Baik|Sedang|Rusak`. - Kolom opsional tetap terdokumentasi dalam kamus data per layer. ### Penamaan Endpoint dan Parameter - Endpoint: huruf kecil + underscore, mencerminkan aksi. - `api/v1/desa/verifikasi_peta_android.php` - Parameter JSON/GET: huruf kecil + underscore, kebanyakan `snake_case`. - `kode_desa`, `pin`, `tema`, `since`, `limit`. ### Penamaan Halaman Peta - Halaman publik bertema: `peta_{tema}.php` - `peta_jembatan.php`, `peta_sawah.php`, `peta_poskamling.php` - Halaman agregat: `satu_peta_lebak.php` sebagai direktori peta tematik. ### Struktur Skrip & Otomasi ``` scripts/ ├── cleanup_disk.php # hapus cache lama, arsip ├── etl_validate_geojson.php # validasi struktur dan atribut ├── count_status_from_html.php └── ... ``` - Semua skrip diberi komentar singkat di header (tujuan, input, output). - Nama skrip diawali kata kerja: `etl_`, `cleanup_`, `count_`, `backup_`. ### Hak Akses dan Kepemilikan - File: `644`, Direktori: `755`, Pemilik: `www-data:www-data` untuk konten web. - Direktori upload tidak dieksekusi; hanya baca/tulis sesuai kebutuhan. - `config/` berisi kredensial: batasi pembacaan ke user aplikasi. ### Contoh Jalur Data (End-to-End) 1. Aplikasi Android unggah GeoJSON → `assets/js/uploaded/tema_timestamp.json`. 2. Admin kecamatan review → pindah ke `assets/js/pending/`. 3. QA otomatis + clipping ke batas → `assets/js/verified/`. 4. Admin kabupaten finalisasi + metadata → `assets/js/final_approved/`. 5. Frontend memuat dari daftar berkas (API/manifest) sesuai kategori. ### Versi, Arsip, dan Rollback - Penamaan bersufiks timestamp memudahkan pelacakan & rollback. - Arsip harian: kompres folder `assets/js/final_approved/` ke `/backup/` dengan cap waktu. - Catat changelog ringkas (apa yang berubah, alasan, siapa menyetujui) di `logs/`. ### Anti-duplikasi dan Kebersihan Direktori - Gunakan hash sederhana (md5 isi file) untuk mencegah unggahan ganda. - Jalankan `scripts/cleanup_disk.php` terjadwal untuk menyingkirkan berkas sementara/lama. ### Dokumentasi dan Viewer - Semua dokumen Markdown disalin sebagai `.md.txt` untuk menghindari blokir server. - Viewer `docs/kopi/index.html` memuat daftar bab dari `manifest.json`. - Setiap perubahan besar pada struktur/konvensi wajib tercermin di dokumentasi ini. ### Ringkasan Dengan struktur folder yang jelas dan penamaan konsisten, DBANGLE memudahkan tim mengelola siklus hidup data peta dari unggah hingga publikasi. Konvensi bersama mengurangi miskomunikasi, mempercepat otomasi, dan mempermudah audit, sehingga kualitas layanan publik tetap terjaga meski skala data dan jumlah pemangku kepentingan bertambah. \n \n ## 9. Konfigurasi Server (Nginx, PHP-FPM, Sistem) ### Tujuan Bab Memberikan pedoman konfigurasi server web agar DBANGLE stabil, aman, dan siap melayani unggahan/akses data geospasial. Fokus pada Nginx, PHP-FPM, batas unggahan, header keamanan, CORS, serta praktik sistem (hak akses, log, backup). ### Arsitektur Singkat - OS: Ubuntu Server LTS - Web: Nginx → PHP-FPM (FastCGI) - DB: PostgreSQL + PostGIS (server terpisah atau satu mesin) - Penyimpanan data peta: direktori `assets/js/...` (read-only untuk publik) ### Nginx: Blok Server Dasar ``` server { listen 80; server_name dbangle.id; # redirect ke https (jika TLS aktif) return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name dbangle.id; root /var/www/dbangle; index index.php index.html; # Sertifikat TLS (contoh Let’s Encrypt) ssl_certificate /etc/letsencrypt/live/dbangle.id/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/dbangle.id/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; # Batas unggah & timeout client_max_body_size 100M; # umum fastcgi_read_timeout 600s; fastcgi_send_timeout 600s; # Header keamanan add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Content-Type-Options "nosniff" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header X-XSS-Protection "1; mode=block" always; # CSP minimal (sesuaikan sesuai kebutuhan aset) add_header Content-Security-Policy "default-src 'self' https: data: 'unsafe-inline' 'unsafe-eval'" always; # CORS untuk API (opsional, per lokasi) location ^~ /api/ { add_header Access-Control-Allow-Origin "*" always; add_header Access-Control-Allow-Methods "GET, POST, OPTIONS" always; add_header Access-Control-Allow-Headers "Content-Type, Authorization" always; if ($request_method = OPTIONS) { return 204; } try_files $uri =404; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/run/php/php8.1-fpm.sock; } # Lokasi admin (bisa pakai batas unggah lebih besar) location ^~ /admin/ { client_max_body_size 100M; try_files $uri $uri/ /admin/index.php?$args; } # PHP umum location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.1-fpm.sock; } # File statis location ~* \.(?:css|js|png|jpg|jpeg|webp|svg|ico|json|geojson)$ { expires 7d; add_header Cache-Control "public, max-age=604800"; try_files $uri =404; } } ``` Catatan: - Sesuaikan `php8.1-fpm.sock` dengan versi PHP yang terpasang. - Jika `.md` diblokir, gunakan pasangan `.md.txt` untuk viewer dokumen (sudah diterapkan di DBANGLE). ### PHP-FPM dan php.ini - `upload_max_filesize = 100M` - `post_max_size = 100M` - `max_execution_time = 300` - `max_input_time = 300` - `memory_limit` minimal 256M (sesuaikan beban ekspor/ETL) - `date.timezone = Asia/Jakarta` Setelah mengubah, lakukan `systemctl reload php8.1-fpm` dan `systemctl reload nginx`. ### Hak Akses, Kepemilikan, dan Izin - Pemilik konten web: `www-data:www-data` - File: `644`, Direktori: `755` - Direktori upload (foto/mentah): tidak dieksekusi; batasi list-dir bila perlu - Simpan rahasia (kredensial DB) di `config/` dengan izin baca terbatas ### Struktur Log - Nginx: `/var/log/nginx/access.log`, `/var/log/nginx/error.log` - Aplikasi: `/var/www/dbangle/logs/security_report.log` (contoh), log ETL/QA di `logs/` - Rotasi log: aktifkan `logrotate` untuk mencegah penuhnya disk ### Keamanan Tambahan - Rate limiting sederhana pada endpoint sensitif (login/upload) - Validasi ketat tipe/ukuran file unggahan (hanya JSON/GeoJSON untuk layer spasial) - Nonaktifkan eksekusi di folder data: buat file `.htaccess` (jika Apache) atau atur Nginx untuk hanya melayani statis - Audit rutin: cek file baru dan perubahan izin yang tidak semestinya ### Kinerja dan Cache - `sendfile on;` dan `gzip` untuk aset teks (css, js, json) - Gunakan `ETag`/`Last-Modified` untuk JSON peta bila diperlukan - Pecah dataset besar per wilayah untuk menghindari payload jumbo ### Backup dan Pemulihan - Database: dump harian (pg_dump), simpan di tempat terpisah dan terenkripsi jika sensitif - Aset peta final: arsip periodik `assets/js/final_approved/` ke `/backup/` - Uji pemulihan minimal bulanan ### Monitoring - Periksa `5xx` surges, waktu respons >1 detik, dan lonjakan bandwidth - Health-check sederhana: `curl -f https://dbangle.id/api/performance.php` - Integrasi opsional: Prometheus/Grafana atau UptimeRobot untuk notifikasi ### Prosedur Rilis Aman 1. Siapkan berkas di direktori sementara (mis. `/tmp/release_xxx`) 2. Pindahkan secara atomik (`mv`) ke lokasi final 3. `chown -R www-data:www-data` dan set izin 4. Uji URL kunci dan log error; rollback bila ada anomali ### Troubleshooting Singkat - 403 pada halaman peta: cek anti-view-source/WAF lokal atau izin file; pastikan tidak memblokir `peta_*.php` - 413 saat unggah GeoJSON: tingkatkan `client_max_body_size`, `upload_max_filesize`, `post_max_size` - 404 API: pastikan `location` Nginx mengarah ke PHP-FPM dan file ada - Timeout export: tingkatkan `fastcgi_read_timeout` dan `max_execution_time` ### Penutup Konfigurasi server yang disiplin memastikan DBANGLE stabil, cepat, dan aman. Pedoman ini dapat dijadikan baseline dan disesuaikan dengan kebutuhan skala kabupaten maupun rencana ekspansi ke tingkat provinsi. \n \n ## 10. Konfigurasi Aplikasi ### Tujuan Bab Memberikan pedoman konfigurasi aplikasi DBANGLE di level kode (PHP/JS) agar konsisten antara lingkungan, aman secara default, dan mudah dirawat. Bab ini melengkapi Bab 09 (server) dengan fokus pada berkas konfigurasi, variabel lingkungan, kredensial, opsi peta (Leaflet), batas unggah, logging aplikasi, dan fitur-fitur pengaman. ### 1) Berkas dan Lokasi Konfigurasi - `config/app.php` — pengaturan umum aplikasi (BASE_URL, mode debug, timezone, fitur UI) - `config/database_app.php` — kredensial database aplikasi utama (PDO MySQL/PostgreSQL) - `config/database_secure.php` — koneksi terproteksi/khusus (akses terbatas) - `includes/` — helper keamanan, anti-view-source (opsional), pembungkus PDO, utilitas JSON - `admin/includes/` — konfigurasi spesifik panel admin jika diperlukan Rekomendasi: Pisahkan rahasia (password DB, secret key) dari repo publik. Bila tidak menggunakan `.env`, simpan di `config/` dengan izin baca terbatas untuk user web (`www-data`). ### 2) Variabel Dasar Aplikasi - BASE_URL: `https://dbangle.id` (sesuaikan staging/production) - API_BASE: `https://dbangle.id/api/v1` - TIMEZONE: `Asia/Jakarta` - DEBUG: `false` di production (aktifkan `true` hanya di staging/dev) - SECURITY_HEADERS: `true` untuk menambahkan header keamanan via PHP (opsional, utamanya di Nginx) Contoh cuplikan `config/app.php`: ```php return [ 'base_url' => 'https://dbangle.id', 'api_base' => 'https://dbangle.id/api/v1', 'timezone' => 'Asia/Jakarta', 'debug' => false, 'security_headers' => true, 'uploads' => [ 'geojson_max_mb' => 100, 'image_max_mb' => 10, 'allowed_geo' => ['application/json','application/geo+json','application/octet-stream'], 'allowed_img' => ['image/jpeg','image/png','image/webp'] ], 'docs' => [ 'use_md_txt' => true ] ]; ``` ### 3) Database dan Koneksi Aman - Gunakan PDO dengan prepared statements pada semua query. - Mode error: `PDO::ERRMODE_EXCEPTION` agar kesalahan tertangkap jelas di log. - Set `charset`/`client_encoding` ke UTF-8. - Batasi user DB hanya pada hak yang diperlukan (least privilege). Contoh koneksi ringkas: ```php $pdo = new PDO($dsn, $user, $pass, [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, PDO::ATTR_EMULATE_PREPARES => false, ]); ``` ### 4) Session, Auth, dan Token - Session diaktifkan pada halaman admin; cookie `HttpOnly` dan `Secure` (HTTPS). - Token sederhana untuk API v1 dapat disimpan di tabel `users`/`tokens` dengan masa berlaku. - Rate limit login per IP/kode_desa untuk mencegah brute force. ### 5) Konfigurasi Peta (Leaflet) - Basemap: OSM/Esri Satellite/Esri Topo. Simpan daftar URL tile, attribution, dan batas default. - Bounds Lebak: gunakan bounding box untuk `fitBounds()` awal; opsi `maxBounds` dapat diaktifkan jika dataset mengambang. - Legend/Styling: warna per kategori ditentukan di satu tempat (mapping FTYPE → style). Contoh konfigurasi JS (inline atau file `assets/js/map.config.js`): ```js const LEBAK_BOUNDS = [[-7.2,106.0],[-6.4,106.7]]; const BASEMAPS = { osm: L.tileLayer('https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {maxZoom:19, attribution:'© OSM'}), esriSat: L.tileLayer('https://server.arcgisonline.com/ArcGIS/rest/services/World_Imagery/MapServer/tile/{z}/{y}/{x}', {maxZoom:19, attribution:'Esri'}) }; const STYLE_BY_FTYPE = { jembatan: {color:'#1d4ed8', weight:2, fillOpacity:0.2}, poskamling: {color:'#16a34a', radius:6}, sawah: {color:'#22c55e', weight:1, fillOpacity:0.3}, default: {color:'#0ea5e9'} }; ``` ### 6) Batas Unggah & Validasi Berkas - Validasi sisi server: tipe MIME, ukuran maksimum, dan struktur GeoJSON. - Penempatan folder sesuai tahap: `uploaded/ → pending/ → verified/ → final_approved/`. - Sanitasi nama file: huruf kecil, `_`, tanpa spasi/karakter khusus. - Jalankan validasi atribut minimal (`WADMKC`, `WADMKD`, `KODE_DESA`, `FTYPE`). ### 7) Logging Aplikasi - Lokasi: `/var/www/dbangle/logs/*.log` (akses dibatasi) - Format: `[timestamp] [level] [user/ip] pesan | context(json)` - Peristiwa dicatat: login gagal/berhasil, unggah berkas, verifikasi, rilis final. ### 8) Konfigurasi Anti View Source & WAF Aplikasi (Opsional) - Anti View Source: hindari memblokir halaman publik `peta_*.php` (pelajaran dari 403 sebelumnya). Jika aktif, whitelist pola `peta_`, `public_`, `handbook_`. - WAF sederhana: filter pola berbahaya di input, aktifkan hanya yang tidak mengganggu lalu lintas sah. - Mode debug WAF = off di production. ### 9) Fitur UI Khusus - Pagination tabel default: 10–20 baris/halaman. - Ekspor Excel: aktifkan `XLSX` bila dataset ≤ 10k baris per unduhan (paging server-side untuk lebih besar). - Pencarian/filter: case-insensitive untuk kenyamanan pengguna. ### 10) Manifest Dokumentasi - Viewer dokumentasi memuat `.md.txt` dari `docs/kopi/manifest.json`. - Set `use_md_txt=true` agar tautan otomatis menggunakan ekstensi tersebut. ### 11) Perbedaan Lingkungan - Production: `DEBUG=false`, logging lebih ketat, header keamanan aktif, `.md` diblokir (pakai `.md.txt`). - Staging: dataset subset, `DEBUG=true`, pengujian performa dan keamanan. - Dev: jalankan di port lokal, tanpa data sensitif. ### 12) Checklist Rilis Aplikasi - [ ] Ganti `base_url`, `api_base`, dan `DEBUG=false` - [ ] Periksa izin folder upload & logs - [ ] Uji unggah/validasi GeoJSON > 5MB - [ ] Uji login admin, verifikasi berkas, publikasi final - [ ] Baca log error selama ≥24 jam pascarilis ### 13) Penutup Konfigurasi aplikasi yang konsisten mempercepat pengembangan, meminimalkan regresi, dan meningkatkan keamanan default. Dipadukan dengan konfigurasi server (Bab 09), DBANGLE siap melayani kebutuhan peta dan data geospasial Kabupaten Lebak secara andal dan aman. \n \n ## 11. Keamanan Aplikasi ### Tujuan Bab Menetapkan kebijakan, kontrol, dan praktik keamanan untuk melindungi platform DBANGLE, data geospasial/non-geospasial, serta pengguna. Fokus pada pencegahan (prevent), deteksi (detect), dan respons (respond), dengan prinsip sederhana: secure-by-default, least-privilege, dan auditability. ### 1) Prinsip dan Kebijakan - Secure-by-default: fitur berisiko dinonaktifkan secara default; hanya diaktifkan bila dibutuhkan. - Least Privilege: hak akses minimum untuk akun server, database, dan aplikasi. - Defense-in-Depth: lapisan perlindungan (Nginx, PHP, DB, OS, backup, dan proses operasional). - Privacy-by-Design: data pribadi diminimalkan, dienkripsi saat transit, dan dibatasi aksesnya. - Compliance: selaraskan dengan regulasi nasional terkait data pribadi dan keterbukaan informasi. ### 2) Kontrol Keamanan Server & Jaringan - TLS (HTTPS) wajib untuk seluruh trafik publik dan admin. - Header keamanan di Nginx: X-Frame-Options, X-Content-Type-Options, Referrer-Policy, CSP minimal. - Rate Limiting: terapkan untuk endpoint login dan unggahan. - Isolasi Aset: direktori `assets/js/` hanya untuk file statis; non-eksekusi. - Pembaruan OS: patch rutin; layanan tidak terpakai dinonaktifkan. ### 3) Keamanan Aplikasi (PHP/JS) - Validasi input universal (tipe, panjang, whitelist); semua query memakai prepared statements (PDO). - Sanitasi output HTML; escape konten dinamis (hindari XSS). - CSRF: token untuk aksi sensitif di panel admin. - Autentikasi: login dua tahap (password → PIN) untuk peran desa; sesi `HttpOnly`+`Secure`. - Otorisasi: periksa peran/ruang lingkup (desa/kecamatan/kabupaten) pada setiap aksi. - Upload Aman: - Periksa tipe MIME/ekstensi; batasi ukuran; simpan di folder non-eksekusi. - Ubah nama file aman (lowercase, underscore, timestamp); cek isi JSON/GeoJSON valid. - Lakukan scanning sederhana (pattern blacklist) pada konten teks. ### 4) Keamanan Basis Data - Pengguna DB terbatas per kebutuhan (aplikasi hanya `SELECT/INSERT/UPDATE` tertentu). - Enkripsi koneksi DB (jika lintas host) dan enforce UTF-8. - Indeks & constraint untuk mencegah data tidak konsisten; audit trigger ringan bila perlu. - Backup terenkripsi dan diuji pemulihannya; rotasi kunci/credential berkala. ### 5) Proteksi Data Pribadi - Minimasi koleksi data; hanya simpan yang perlu. - Pseudonimisasi/anonymisasi untuk laporan publik. - Akses data sensitif dibatasi pada admin berwenang; jejak audit. ### 6) Logging, Monitoring, dan Audit - Aplikasi mencatat autentikasi, unggah, verifikasi, perubahan hak akses, dan rilis data. - Log disimpan terpisah dari aset publik; rotasi log aktif. - Alarm sederhana: deteksi lonjakan 4xx/5xx, login gagal beruntun, dan upload gagal beruntun. - Audit berkala: review konfigurasi, izin file, dan paket server. ### 7) Kebijakan Kata Sandi & PIN - Password minimal 8 karakter, kombinasi huruf/angka/simbol. - PIN desa 6 digit; wajib ganti pada login awal; catat tanggal rotasi terakhir. - Penguncian sementara (temporary lockout) setelah percobaan gagal beruntun. ### 8) Manajemen Kerentanan - Inventaris dependensi; review rutin CVE; update berkala. - Pentest ringan: uji injeksi, XSS, upload, dan kontrol akses. - Respons insiden: SOP singkat (identifikasi → contain → eradicate → recover → postmortem). ### 9) Keamanan API - Semua endpoint JSON: validasi parameter; limit paging. - Hindari kebocoran informasi (stack trace) di production; `DEBUG=false`. - CORS diaktifkan hanya untuk rute API yang perlu; enforce `Content-Type: application/json`. ### 10) Keamanan Frontend Map - Hindari menyisipkan HTML tidak tepercaya di popup; gunakan templating aman. - Batasi jumlah fitur per halaman untuk mencegah DoS via data jumbo. - Pemetaan layer besar: gunakan pagination/tiling/cluster; hindari menyimpan rahasia di JavaScript. ### 11) Backup, DR, dan Ketersediaan - Backup DB + aset final harian; simpan off-host. - Uji pemulihan bulanan; dokumentasikan RPO/RTO sederhana. - Rilis atomik untuk menghindari kondisi balapan saat deploy. ### 12) Checklist Keamanan (Operasional) - [ ] HTTPS aktif, sertifikat valid - [ ] Header keamanan aktif (XFO, XCTO, CSP, Referrer-Policy) - [ ] Direktori upload non-eksekusi, izin file/direktori benar - [ ] Upload dibatasi tipe/ukuran dan tervalidasi - [ ] Prepared statements pada semua query - [ ] DEBUG=false di production - [ ] Rate limit login/unggah aktif - [ ] Log diamankan dan rotasi aktif - [ ] Backup terakhir lulus uji restore ### 13) Edukasi dan Proses - Orientasi keamanan bagi admin/surveyor (upload aman, kata sandi kuat, etika data). - SOP insiden singkat tersedia dan dapat dijalankan tim kecil. - Komunikasi internal via kanal resmi; hindari berbagi kredensial lintas personal. ### Penutup Keamanan bukan fitur satu kali, melainkan proses berkelanjutan. Dengan kebijakan jelas, kontrol teknis berlapis, dan disiplin operasional, DBANGLE menjaga kepercayaan publik sekaligus memastikan data yang dipublikasikan aman, akurat, dan dapat dipertanggungjawabkan. \n \n ## 12. Auth, Otorisasi, dan Sesi ### Tujuan Bab Menjelaskan rancangan autentikasi (auth), otorisasi (access control), dan manajemen sesi pada DBANGLE agar aman, sederhana, dan sesuai kebutuhan operasional (desa–kecamatan–kabupaten–OPD). ### Model Peran (Role) - Desa (Surveyor/Admin Desa): unggah dan mengelola data desanya sendiri. - Kecamatan (Verifikator Tahap 1): meninjau data desa dalam wilayah kecamatannya. - Kabupaten (Verifikator Final/Admin): validasi akhir, publikasi, pengaturan sistem. - OPD (Pengguna Data): mengakses data tematik sesuai kewenangan sektor. - Publik (Tanpa login): akses peta dan data publik yang telah final. ### Skema Akun dan Identitas - Identitas utama desa menggunakan `kode_desa` (unik) dan nama desa. - Admin kecamatan dan kabupaten menggunakan akun berbasis username/email. - Atribut akun minimal: `id`, `username`, `nama`, `role`, `kode_desa (opsional)`, `kode_kecamatan (opsional)`, `status`, `created_at`, `last_login`. ### Alur Login (Website) – Opsi Password → PIN (untuk desa) 1. Pengguna mengisi username/kode desa + password. 2. Jika role `desa`, sistem meminta PIN 6 digit. 3. Jika password/PIN valid, buat sesi (session) server-side dan arahkan ke dashboard sesuai peran. Catatan PIN: - Default PIN desa adalah 6 digit terakhir `kode_desa` bila `pin_hash` belum tersedia. - Disarankan mengganti PIN pada login pertama. ### Alur Login (API v1 untuk Android) - Endpoint: `POST /api/v1/auth/login.php` menerima `{kode_desa, pin}`. - Respons: `{success, message, user:{id, kode_desa, nama, role}, token}`. - Token sederhana (signed) berisi `user_id`, `role`, `exp` (masa berlaku singkat, mis. 1–7 hari). ### Penyimpanan Kredensial - Password disimpan dengan `password_hash()` (PHP) menggunakan `PASSWORD_DEFAULT`. - PIN desa disimpan sebagai `pin_hash` terpisah (jika digunakan di web); fallback default diperbolehkan sementara. - Token API tidak disimpan permanen kecuali perlu revokasi; cukup diverifikasi tandatangannya. ### Sesi (Session) di Website - Menggunakan session PHP untuk halaman admin. - Cookie diberi atribut `HttpOnly` dan `Secure` (wajib HTTPS). - Session ID dirotasi setelah login (mitigasi session fixation). - Timeout sesi (idle) 30–60 menit; perpanjang saat aktivitas. ### Otorisasi (Access Control) - Middleware/guard memeriksa: - Apakah pengguna telah login? - Apakah role sesuai untuk rute/aksi? - Apakah ruang lingkup wilayah sesuai? (desa hanya boleh CRUD data miliknya; kecamatan hanya desa di wilayahnya) - Setiap endpoint verifikasi/publikasi memeriksa role dan scope sebelum proses. ### Validasi Input Auth - Normalisasi dan sanitasi input username/kode desa. - Pembatasan percobaan (rate limit) pada login per IP/kode desa. - Logging percobaan gagal dan notifikasi bila melewati ambang. ### Reset Password/PIN - Password: melalui admin kabupaten (atau email jika tersedia); catat di audit log. - PIN: admin desa atau kecamatan dapat meminta reset; sistem menghasilkan PIN sementara yang wajib diganti setelah login. ### Pola Respons API Auth - Berhasil: `200` → `{success:true, message:'Login berhasil', user, token}` - Gagal kredensial: `401` → `{success:false, message:'Kode desa atau PIN salah'}` - Validasi gagal: `400` → `{success:false, message:'Input tidak valid'}` - Gangguan server: `500` → `{success:false, message:'Terjadi kesalahan'}` ### Praktik Keamanan Tambahan - Jangan kirimkan detail spesifik kegagalan (hindari enumerasi akun). - Token API memiliki `exp` pendek dan tanda tangan (HMAC) dengan secret aplikasi. - Logout web menghapus sesi; logout API opsional (client-side wipe token). - Audit login/ubah PIN/ubah password dicatat. ### Contoh Struktur Payload User (API) ```json { "id": 123, "username": "PONDOKPANJANG_3602262004", "nama": "Desa Pondokpanjang", "role": "desa", "kode_desa": "3602262004" } ``` ### Contoh Pseudocode Login (Website) ```php // 1) cek username/password $user = findUserByUsername($username); if(!$user || !password_verify($password, $user['password_hash'])) return error('Salah'); // 2) jika role desa → minta PIN if($user['role']==='desa'){ if(!verify_pin($user, $pin)) return error('PIN salah'); } // 3) buat sesi session_regenerate_id(true); $_SESSION['uid'] = $user['id']; $_SESSION['role'] = $user['role']; $_SESSION['desa'] = $user['kode_desa'] ?? null; log_login_success($user['id']); ``` ### Contoh Pseudocode Verifikasi Scope ```php function ensureScopeDesa(string $kodeDesaRequest){ if($_SESSION['role']==='desa'){ if($_SESSION['desa'] !== $kodeDesaRequest){ http_response_code(403); exit('Akses ditolak'); } } } ``` ### Checklist Implementasi - [ ] Password hash/verify, PIN hash (fallback dihapus saat siap) - [ ] Session secure + rotate + timeout - [ ] Rate limit login, logging event auth - [ ] Guard peran + scope wilayah untuk tiap endpoint sensitif - [ ] Token API bertanda tangan + masa berlaku - [ ] Form dan respons bebas bocoran info sensitif ### Penutup Rancangan auth, otorisasi, dan sesi DBANGLE menyeimbangkan keamanan dan kesederhanaan. Dengan password → PIN untuk desa, token sederhana untuk mobile, dan guard berbasis peran + wilayah, platform tetap mudah digunakan sekaligus terlindungi dari penyalahgunaan. \n \n ## 13. API v1 (Auth, Desa, Peta Tematik) ### Tujuan Bab Menjelaskan desain dan kontrak API v1 DBANGLE yang digunakan aplikasi web dan Android untuk autentikasi, unggah/validasi GeoJSON, serta pengambilan daftar berkas peta tematik. Fokus pada kesederhanaan, konsistensi respons, dan keamanan dasar. ### Prinsip Desain - Konsisten: semua respons JSON memiliki bentuk `{ success, message, data }` atau variasinya. - Idempotensi: operasi baca (GET) aman diulang; operasi tulis (POST) memvalidasi ulang. - Keamanan sederhana: CORS terbatas, validasi input ketat, pagination default, dan tanpa bocoran stack trace. - Versi: seluruh endpoint diawali `/api/v1`. Perubahan mayor akan dipromosikan ke `/api/v2`. ### Otentikasi (Android) - Endpoint: `POST /api/v1/auth/login.php` - Body (JSON): ```json { "kode_desa": "3602262004", "pin": "123456" } ``` - Respons (berhasil): ```json { "success": true, "message": "Login berhasil", "user": { "id": 12, "kode_desa": "3602262004", "nama": "Desa Pondokpanjang", "role": "desa" }, "token": "" } ``` - Kode status: 200 (sukses), 400 (input tak valid), 401 (kredensial salah), 500 (gangguan). - Catatan: Jika `pin_hash` belum tersedia, fallback sementara ke 6 digit terakhir `kode_desa` (segera ganti setelah login awal). ### Otentikasi (Website) - Endpoint (opsional): `POST /api/v1/auth/login_password.php` (jika dipakai untuk web) - Alur: password diverifikasi; jika role `desa`, web meminta PIN 6 digit sebelum membuat sesi. ### Unggah/Verifikasi GeoJSON (Android Desa) - Endpoint: `POST /api/v1/desa/verifikasi_peta_android.php` - Tipe: `multipart/form-data` - Field: - `kode_desa` (string, wajib) - `tema` (string, wajib; contoh: `jembatan`, `poskamling`, `sawah`) - `file` (berkas GeoJSON, wajib) - `meta` (opsional JSON: versi, catatan) - Validasi server: - MIME/ekstensi: hanya JSON/GeoJSON; ukuran sesuai batas server - Struktur: `FeatureCollection` dengan `properties` minimal (`WADMKC`,`WADMKD`,`KODE_DESA`,`FTYPE`) - Spasial: geometri valid; intersect batas Lebak; clipping opsional - Alur simpan: `uploaded/ → pending/ → verified/ → final_approved/` - Respons (contoh): ```json { "success": true, "message": "Berkas diterima dan menunggu verifikasi", "data": { "tema": "sawah", "filename": "sawah_3602262004_20250915094501.json", "status": "pending" } } ``` ### Daftar Berkas Tematik - Endpoint: `GET /api/get_tema_files.php?tema={slug}&status=final&limit=50` - Query: - `tema` (wajib): `jembatan|poskamling|sawah|...` - `status` (opsional, default `final`): `pending|verified|final` - `limit` (opsional, default 50, max 200) - Respons (contoh): ```json { "success": true, "data": [ { "file": "jembatan_3602042015_20250801145241.json", "url": "/assets/js/final_approved/jembatan_3602042015_20250801145241.json", "updated_at": "2025-08-01T14:52:41+07:00", "tema": "jembatan", "style": { "color": "#1d4ed8" } } ] } ``` ### Detail GeoJSON (opsional) - Endpoint: `GET /api/get_geojson_details.php?file=...` - Fungsi: mengembalikan ringkasan (jumlah fitur, kecamatan, desa dominan, luas total) tanpa memuat seluruh data di frontend. ### Kontrak Kesalahan (Error Contract) - Respons 4xx/5xx tidak memaparkan detail server; hanya `message` umum dan `code` internal opsional. - Contoh: ```json { "success": false, "message": "Input tidak valid", "code": "VAL001" } ``` ### Keamanan API - CORS hanya untuk rute `/api/` dan hanya metode `GET, POST, OPTIONS`. - Header keamanan aktif (Nginx) dan `Content-Type: application/json` untuk respons JSON. - Rate limit dasar pada `auth/login.php` dan `desa/verifikasi_peta_android.php`. - Validasi berlapis: skema JSON, struktur GeoJSON, dan batas spasial. ### Pagination dan Batas - Default `limit=50`, `max=200`; dukung `offset`/`page` bila dibutuhkan. - Sortir default `updated_at DESC` untuk berkas tematik. ### Versi dan Depreksi - Perubahan tak kompatibel diumumkan; endpoint lama didepresiasi bertahap dengan periode transisi. ### Contoh Implementasi Klien (JavaScript Fetch) ```js async function getTemaFiles(tema){ const res = await fetch(`/api/get_tema_files.php?tema=${encodeURIComponent(tema)}&status=final&limit=50`, {cache:'no-store'}); if(!res.ok) throw new Error('Gagal memuat'); const data = await res.json(); if(!data.success) throw new Error(data.message || 'Kesalahan API'); return data.data; } ``` ### Checklist API v1 - [ ] Respons JSON konsisten `{success,message,data}` - [ ] Validasi input & batas ukuran berkas - [ ] CORS terbatas + header keamanan aktif - [ ] Pagination pada endpoint daftar - [ ] Logging akses/galat untuk audit ### Penutup API v1 DBANGLE dirancang sederhana agar mudah diadopsi oleh aplikasi internal dan perangkat Android. Dengan kontrak data yang konsisten, validasi berlapis, dan pengendalian performa, layanan siap berkembang mengikuti kebutuhan kabupaten hingga provinsi tanpa mengorbankan stabilitas. \n \n ## 14. Frontend Leaflet UI ### Tujuan Bab Menjabarkan rancangan antarmuka (UI) peta di DBANGLE menggunakan Leaflet.js: struktur halaman, pola komponen, interaksi dasar, performa, aksesibilitas, dan praktik yang telah terbukti stabil di implementasi `peta_jembatan.php`, `peta_poskamling.php`, `peta_sawah.php`, dan `satu_peta_lebak.php`. ### Struktur Halaman Peta - Header ringkas (judul + deskripsi singkat) - Panel filter (kecamatan, desa, kategori/tema) - Kanvas peta (Leaflet map) dalam wadah responsif - Statistik ringkas (kartu total fitur, luas, sebaran kecamatan) - Tabel data (paginated) dan tombol ekspor Layout dasar: ```html
``` ### Inisialisasi Peta ```js const map = L.map('map', { zoomControl:true }); const BASEMAPS = { osm: L.tileLayer('https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {maxZoom:19, attribution:'© OSM'}), esriSat: L.tileLayer('https://server.arcgisonline.com/ArcGIS/rest/services/World_Imagery/MapServer/tile/{z}/{y}/{x}', {maxZoom:19, attribution:'Esri'}) }; BASEMAPS.esriSat.addTo(map); const LEBAK_BOUNDS = [[-7.2,106.0],[-6.4,106.7]]; // perkiraan map.fitBounds(LEBAK_BOUNDS); ``` ### Memuat GeoJSON - Sumber: berkas lokal `assets/js/final_approved/*.json` atau daftar dari `api/get_tema_files.php`. - Pola aman: `fetch(..., {cache:'no-store'})` → cek `res.ok` → `res.json()` → validasi struktur. ```js async function loadGeoJSON(url){ const res = await fetch(url, {cache:'no-store'}); if(!res.ok) throw new Error('Gagal memuat'); return res.json(); } ``` ### Rendering Fitur - Point: gunakan `L.circleMarker` agar konsisten skala; radius berdasarkan kategori atau kepadatan. - Polygon/MultiPolygon: `L.geoJSON` dengan `style` per `FTYPE`. - Popup: templating aman (escape) dan memuat kolom utama: `NAMOBJ/NAMMAP`, `WADMKD`, `WADMKC`, `FTYPE`. ```js function styleByFTYPE(props){ const mapStyle = { jembatan: {color:'#1d4ed8', weight:2, fillOpacity:0.15}, poskamling:{color:'#16a34a', weight:1, fillOpacity:0.15}, sawah: {color:'#22c55e', weight:1, fillOpacity:0.25}, default: {color:'#0ea5e9', weight:1, fillOpacity:0.2} }; return mapStyle[props.FTYPE] || mapStyle.default; } function pointToLayer(feature, latlng){ return L.circleMarker(latlng, { radius:6, ...styleByFTYPE(feature.properties) }); } function onEachFeature(feature, layer){ const p = feature.properties||{}; const html = `${(p.NAMOBJ||p.NAMMAP||'-')}
`+ `Desa: ${p.WADMKD||'-'}
`+ `Kec.: ${p.WADMKC||'-'}
`+ `Jenis: ${p.FTYPE||'-'}`; layer.bindPopup(html); } ``` ### Filter Kecamatan/Desa - Dropdown diisi dari daftar unik `WADMKC`/`WADMKD` pada data. - Filter dilakukan sebelum render ulang layer; atau dengan `setFilter` sederhana pada koleksi fitur. ```js function filterFeature(f){ if(selectedKec && f.properties.WADMKC!==selectedKec) return false; if(selectedDesa && f.properties.WADMKD!==selectedDesa) return false; return true; } ``` ### Tabel dan Interaksi Marker - Simpan referensi `featureId → layer` dalam `Map` JavaScript. - Klik baris tabel → panggil `layer.openPopup()` dan `map.panTo(layer.getLatLng())` (untuk point). - Untuk polygon, gunakan `layer.getBounds()` dan `map.fitBounds(...)`. ### Legenda dan Kontrol - Legenda statis berdasarkan kategori; letakkan kanan atas. - Kontrol basemap (opsional) `L.control.layers(BASEMAPS,null,{collapsed:true})`. ### Performa - Pagination tabel 10–20 baris/halaman. - Pecah dataset besar per kecamatan/desa; hindari memuat ribuan polygon dalam satu layer. - Gunakan `map.invalidateSize()` setelah tab/elemen peta ditampilkan untuk mencegah “acak-acakan”. ### Aksesibilitas dan UX - Kontras warna layer mengikuti WCAG dasar; tooltip alternatif teks untuk ikon. - Teks popup tidak panjang; pecah informasi ke baris terpisah. - Komponen klik besar dan responsif untuk perangkat sentuh. ### Pola Stabil yang Teruji - Hindari include `header/footer` yang memicu blokir; halaman peta berdiri sendiri ketika perlu. - Atur `maxBounds` hanya jika data sering keluar area; jika tidak, cukup `fitBounds` + kontrol zoom minimum. - Gunakan pembungkus `.map-frame` dan `.map-shell` ketika peta ada dalam kontainer kompleks; panggil `map.invalidateSize()` setelah render. ### Contoh Alur Sederhana Memuat Tema Dinamis ```js async function loadTema(tema){ const list = await getTemaFiles(tema); // dari API bab 13 if(!list.length) return; const data = await loadGeoJSON(list[0].url); if(window.currentLayer){ map.removeLayer(window.currentLayer); } window.currentLayer = L.geoJSON(data, { style: f=>styleByFTYPE(f.properties), pointToLayer, onEachFeature }) .addTo(map); try { map.fitBounds(window.currentLayer.getBounds(), {padding:[20,20]}); } catch(e) {} } ``` ### Ringkasan Rancangan Frontend Leaflet di DBANGLE menekankan kesederhanaan dan kehandalan: render yang konsisten untuk point/polygon, filter wilayah, popup aman, interaksi tabel↔marker, dan pengendalian performa. Dengan pola ini, halaman peta tematik menjadi stabil, mudah dirawat, dan nyaman digunakan publik maupun admin. \n \n ## 15. Peta Tematik DBANGLE (contoh: KOPI) — Layer, Styling, Legend ### Tujuan Bab Memberikan panduan operasional untuk membangun peta tematik di atas platform DBANGLE: penentuan layer, skema atribut, aturan styling, legenda, filter, dan praktik performa. KOPI (Kerja Optimis Penuh Inovasi) dipakai sebagai contoh tema, namun prinsip di sini berlaku untuk seluruh tema (jembatan, poskamling, sawah, fasilitas, dsb.). ### 1) Konsep Layer Tematik - Layer Administratif: batas kabupaten/kecamatan/desa (referensi, non-tematik). Digunakan untuk clipping dan validasi. - Layer Inti DBANGLE: pemukiman, infrastruktur, fasilitas layanan publik, lingkungan. - Layer Tema Program: kumpulan fitur yang terkait sasaran program (contoh KOPI: kebun kopi, pos pengolahan, jalur distribusi, titik UMKM kopi, lokasi pelatihan). Struktur minimal per tema: - Dataset titik (Point) → lokasi/kejadian/objek spesifik (pos kamling, jembatan kecil, kios, UMKM). - Dataset area (Polygon/MultiPolygon) → luasan (sawah/pesawahan, hamparan kebun, kawasan rawan). - Metadata → sumber, tanggal pembaruan, versi, status validasi. ### 2) Skema Atribut Wajib - `WADMKC` (string): Nama kecamatan - `WADMKD` (string): Nama desa - `KODE_KEC` (string): Kode kecamatan - `KODE_DESA` (string): Kode desa - `FTYPE` (string): jenis fitur (contoh: `kebun_kopi`, `pos_pengolahan`, `umkm_kopi`, `jembatan`, `poskamling`, `sawah`) - `NAMOBJ`/`NAMMAP` (string, opsional): nama objek/entitas Contoh atribut tematik KOPI (opsional per dataset): - `KOMODITAS` (string): mis. `kopi_robusta`, `kopi_arabika` - `LUAS_HA` (number): untuk area - `KAPASITAS_TON` (number): kapasitas produksi/tampung - `STATUS` (enum): `aktif|tidak_aktif|rencana` ### 3) Aturan Styling Styling harus konsisten dan mudah dibaca. Gunakan peta warna yang kontras namun ramah aksesibilitas. - Titik (Point): `L.circleMarker` dengan radius 5–8 px. - `FTYPE=umkm_kopi` → warna `#9A3412` - `FTYPE=pos_pengolahan` → warna `#D97706` - `FTYPE=poskamling` → warna `#16A34A` - default → `#0EA5E9` - Area (Polygon): garis `weight:1–2`, `fillOpacity:0.2–0.35`. - `FTYPE=kebun_kopi` → `fill:#065F46` (hijau tua) - `FTYPE=sawah` → `fill:#22C55E` - default → `fill:#0EA5E9` Contoh fungsi styling: ```js function styleByFTYPE(p){ const m = { umkm_kopi: {color:'#9A3412', fillColor:'#9A3412', weight:1, fillOpacity:0.25}, pos_pengolahan: {color:'#D97706', fillColor:'#D97706', weight:1, fillOpacity:0.25}, poskamling: {color:'#16A34A', fillColor:'#16A34A', weight:1, fillOpacity:0.25}, kebun_kopi: {color:'#065F46', fillColor:'#065F46', weight:1, fillOpacity:0.30}, sawah: {color:'#22C55E', fillColor:'#22C55E', weight:1, fillOpacity:0.30}, default: {color:'#0EA5E9', fillColor:'#0EA5E9', weight:1, fillOpacity:0.25} }; return m[p.FTYPE] || m.default; } ``` ### 4) Popup dan Templating Aman Tampilkan informasi paling relevan dan hindari HTML tidak tepercaya. ```js function popupHtml(p){ const name = (p.NAMOBJ||p.NAMMAP||'-'); return `${name}
`+ `Jenis: ${p.FTYPE||'-'}
`+ `Desa: ${p.WADMKD||'-'}
`+ `Kec.: ${p.WADMKC||'-'}`; } ``` ### 5) Legenda Buat legenda statis yang menyesuaikan dengan tema yang aktif. Contoh HTML ringkas: ```html
UMKM Kopi
Pos Pengolahan
Kebun Kopi
Sawah
``` CSS `.dot` berukuran 10–12 px, border-radius 50%. ### 6) Filter dan Pencarian - Filter wilayah: dropdown `WADMKC` → `WADMKD`. Isi daftar dari properti unik data. - Filter tematik: ceklis `FTYPE`. - Pencarian teks: nama objek (`NAMOBJ/NAMMAP`). Filter dilakukan di sisi klien untuk dataset kecil–menengah; untuk dataset besar gunakan API server-side (paging/filter). ### 7) Interaksi Tabel ↔ Marker - Simpan peta `id→layer` ketika merender fitur. - Klik baris tabel → fokus ke marker/polygon dan `openPopup()`. - Klik marker → highlight baris pada tabel (scroll into view). ### 8) Performa - Pagination tabel 10–20 baris. - Pecah dataset besar per kecamatan/desa atau gunakan `get_tema_files.php` untuk memuat potongan. - Panggil `map.invalidateSize()` saat peta ditempatkan dalam container/tab dinamis. - Hindari memuat ribuan polygon sekaligus; gunakan zoom threshold atau subset. ### 9) Validasi Spasial (Client Hint) Meski validasi utama di server, pada klien dapat dilakukan: - Abaikan fitur di luar bounding box Lebak untuk menghindari tampilan “keluar area”. - Tampilkan pesan jika proporsi besar data di luar area. ### 10) Prosedur Publikasi Tema 1. Desain skema atribut → tentukan `FTYPE` dan legend. 2. Siapkan data uji (10–50 fitur) → validasi di server. 3. Tinjau visual: warna, ketajaman, keterbacaan, label. 4. Finalisasi → unggah batch penuh per kecamatan/desa. 5. Terbitkan ke `final_approved/` dan update daftar pada halaman tema terkait. ### 11) Contoh Alur Implementasi (Kode Ringkas) ```js async function renderTema(url){ const data = await loadGeoJSON(url); if(window.temaLayer){ map.removeLayer(window.temaLayer); } window.temaLayer = L.geoJSON(data, { pointToLayer: (f,latlng)=>L.circleMarker(latlng, {radius:6, ...styleByFTYPE(f.properties)}), style: f=>styleByFTYPE(f.properties), onEachFeature: (f,l)=>l.bindPopup(popupHtml(f.properties)) }).addTo(map); try{ map.fitBounds(window.temaLayer.getBounds(), {padding:[24,24]}); }catch(e){} } ``` ### 12) Kualitas Aksesibilitas - Palet warna diuji minimal kontras 3:1 untuk elemen non-teks. - Ukuran marker tidak lebih kecil dari 5 px; garis polygon minimal 1 px. - Tooltip/popup ringkas, hindari paragraf panjang. ### 13) Catatan untuk KOPI (Sebagai Contoh) - Gunakan simbol warna hangat untuk rantai nilai (UMKM/pos pengolahan), hijau untuk hamparan kebun. - Sorot lokasi pelatihan/komunitas dengan ikon khusus (opsional SVG). - Buat sub-legend untuk status (`aktif`, `rencana`) bila diperlukan. ### Ringkasan Dengan pola layer, styling, legenda, dan filter yang konsisten, peta tematik DBANGLE tampil stabil, informatif, dan ramah pengguna. Tema KOPI hanyalah contoh; pendekatan ini dapat langsung diterapkan pada tema lain tanpa merombak struktur antarmuka. \n \n ## 16. Analitik dan Dashboard ### Tujuan Bab Menjelaskan rancangan analitik dan dashboard di DBANGLE: metrik utama, teknik agregasi spasial/non-spasial, penyajian visual, serta strategi performa. Analitik berfungsi untuk memberi ringkasan cepat bagi pengambil keputusan tanpa harus membuka seluruh layer peta. ### Sasaran Analitik - Ringkasan jumlah fitur per kategori, kecamatan, dan desa - Luas total/panjang total (untuk polygon/line) per wilayah - Tren unggah/verifikasi per periode (mingguan/bulanan) - Kualitas data: proporsi field hilang, fitur di luar batas, dan status validasi ### Sumber Data Analitik - Basis data (tabel `fitur_tematik`, `layer_tematik`, `desa`, `kecamatan`) - Metadata file final (`assets/js/final_approved/*.json`) untuk ringkasan ringan - Log aplikasi (unggah, verifikasi, publikasi) untuk metrik operasional ### Skema Ringkas Tabel Agregasi (Opsional) - `agg_kecamatan_tema` (kec, tema, count, luas_total, updated_at) - `agg_desa_tema` (desa, tema, count, luas_total, updated_at) - `agg_operasional` (periode, unggah, verified, final) Tabel ini dapat diisi via job terjadwal (cron) agar query dashboard cepat. ### Teknik Agregasi 1. Non-spasial (COUNT, SUM) di database - `COUNT(*)` fitur per kategori/kecamatan/desa - `SUM(luas_ha)` untuk area tematik 2. Spasial (PostGIS) - `ST_Area(geom::geography)` untuk luas akurat (meter/ha) - `ST_Length(geom::geography)` untuk panjang (jaringan jalan/sungai) - `ST_Intersection` / `ST_Within` untuk menghitung per wilayah 3. Precompute - Simpan hasil agregasi per periode agar tampilan dashboard selalu cepat ### Desain Dashboard - Kartu ringkas (stat cards): total fitur, total desa tercakup, luas total - Grafik bar/line: unggah/verified/final per minggu - Peta mini (spark map): sebaran cepat (heat/choropleth sederhana) bila diperlukan - Tabel ringkasan: top 10 kecamatan/desa menurut jumlah/lintas kategori Komponen UI disarankan menggunakan Chart.js untuk grafik dan tabel paginasi sederhana. ### Contoh Query Agregasi (PostgreSQL/PostGIS) ```sql -- Jumlah fitur per kecamatan (contoh tema jembatan) SELECT d.kode_kecamatan, k.nama_kecamatan, COUNT(*) AS jumlah FROM fitur_tematik f JOIN desa d ON f.kode_desa = d.kode_desa JOIN kecamatan k ON d.kode_kecamatan = k.kode_kecamatan WHERE f.layer_slug = 'jembatan' GROUP BY d.kode_kecamatan, k.nama_kecamatan ORDER BY jumlah DESC; -- Luas total sawah per kecamatan (ha) SELECT d.kode_kecamatan, k.nama_kecamatan, SUM(ST_Area(f.geom::geography))/10000.0 AS luas_ha FROM fitur_tematik f JOIN desa d ON f.kode_desa = d.kode_desa JOIN kecamatan k ON d.kode_kecamatan = k.kode_kecamatan WHERE f.layer_slug = 'sawah' GROUP BY d.kode_kecamatan, k.nama_kecamatan ORDER BY luas_ha DESC; ``` ### Contoh Endpoint Ringkas (JSON) - `GET /api/v1/analitik/kecamatan?tema=jembatan` → daftar {kecamatan, jumlah} - `GET /api/v1/analitik/luas?tema=sawah&level=kecamatan` → {kecamatan, luas_ha} - `GET /api/v1/analitik/operasional?periode=month&limit=6` → {unggah, verified, final} Respons konsisten `{success, data}` agar mudah dipakai frontend. ### Contoh Komponen Frontend (Chart.js) ```html ``` ### Performa Dashboard - Precompute agregasi harian; hindari query berat di jam sibuk - Pagination/limit default pada endpoint analitik - Cache 5–15 menit untuk grafik yang tidak sensitif real-time - Hindari memuat data mentah besar di dashboard; tampilkan ringkasan saja ### Kualitas Data - Tampilkan badge kualitas: persen fitur yang valid, kolom wajib terisi, dan out-of-bounds - Beri tautan “lihat masalah” ke daftar fitur yang perlu diperbaiki ### Keamanan - Endpoints analitik internal di-protect (login admin) - Grafik publik hanya memakai data yang sudah final/teragregasi ### Workflow Operasional 1. ETL dan verifikasi mengalirkan data baru 2. Job agregasi (cron) menghitung ulang metrik inti 3. Dashboard memuat data agregat via API cepat 4. Admin memantau tren dan prioritas perbaikan ### Ringkasan Analitik DBANGLE menyajikan gambaran besar yang ringkas, akurat, dan cepat. Dengan agregasi terjadwal, API ringan, serta visualisasi yang sederhana, pengambil keputusan dapat fokus pada kebijakan, bukan teknis data mentah. \n \n ## 17. Android Surveyor ### Tujuan Bab Menjelaskan arsitektur, alur kerja, dan praktik terbaik aplikasi Android Surveyor DBANGLE untuk pengumpulan data lapangan yang andal, hemat kuota, dan aman. Fokus pada login, mode offline, pengambilan koordinat, unggah foto/GeoJSON, verifikasi, serta trik mengatasi koneksi terbatas. ### Arsitektur Aplikasi - Framework: Flutter (Dart) agar pengembangan cepat dan UI konsisten. - Lapisan: UI → Service (Auth, Upload) → Storage (cache lokal) → Network (HTTP/HTTPS). - Konfigurasi: `Config.apiBaseUrl = https://dbangle.id/api/v1`, `webBaseUrl = https://dbangle.id`. - Dependensi utama (contoh): `http`, `shared_preferences`, `path_provider`, `permission_handler`, `geolocator` (opsional), `file_picker`. ### Peran dan Sesi - Login dua tahap untuk Desa: password → PIN 6 digit (API v1 hanya PIN juga didukung). - Data sesi disimpan ringan di `SharedPreferences` (user id, kode_desa, token, waktu login). - Logout menghapus token/sesi lokal. ### Alur Kerja Utama 1. Login - Masukkan `kode_desa` + `pin` (atau username+password lalu PIN bila mode web). - Terima `user` + `token` dari `POST /api/v1/auth/login.php`. 2. Ambil/Impor Data - Buat fitur baru (point/polygon) atau impor GeoJSON dari penyimpanan. - Isi atribut wajib: `WADMKC`, `WADMKD`, `KODE_KEC`, `KODE_DESA`, `FTYPE`, `NAMOBJ`. 3. Bukti Foto - Pilih dari kamera/galeri; kompres dan beri nama konsisten (`kodeDesa_timestamp.jpg`). 4. Simpan Lokal (Offline) - Simpan draf ke penyimpanan lokal (JSON) jika jaringan buruk. 5. Unggah - Kirim `multipart/form-data` ke `desa/verifikasi_peta_android.php` berisi file GeoJSON dan metadata. 6. Tindak Lanjut - Tampilkan status `pending/verified/final` dan notifikasi sederhana. ### Desain Data di Aplikasi - Struktur lokal draf: ```json { "meta": {"kode_desa":"3602262004","tema":"sawah","created_at":"2025-09-15T10:33:00+07:00"}, "geojson": {"type":"FeatureCollection","features":[ /* fitur */ ]} } ``` - Validasi klien: pastikan properti wajib ada; geometri untuk point minimal 5–8 digit presisi. ### Unggah Multipart - Field: `kode_desa`, `tema`, `file` (GeoJSON), `meta` (JSON opsional), plus file foto bila disyaratkan. - Tampilkan progress bar (%) dan status hasil (berhasil/gagal + pesan). ### Mode Offline & Sinkronisasi - Simpan draf di folder app (`path_provider` → `getApplicationDocumentsDirectory`). - Tanda draf dengan status: `draft`, `queued`, `uploaded`. - Saat online, antrikan unggah berurutan untuk hemat kuota. ### Koordinat dan Presisi - Gunakan `geolocator` atau baca dari GeoJSON impor. - Tampilkan akurasi GPS bila tersedia; izinkan koreksi manual di peta kecil. ### Keamanan dan Privasi - Simpan token secukupnya; jangan menyimpan password. - Lindungi data pribadi; foto hanya untuk verifikasi internal bila sensitif. - Validasi ketat agar file tidak mengandung skrip (hanya teks JSON murni). ### Antarmuka Utama - Halaman Login → Halaman Beranda (aksi cepat: Tambah Data, Impor, Antrian Upload) → Form Atribut → Peta → Unggah → Riwayat. - Pemberitahuan ringan saat koneksi gagal/berhasil. ### Contoh Potongan Kode (Dart) ```dart final uri = Uri.parse('${Config.apiBaseUrl}/desa/verifikasi_peta_android.php'); final req = http.MultipartRequest('POST', uri) ..fields['kode_desa'] = kodeDesa ..fields['tema'] = tema ..fields['meta'] = jsonEncode({ 'versi': 1, 'catatan': note }) ..files.add(await http.MultipartFile.fromPath('file', geojsonPath, contentType: MediaType('application','json'))); final res = await req.send(); final body = await res.stream.bytesToString(); final data = jsonDecode(body); if (data['success'] == true) { // tandai uploaded dan hapus dari antrian } ``` ### Toleransi Jaringan Rendah - Timeouts: 30–60 detik untuk unggah; retry 1–2 kali. - Kompresi foto (JPEG, quality 70–80) dan ukuran maksimal 1200–1600px sisi terpanjang. - Batasi ukuran GeoJSON; pecah per desa/tema bila besar. ### Uji Lapangan - Uji di wilayah tanpa jaringan; pastikan draf tidak hilang. - Uji unggah bertahap saat sinyal ada. - Uji konsistensi atribut (kamus data) dan peta kecil pratinjau. ### Checklist Aplikasi Android - [ ] Login PIN bekerja, fallback bila `pin_hash` kosong - [ ] Draf offline tersimpan, tidak hilang saat aplikasi ditutup - [ ] Validasi atribut wajib sebelum unggah - [ ] Unggah multipart menunjukkan progres dan pesan hasil - [ ] Ukuran foto terkompresi dan penamaan konsisten - [ ] Retry unggah saat jaringan drop ### Roadmap - Tanda koordinat otomatis dari EXIF (bila tersedia) dan koreksi manual - Prefill daftar `WADMKC/WADMKD` dari referensi offline agar minim salah ketik - Penyelarasan draf dengan verifikasi server (pull status) ### Ringkasan Aplikasi Android Surveyor DBANGLE dirancang untuk sederhana namun tangguh pada kondisi lapangan. Dengan login PIN, draf offline, unggah multipart, dan validasi atribut wajib, proses pengumpulan data menjadi cepat, akurat, dan efisien di seluruh desa. \n \n ## 18. Alur Unggah GeoJSON (Lapangan → Verifikasi → Publikasi) ### Tujuan Bab Mendeskripsikan alur end-to-end unggah data tematik ke DBANGLE: dari pembuatan/ekstraksi data di lapangan, validasi otomatis, verifikasi berjenjang, hingga publikasi final. Bab ini juga memuat checklist praktis agar unggah berjalan lancar meski koneksi terbatas. ### Gambaran Umum Alur 1. Persiapan Data di Lapangan 2. Unggah ke server (Android atau web admin) 3. Validasi otomatis (skema, spasial, konsistensi) 4. Review Admin Kecamatan (Tahap 1) 5. Verifikasi Final Admin Kabupaten 6. Publikasi ke `final_approved/` dan tampil di peta ### 1) Persiapan Data di Lapangan - Bentuk data: GeoJSON `FeatureCollection` (Point/Polygon/MultiPolygon) dengan properti wajib `WADMKC`, `WADMKD`, `KODE_KEC`, `KODE_DESA`, `FTYPE`, dan `NAMOBJ/NAMMAP` (opsional). - Akurasi: gunakan koordinat WGS84 (EPSG:4326); presisi 6–8 digit desimal cukup untuk skala desa. - Foto bukti (opsional): kompres (JPEG 70–80%), penamaan `kodeDesa_timestamp.jpg`. - Validasi awal di aplikasi: pastikan semua kolom wajib terisi dan geometri tidak kosong. ### 2) Unggah ke Server - Android: `POST /api/v1/desa/verifikasi_peta_android.php` (multipart). Field: `kode_desa`, `tema`, `file` (GeoJSON), `meta` (opsional JSON), serta foto bila diperlukan. - Web Admin: form unggah dengan batas ukuran sesuai konfigurasi (Bab 09–10). - Penamaan berkas otomatis: `tema_kodeDesa_YYYYMMDDHHMMSS.json`. ### 3) Validasi Otomatis - Skema: cek properti wajib, tipe data (angka vs string), enumerasi (mis. `KONDISI`). - Spasial: cek validitas geometri, bounding box Lebak, dan (bila area) luas > 0. - Konsistensi: `KODE_DESA` selaras dengan `WADMKD` berdasar tabel referensi. - Hasil validasi: - Lolos → simpan ke `assets/js/pending/` - Perlu perbaikan → tandai dan kembalikan pesan rinci ke pengunggah ### 4) Review Tahap 1 (Admin Kecamatan) - Memeriksa sampel fitur (koordinat, atribut, foto), memberi catatan revisi jika perlu. - Mengubah status dari `pending` ke `verified` bila layak. ### 5) Verifikasi Final (Admin Kabupaten) - Pemeriksaan akhir: cakupan antar desa, tumpang tindih yang tidak wajar, dan konsistensi metadata. - Penetapan status `final` dan publikasi. ### 6) Publikasi Final - Berkas dipindah ke `assets/js/final_approved/` dengan metadata yang diperbarui (tanggal, versi, sumber, kontak). - Frontend memuat daftar file dari API/manifest dan menampilkannya di peta tematik. ### Struktur Direktori Data (Ringkas) ``` assets/js/ uploaded/ # unggahan mentah pending/ # menunggu review kecamatan verified/ # lulus tahap 1 final_approved/ # siap tayang (publik) ``` ### Checklist Pengunggah (Surveyor/Desa) - [ ] GeoJSON berformat `FeatureCollection`, UTF-8, EPSG:4326 - [ ] Kolom wajib lengkap (`WADMKC`, `WADMKD`, `KODE_KEC`, `KODE_DESA`, `FTYPE`) - [ ] Nama file aman (huruf kecil + underscore; tanpa spasi) - [ ] Ukuran file ≤ 5–10MB (pecah per kecamatan/desa jika besar) - [ ] Foto dikompresi dan diberi nama konsisten - [ ] Koneksi lemah? Simpan draf dan unggah saat sinyal kuat ### Checklist Verifikator (Kecamatan/Kabupaten) - [ ] Koordinat berada dalam batas Lebak dan desa yang tepat - [ ] Atribut sesuai kamus data; tidak ada nilai janggal - [ ] Tidak ada duplikasi fitur mencolok - [ ] Metadata terisi (sumber, tanggal_pembaruan, versi) - [ ] Status diubah sesuai hasil: `pending` → `verified` → `final` ### Notifikasi dan Umpan Balik - Android menampilkan pesan ringkas hasil unggah (berhasil/gagal + alasan) - Admin menerima daftar antrian terbaru beserta ringkasan validasi ### Masalah Umum dan Solusi - 413 Request Entity Too Large → tingkatkan `client_max_body_size` (Nginx) dan `upload_max_filesize` (PHP) - 403 pada halaman peta → pastikan anti view source/WAF tidak memblokir `peta_*.php` - GeoJSON tidak valid → perbaiki ring polygon, tipe properti, atau drop fitur di luar area - Peta “acak-acakan” → bungkus map (`.map-frame`), panggil `map.invalidateSize()`, atau pecah data ### Ringkasan Dengan alur unggah yang jelas, validasi otomatis, dan verifikasi berlapis, DBANGLE memastikan data yang tayang akurat dan konsisten. Struktur direktori dan checklist praktis membantu surveyor serta admin menjaga kualitas sekaligus mempercepat waktu rilis. \n \n ## 19. Performa dan Optimasi ### Tujuan Bab Memberikan panduan menyeluruh untuk menjaga DBANGLE tetap cepat, hemat sumber daya, dan stabil pada trafik publik maupun pekerjaan admin. Fokus pada optimasi front-end (Leaflet), back-end (PHP/Nginx), basis data (PostgreSQL/PostGIS), dan alur data (ETL/serving GeoJSON). ### Strategi Umum - Ukur sebelum mengubah: gunakan metrik waktu muat (TTFB, waktu render peta), ukuran transfer, error rate. - Sasar 80/20: optimalkan bagian yang paling sering dipakai (peta tematik populer, endpoint daftar berkas, unggah Android). - Sederhanakan: kurangi kompleksitas UI dan jumlah komponen aktif pada halaman yang sama. ### Frontend (Leaflet, JS, CSS) 1. Beban Data - Pecah dataset besar per kecamatan/desa; jangan memuat ribuan fitur polygon sekaligus. - Untuk titik padat, aktifkan clustering (opsional) atau batasi pada zoom tertentu (zoom threshold). - Pakai `fetch(..., {cache:'no-store'})` hanya untuk data yang sering berubah; selain itu izinkan cache browser. 2. Render - Gunakan `L.circleMarker` untuk Point (lebih ringan daripada icon custom); radius 5–8 px. - Hindari `bindPopup` berat di tiap fitur; buat isi popup ringkas dan tanpa HTML kompleks. - Panggil `map.invalidateSize()` setelah peta ditampilkan di tab/kartu tersembunyi. 3. Tabel dan DOM - Pagination 10–20 baris; hindari merender ribuan baris. - Debounce untuk pencarian/filter (200–300 ms) agar tidak merender ulang terlalu sering. 4. Aset Statis - Kompres CSS/JS; gunakan CDN yang andal untuk lib umum (Bootstrap, Leaflet) atau sajikan lokal dengan cache panjang. ### Backend (PHP, Nginx) 1. Endpoint - Konsistenkan respons JSON `{success, message, data}`; hindari payload tidak perlu. - Gunakan `limit` dan `offset/page` default pada daftar; batasi maksimal (mis. 200). - Streaming ekspor (CSV/XLSX/PDF) agar hemat memori. 2. Nginx - `client_max_body_size` dan `fastcgi_*_timeout` disetel sesuai ukuran unggah dan analitik. - Aktifkan kompresi `gzip` untuk `application/json`, `text/css`, `application/javascript`. - Cache aset statis dengan `expires 7d` dan `Cache-Control: public`. 3. Concurrency - Hindari pekerjaan berat pada request utama; dorong ke job latar (cron) bila memungkinkan. ### Database (PostgreSQL + PostGIS) 1. Indeks - Pasang indeks GiST pada kolom geometri; B-Tree pada kolom filter (tema, kode_desa, kode_kecamatan, updated_at). - Periksa `EXPLAIN ANALYZE` untuk kueri lambat; tambahkan indeks komposit bila pola filter berulang. 2. Query - Hitung luas/panjang sekali (materialized) jika dipakai berulang di dashboard. - Batasi ruang lingkup kueri dengan filter wilayah sebelum operasi spasial berat (intersection/within). 3. Pemeliharaan - `VACUUM (ANALYZE)` berkala; perbarui statistik setelah batch besar. - Partisi tabel fitur berdasarkan tema atau wilayah (opsional) untuk skala besar. ### GeoJSON Serving 1. Ukuran Berkas - Target ≤ 5–10 MB per berkas; simplify geometri dengan toleransi kecil (tanpa mengubah makna). - Hapus atribut yang tidak dipakai di frontend; simpan detail di server bila perlu. 2. Struktur - FeatureCollection yang valid; pastikan encoding UTF-8 dan WGS84. - Sertakan metadata ringkas (sumber, tanggal) di top-level atau file pendamping `.meta.json`. 3. Pengambilan - Gunakan daftar lewat API (manifest) agar frontend tidak memindai direktori. ### Analitik dan Precompute - Jalankan job agregasi harian untuk statistik dashboard; simpan hasil pada tabel ringkas. - Hitung “centroid”/bounding untuk polygon besar agar peta awal tidak harus fit ke seluruh geometri berat. ### Profiling dan Monitoring - Tambahkan timestamp sederhana pada log untuk memantau waktu proses per endpoint. - Buat halaman `api/performance.php` yang mengembalikan `{ok:true, ts:now}` untuk health-check. - Catat ukuran berkas unggah dan waktu verifikasi, sehingga mudah mengidentifikasi bottleneck. ### Pola Optimasi yang Sudah Terbukti di DBANGLE - Menggunakan template peta stabil seperti `peta_jembatan.php` untuk menghindari “acak-acakan”. - Menghapus include yang memicu WAF/anti-view-source pada halaman peta publik; halaman berdiri sendiri. - Menambahkan `.map-frame` dan `map.invalidateSize()` pada tata letak kompleks. - Memindahkan dataset besar ke folder `final_approved/` terpisah dan memuat via daftar API. ### Checklist Performa - [ ] Dataset besar dipotong per wilayah dan/atau dipaginasi di UI - [ ] Indeks PostGIS terpasang pada kolom geometri; indeks filter utama tersedia - [ ] Aset statis dicache; gzip aktif untuk JSON/CSS/JS - [ ] Endpoint daftar memiliki `limit` default dan maksimal - [ ] Dashboard memakai agregasi precompute, bukan data mentah - [ ] Ukuran GeoJSON berada dalam batas wajar dan disederhanakan bila perlu ### Contoh Konfigurasi Ringkas (Nginx) ``` location ~* \.(?:css|js|png|jpg|jpeg|webp|svg|ico|json|geojson)$ { gzip on; gzip_types application/json text/css application/javascript; expires 7d; add_header Cache-Control "public, max-age=604800"; try_files $uri =404; } ``` ### Ringkasan Performa bukan hanya soal satu komponen, melainkan orkestrasi seluruh lapisan: data yang ringan, kueri yang efisien, API hemat, dan UI sederhana. Dengan disiplin pada ukuran berkas, indeks yang tepat, caching, serta precompute untuk analitik, DBANGLE tetap gesit melayani publik dan pemangku kepentingan seiring pertumbuhan data. \n \n ## 20. Logging, Monitoring, dan Audit ### Tujuan Bab Menetapkan standar pencatatan (logging), pemantauan (monitoring), dan audit trail pada DBANGLE agar insiden mudah dideteksi dini, dianalisis, dan dicegah berulang. Fokus pada apa yang harus dicatat, di mana disimpan, bagaimana dipantau, dan SOP ringkas ketika terjadi masalah. ### 1) Ruang Lingkup Logging - Aplikasi (PHP) - Autentikasi: login berhasil/gagal, logout, reset password/PIN - Aktivitas data: unggah, verifikasi, publikasi, ekspor - Galat aplikasi: exception, validasi gagal, timeouts - Server (Nginx/PHP-FPM) - Access log, error log, status FastCGI - Database (PostgreSQL) - Error query, slow query (opsional `pg_stat_statements`) ### 2) Format dan Lokasi Log - Direktori aplikasi: `/var/www/dbangle/logs/` - `app.log` – catatan umum - `security_report.log` – keamanan (login, rate-limit, upload mencurigakan) - `etl_qa.log` – ETL/QA - Sistem/Server: - Nginx: `/var/log/nginx/{access,error}.log` - PHP-FPM: `/var/log/php8.1-fpm.log` (versi menyesuaikan) - Format baris log (aplikasi): ``` [timestamp ISO8601] [level] [userId/kode_desa/ip] event=LOGIN status=FAIL reason=PIN_SALAH path=/api/v1/auth/login.php ``` Gunakan tingkat log: `INFO`, `WARN`, `ERROR`. ### 3) Retensi dan Rotasi Log - Gunakan `logrotate` untuk Nginx dan log aplikasi: - Rotasi harian/mingguan, simpan 7–30 file lama - Kompres `.gz` setelah rotasi - Izin akses dibatasi (hanya admin/server) ### 4) Monitoring (Kinerja & Ketersediaan) - Health-check HTTP: `GET /api/performance.php` mengembalikan `{ok:true, ts:...}` - Indikator utama: - Rasio 5xx per 5 menit - Rata-rata waktu respons endpoint kunci (auth, daftar_berkas, unggah) - Ukuran disk (folder `assets/js/*`, `logs/`, `uploads/`) - Penggunaan CPU/RAM (opsional, via `node_exporter` + Prometheus) - Notifikasi: - Threshold 5xx > 1% → kirim alert (email/Telegram opsional) - Disk usage > 80% → kirim alert ### 5) Audit Trail - Simpan aksi sensitif pada tabel `audit_log`: - Kolom: `id`, `entitas`, `aksi`, `id_entitas`, `user_id`, `ip`, `waktu`, `keterangan` - Contoh entitas: `fitur_tematik`, `layer_tematik`, `user`, `config` - Tampilkan ringkasan audit pada panel admin (filter per pengguna/periode) ### 6) Praktik Baik Pencatatan di Kode - Tangkap exception dengan try/catch bermakna; tulis ke `app.log`/`security_report.log` - Jangan menulis data sensitif (password, PIN) ke log - Sertakan `request_id` sederhana (UUID) untuk melacak satu permintaan end-to-end ### 7) Contoh Implementasi Sederhana (PHP) ```php function log_app($level, $message, array $ctx = []){ $ts = date('c'); $ip = $_SERVER['REMOTE_ADDR'] ?? '-'; $uid = $_SESSION['uid'] ?? ($ctx['uid'] ?? '-'); $line = sprintf('[%s] [%s] [uid=%s ip=%s] %s | %s', $ts, strtoupper($level), $uid, $ip, $message, json_encode($ctx)); error_log($line."\n", 3, __DIR__.'/../logs/app.log'); } ``` ### 8) Dashboard Internal Monitoring (Ringkas) - Halaman sederhana yang menampilkan: - Ringkasan error 24 jam terakhir (dari `app.log` & `error.log`) - Grafik kecil jumlah unggah/verified/final (Bab 16) - Status disk dan rata-rata waktu respons - Proteksi dengan login admin ### 9) SOP Insiden 1. Identifikasi - Baca alert/keluhan; cek `error.log` dan `app.log` pada interval yang sama 2. Contain - Nonaktifkan sementara fitur yang bermasalah jika perlu (feature flag) 3. Perbaikan - Temukan akar masalah (konfigurasi, bug, data korup); perbaiki di staging → production 4. Pemulihan - Validasi layanan pulih; pantau 1–24 jam 5. Postmortem singkat - Catat penyebab, dampak, tindakan pencegahan; arsipkan di `logs/postmortem/` ### 10) Keamanan Log - Batasi akses baca log hanya untuk admin server - Enkripsi arsip log sensitif jika dipindahkan - Hapus log lama sesuai kebijakan retensi ### 11) Checklist - [ ] Log aplikasi diaktifkan (app.log/security_report.log) - [ ] Rotasi log berjalan - [ ] Health-check tersedia dan dipantau - [ ] Audit trail ditulis untuk aksi sensitif - [ ] SOP insiden terdokumentasi dan diuji ### Ringkasan Logging, monitoring, dan audit adalah fondasi operasional DBANGLE. Dengan catatan yang rapi, pantauan proaktif, dan SOP insiden yang jelas, tim dapat merespons cepat, menjaga keandalan, dan meningkatkan kualitas layanan dari waktu ke waktu. \n \n ## 21. Backup dan Restore ### Tujuan Bab Menyediakan panduan operasional untuk melakukan backup terjadwal dan pemulihan (restore) komponen inti DBANGLE: basis data, berkas peta (GeoJSON), unggahan, dan konfigurasi. Fokus pada kesederhanaan, keterulangan, dan verifikasi hasil. ### Ruang Lingkup Backup - Database: PostgreSQL (schema, data) + PostGIS - Aset peta final: `assets/js/final_approved/` (wajib), serta `verified/` (opsional) - Unggahan lain: `uploads/` (foto/lamparan) - Konfigurasi & skrip: `config/`, `scripts/`, `nginx` site config (opsional) - Log penting: ringkas harian (opsional, bukan semua log) ### Strategi dan Retensi - Harian: backup DB + `final_approved/` (retensi 7–14 hari) - Mingguan: snapshot penuh (DB + aset + uploads + config) (retensi 4–8 minggu) - Bulanan: arsip jangka panjang (retensi 3–6 bulan) - Simpan di lokasi terpisah (remote/NAS/Cloud); enkripsi jika berisi data sensitif ### Struktur Direktori Backup ``` /backup/ daily/ weekly/ monthly/ ``` Nama file bertimestamp: `dbangle_db_YYYYMMDD.pgsql.gz`, `final_approved_YYYYMMDD.tgz`. ### Perintah Backup (Contoh Ubuntu) 1) Database PostgreSQL ```bash # ENV: sesuaikan user/DB PGUSER=dbuser PGDATABASE=dbangle \ pg_dump -Fc -Z6 -f "/backup/daily/dbangle_db_$(date +%F).dump" ``` 2) Aset Peta Final ```bash tar -czf "/backup/daily/final_approved_$(date +%F).tgz" -C /var/www/dbangle/assets/js final_approved ``` 3) Uploads (opsional, harian atau mingguan) ```bash tar -czf "/backup/weekly/uploads_$(date +%F).tgz" -C /var/www/dbangle uploads ``` 4) Konfigurasi ```bash tar -czf "/backup/weekly/config_$(date +%F).tgz" \ /etc/nginx/sites-enabled/dbangle.id /var/www/dbangle/config /var/www/dbangle/scripts ``` ### Otomasi Cron ``` # Harian 02:10 10 2 * * * root PGUSER=dbuser PGDATABASE=dbangle pg_dump -Fc -Z6 -f /backup/daily/dbangle_db_$(date +\%F).dump 15 2 * * * root tar -czf /backup/daily/final_approved_$(date +\%F).tgz -C /var/www/dbangle/assets/js final_approved # Mingguan (Minggu 03:00) 0 3 * * 0 root tar -czf /backup/weekly/uploads_$(date +\%F).tgz -C /var/www/dbangle uploads 5 3 * * 0 root tar -czf /backup/weekly/config_$(date +\%F).tgz /etc/nginx/sites-enabled/dbangle.id /var/www/dbangle/config /var/www/dbangle/scripts ``` Pastikan partisi `/backup` memiliki ruang cukup dan dirotasi. ### Verifikasi Backup - Database: `pg_restore -l /backup/daily/dbangle_db_YYYY-MM-DD.dump` (listing tidak error) - Arsip: `tar -tzf` untuk memeriksa isi tanpa ekstrak - Hash opsional: simpan `sha256sum` berdampingan ### Prosedur Restore (Uji di Staging) 1) Siapkan server staging (Ubuntu + PostgreSQL + PostGIS + Nginx + PHP) 2) Restore database ```bash # buat DB baru createdb dbangle_staging pg_restore -Fc -d dbangle_staging /backup/daily/dbangle_db_YYYY-MM-DD.dump ``` 3) Restore aset peta ```bash mkdir -p /var/www/dbangle/assets/js/final_approved tar -xzf /backup/daily/final_approved_YYYY-MM-DD.tgz -C /var/www/dbangle/assets/js chown -R www-data:www-data /var/www/dbangle/assets/js/final_approved find /var/www/dbangle/assets/js/final_approved -type f -exec chmod 644 {} + ``` 4) Restore uploads (opsional) ```bash tar -xzf /backup/weekly/uploads_YYYY-MM-DD.tgz -C /var/www/dbangle chown -R www-data:www-data /var/www/dbangle/uploads ``` 5) Restore konfigurasi (staging menyesuaikan) ```bash tar -xzf /backup/weekly/config_YYYY-MM-DD.tgz -C / systemctl reload nginx ``` 6) Ubah koneksi aplikasi (`config/database_app.php`) menunjuk ke DB staging 7) Uji halaman kunci (peta, API, admin); cek log error ### Kebersihan dan Rotasi Backup - Hapus backup melebihi retensi menggunakan cron mingguan - Kompres tingkat sedang (Z6) agar seimbang antara ukuran dan waktu - Pisahkan volume backup agar tidak memenuhi partisi aplikasi ### Keamanan Backup - Hak akses `/backup` hanya untuk admin - Enkripsi arsip yang memuat data sensitif (mis. `gpg -c ...`) - Jangan meletakkan backup di dalam web root ### Checklist - [ ] Cron harian/mingguan aktif - [ ] Ruang disk cukup dan dimonitor - [ ] Verifikasi restore lulus di staging minimal bulanan - [ ] Kepemilikan/izin file setelah restore benar (`www-data`, 644/755) - [ ] Catatan lokasi dan tanggal backup terakhir terdokumentasi ### Ringkasan Backup yang baik bukan hanya membuat salinan, tetapi juga memastikan dapat dipulihkan. Dengan jadwal jelas, retensi wajar, dan uji restore berkala, DBANGLE tetap siap menghadapi insiden tanpa kehilangan data penting maupun layanan peta untuk publik. \n \n ## 22. Deployment Zero Downtime ### Tujuan Bab Menetapkan praktik rilis (deployment) yang aman, cepat, dan tanpa downtime bagi DBANGLE. Fokus pada strategi atomic deploy, struktur rilis, pengelolaan konfigurasi, cache, migrasi database, serta rollback yang dapat diprediksi. ### Prinsip Utama - Atomic: penggantian versi dilakukan dengan operasi `mv`/symlink sekali jalan sehingga pengguna tidak melihat kondisi setengah jadi. - Idempotent: skrip rilis dapat dijalankan ulang tanpa meninggalkan keadaan rusak. - Reversible: setiap rilis punya prosedur rollback sederhana. - Observability: setelah rilis, ada cek kesehatan otomatis dan pengawasan log. ### Struktur Direktori Rilis (Contoh) ``` /var/www/ dbangle/ # symlink → /var/www/releases/2025-09-15_1400 releases/ 2025-09-15_1400/ 2025-09-10_0900/ shared/ # file/dir yang dibagi antar rilis uploads/ logs/ config/ ``` - `dbangle` menunjuk ke direktori rilis aktif. - `shared` berisi data yang tidak boleh dihapus saat ganti versi. ### Alur Rilis Atomic 1. Siapkan paket rilis di `/tmp/release_xxx.tgz` (berisi aplikasi kecuali `uploads/logs/config`). 2. Ekstrak ke `/var/www/releases/2025-09-15_1400/`. 3. Tautkan `shared`: - `uploads → releases/.../uploads` (symlink atau bind mount) - `logs → releases/.../logs` - `config → releases/.../config` 4. Jalankan langkah build ringan (jika ada) dan pre-check. 5. `ln -sfn /var/www/releases/2025-09-15_1400 /var/www/dbangle` (switch versi). 6. `nginx -t && systemctl reload nginx` (jika perlu hanya reload, bukan restart total). 7. Validasi health-check dan halaman kunci. ### Pengelolaan Konfigurasi - Simpan rahasia di `/var/www/shared/config/`. Set symlink ke rilis aktif. - Pastikan izin: `www-data:www-data`, file 644, direktori 755. - Bedakan `production`, `staging` melalui berkas config terpisah. ### Migrasi Database - Versi aplikasi menyertakan migrasi SQL (folder `database/migrations/`). - Prosedur: 1) Backup DB cepat (lihat Bab 21) 2) Jalankan migrasi `psql -f migrations/xxxx.sql` terhadap schema 3) Catat versi migrasi terakhir (tabel `schema_version`) - Migrasi harus backward‑compatible bila memungkinkan; jika tidak, jadwalkan maintenance pendek. ### Cache dan Aset Statis - Nginx menyajikan aset dengan cache 7 hari; saat rilis, gunakan query string versi (cache busting) mis. `app.css?v=20250915`. - Kosongkan cache aplikasi (jika ada) pascarilis. ### Health Check dan Verifikasi - Cek `GET /api/performance.php` harus mengembalikan `{ok:true}`. - Buka 2–3 halaman kunci (peta tematik, admin, API daftar berkas) dan pantau error log 5–15 menit. ### Rollback Cepat 1. `ln -sfn /var/www/releases/2025-09-10_0900 /var/www/dbangle` (kembali ke versi sebelumnya) 2. `systemctl reload nginx` 3. Pulihkan database bila migrasi tidak compatible (gunakan backup harian) ### Automasi Sederhana (Contoh Skrip) ```bash set -e REL=$(date +%Y-%m-%d_%H%M) DST=/var/www/releases/$REL mkdir -p "$DST" tar -xzf /tmp/release.tgz -C "$DST" ln -sfn /var/www/shared/uploads "$DST"/uploads ln -sfn /var/www/shared/logs "$DST"/logs ln -sfn /var/www/shared/config "$DST"/config ln -sfn "$DST" /var/www/dbangle nginx -t && systemctl reload nginx curl -fsS https://dbangle.id/api/performance.php >/dev/null ``` ### Keamanan Rilis - Validasi paket rilis (hash/signature) sebelum ekstrak. - Pastikan izin file benar setelah switch. - Jangan letakkan kunci/secret dalam paket rilis; gunakan `shared/config`. ### Checklist Zero Downtime - [ ] Paket rilis siap, diuji di staging - [ ] Shared (uploads/logs/config) terhubung - [ ] Migrasi DB dieksekusi/direncanakan - [ ] Switch symlink sukses dan reload Nginx lulus - [ ] Health check OK dan log bersih 15 menit pascarilis - [ ] Rencana rollback jelas (versi sebelumnya tersedia) ### Ringkasan Dengan atomic deploy berbasis symlink, konfigurasi terpisah, dan prosedur health‑check+rollback yang jelas, DBANGLE dapat dirilis tanpa menghentikan layanan. Praktik ini menjaga keandalan layanan peta sekaligus memungkinkan pengembangan berkelanjutan. \n \n ## 23. Uji Fungsional dan Keamanan ### Tujuan Bab Menyediakan panduan pengujian menyeluruh untuk memastikan fitur-fitur inti DBANGLE bekerja sesuai kebutuhan dan aman dari celah umum. Fokus pada uji fungsional (alir kerja pengguna) dan uji keamanan dasar (input validation, akses, upload, header, dan konfigurasi server). ### Ruang Lingkup Pengujian - Fungsional Web: peta tematik, filter, popup, tabel, ekspor, halaman agregat (`satu_peta_lebak.php`) - Admin: login, verifikasi berkas (`pending → verified → final`), publikasi, ekspor - API v1: login PIN, daftar berkas (`get_tema_files`), unggah multipart Android - Android: login, draf offline, unggah multipart, progres, notifikasi - Keamanan: input validation, kontrol akses, header keamanan, batas unggah, CORS ### Rencana Uji Fungsional (Contoh Kasus) 1) Peta Tematik Memuat - Langkah: buka `peta_jembatan.php` - Hasil diharapkan: peta tampil, layer termuat ≤ 3 detik pada koneksi normal; popup muncul saat marker diklik; tabel terisi dan pagination berfungsi. 2) Filter Kecamatan/Desa - Langkah: pilih `WADMKC=Banjarsari`, `WADMKD=BINTANGSARI` - Hasil: hanya fitur desa tersebut tampil; `fitBounds` sesuai; tabel sinkron. 3) Tabel ↔ Marker - Langkah: klik baris tabel - Hasil: marker/polygon fokus dan popup terbuka. 4) Halaman Agregat `satu_peta_lebak.php` - Langkah: pilih kategori `sawah` - Hasil: peta kosong → data tampil setelah klik; tidak ada error konsol; performa stabil. 5) Admin Verifikasi - Langkah: ubah status berkas dari pending → verified → final - Hasil: berkas berpindah folder yang benar; metadata terbarui; UI menampilkan status terbaru. ### Rencana Uji API v1 1) Login PIN - `POST /api/v1/auth/login.php` body `{kode_desa, pin}` - Ekspektasi: 200 + `{success:true, user, token}`; untuk salah PIN → 401 + pesan umum. 2) Daftar Berkas Tematik - `GET /api/get_tema_files.php?tema=jembatan&status=final&limit=10` - Ekspektasi: 200 + daftar ≤ limit; properti `url` valid. 3) Unggah Multipart - `POST /api/v1/desa/verifikasi_peta_android.php` - Ekspektasi: 200 + `{success:true, status:'pending'}`; file tersimpan di `assets/js/pending/`. ### Rencana Uji Android (Ringkas) - Login sukses/gagal (PIN salah) - Simpan draf saat offline; unggah otomatis saat online - Progress bar dan pesan hasil - Validasi atribut wajib sebelum unggah ### Rencana Uji Keamanan (Dasar) 1) Validasi Input - Masukkan karakter spesial/HTML pada form; ekspektasi: disanitasi/ditolak, tidak dieksekusi. - Uji upload selain JSON (mis. `.php` → ditolak; ukuran > batas → 413). 2) Kontrol Akses - Akses admin tanpa login → redirect/403 - Akses verifikasi dengan role desa → 403 - Desa mengubah berkas desa lain → 403 3) Header Keamanan - Cek response header: `X-Frame-Options`, `X-Content-Type-Options`, `Referrer-Policy`, `CSP` minimal. 4) CORS - Cek hanya aktif pada `/api/`; metode `GET, POST, OPTIONS`. 5) Rate Limiting (jika aktif) - Uji 20x login cepat; ekspektasi: beberapa permintaan ditahan / dibatasi. ### Otomatisasi Ringan - Gunakan `curl`/`httpie` untuk smoke test endpoint kunci (bash script di `scripts/`): ```bash set -e base=https://dbangle.id curl -fsS "$base/api/performance.php" | jq .ok curl -fsS "$base/api/get_tema_files.php?tema=jembatan&limit=1" | jq .success ``` - Tambahkan ke cron setelah rilis untuk mendeteksi gangguan awal. ### Pelaporan - Format laporan uji sederhana (CSV/Markdown) berisi: kasus, langkah, hasil aktual, status (LULUS/GAGAL), catatan. - Simpan di `logs/tests/` dengan timestamp; tautkan pada catatan rilis. ### Kriteria Penerimaan (Acceptance) - 0 blocker (gagal fatal) pada halaman kunci dan API - ≤ 3 detik waktu muat peta untuk dataset kecil (koneksi normal) - Upload ≤ 50MB diterima; validasi berjalan; rute verifikasi aman - Header keamanan dan CORS sesuai kebijakan ### Remediasi Cepat - Jika gagal di keamanan: segera rollback perubahan atau perketat konfigurasi (Nginx/PHP) - Jika gagal di performa: pecah dataset, aktifkan cache, kurangi elemen UI berat - Dokumentasikan akar masalah dan perbaikannya ### Ringkasan Dengan rencana uji fungsional dan keamanan yang jelas, DBANGLE dapat dirilis dan dioperasikan dengan keyakinan. Pengujian rutin pascarilis membantu mencegah regresi, menjaga performa, dan memastikan data yang disajikan aman serta dapat dipercaya. \n \n ## 24. Observabilitas (Metrics, Tracing, Logs) ### Tujuan Bab Mendefinisikan pilar observabilitas DBANGLE—metrics, tracing, dan logs—agar tim dapat memahami kinerja sistem secara menyeluruh, menelusuri akar masalah dengan cepat, dan meningkatkan pengalaman pengguna secara berkelanjutan. ### Pilar Observabilitas - Metrics: angka terstruktur yang dipantau berkelanjutan (latensi, error rate, throughput, disk usage). - Tracing: jejak suatu permintaan melintasi komponen (web → API → DB) untuk menemukan bottleneck. - Logs: catatan detail kejadian (lihat Bab 20). Semua pilar saling melengkapi. ### Metrics Inti yang Dipantau 1) Aplikasi/API - Latensi p95/p99 endpoint kunci (auth, daftar_berkas, unggah) - Rasio kesalahan 4xx/5xx per 5 menit - Throughput (permintaan/menit) per endpoint 2) Server - CPU, RAM, load average - Disk usage direktori `assets/js/*`, `uploads/`, `logs/` - Koneksi terbuka Nginx/PHP-FPM 3) Database - Waktu eksekusi query berat (p95) - Deadlocks/locks berkepanjangan - Ukuran tabel utama dan pertumbuhan harian ### Implementasi Ringan (Tanpa Stack Berat) - Health endpoint sederhana: `/api/performance.php` → `{ok:true, ts, uptime}` - Ekspor metrics dasar (JSON) di endpoint internal: `/api/v1/metrics/app.json` ```json { "ts": "2025-09-15T14:33:00+07:00", "latency_ms": {"auth": 120, "tema_list": 90}, "error_rate": {"5xx": 0.2, "4xx": 1.5}, "throughput_rpm": 180 } ``` - Kumpulkan dengan cron yang menyimpan snapshot ke `logs/metrics/` untuk tren sederhana. ### Integrasi Observabilitas Standar (Opsional) - Prometheus + node_exporter untuk server metrics; blackbox_exporter untuk HTTP check - Grafana untuk dashboard (latensi, 5xx, kapasitas disk, query lambat) - Loki/ELK untuk agregasi log jika volume besar ### Tracing Sederhana - Tambahkan `X-Request-Id` (UUID v4) di setiap respons HTTP; log permintaan dan DB query besar menyertakan ID ini. - Correlate: cari `request_id` yang sama di `app.log` dan Nginx access log. - Notasi di log: `rid= path=/api/... dur_ms=123` ### Contoh Middleware PHP (Request Id) ```php $rid = bin2hex(random_bytes(8)); // 16 hex chars header('X-Request-Id: '.$rid); // simpan ke konteks global/log ``` ### Alarm dan Ambang (Threshold) - 5xx ratio > 1% selama 5 menit → kirim notifikasi - Latensi p95 auth > 1.5s selama 10 menit → investigasi - Disk usage > 80% → tindakan pembersihan (scripts/cleanup_disk.php) ### Visualisasi Minimal (Tanpa Grafana) - Halaman internal monitoring menampilkan: - Sparkline latensi p95 endpoint kunci (CSV → canvas) - Tabel 10 error terbaru (dari `app.log`) - Kapasitas disk per direktori data ### Workflow Operasional 1) Kumpulkan metrics dasar tiap 1–5 menit (cron) 2) Tampilkan di dashboard internal 3) Otomatiskan alert sederhana via script (email/Telegram opsional) 4) Rilis fitur → pantau lonjakan latensi/5xx → rollback bila perlu ### Praktik Baik - Jangan berlebihan: pilih 8–12 metrics inti yang benar‑benar berguna - Jadikan `request_id` wajib di log untuk korelasi cepat - Simpan retensi metrics mentah singkat (7–14 hari), ringkasan bulanan disimpan lebih lama ### Ringkasan Observabilitas yang efektif tidak selalu membutuhkan alat kompleks. Dengan metrics inti, request tracing sederhana, dan log yang rapi, DBANGLE memperoleh visibilitas memadai untuk menjaga performa, keandalan, dan pengalaman pengguna, sekaligus siap berkembang ke stack observabilitas yang lebih canggih di masa depan. \n \n ## 25. Dokumentasi Data dan Metadata ### Tujuan Bab Menetapkan standar dokumentasi data di DBANGLE agar setiap layer/berkas memiliki deskripsi yang jelas: asal-usul, cakupan, struktur, cara pakai, keandalan, dan status validasi. Dokumentasi yang baik mempercepat kolaborasi lintas OPD dan mencegah salah tafsir. ### Prinsip Umum - Satu sumber kebenaran: metadata resmi melekat pada setiap layer/berkas yang dipublikasikan. - Minimal namun informatif: cukup untuk dipahami pengguna non-teknis tanpa membebani pengelola. - Konsisten: format, istilah, dan satuan seragam. - Dapat dilacak: siapa memperbarui apa, kapan, dan mengapa. ### Elemen Metadata Inti (per Layer/Berkas) 1) Identitas - `nama_layer` (string singkat) - `tema` (kategori tematik), `layer_slug` - `versi` (string, mis. `1.0`, `2025.09`) 2) Sumber & Kontak - `sumber` (instansi/OPD, tautan jika ada) - `penanggung_jawab` (nama/role/kontak) 3) Cakupan & Waktu - `cakupan_wilayah` (Kabupaten/Kecamatan/Desa) - `tanggal_pembaruan` (ISO 8601) - `periode_data` (mis. 2024–2025) 4) Struktur & Skema - `tipe_geom` (Point/Polygon/MultiPolygon) - `properti_wajib` (`WADMKC`, `WADMKD`, `KODE_KEC`, `KODE_DESA`, `FTYPE`) - `properti_opsional` (daftar dan tipe) - `satuan` (mis. `LUAS_HA` dalam hektar) 5) Kualitas & Validasi - `metode_validasi` (skema/spasial/konsistensi) - `status_validasi` (`pending|verified|final`) - `catatan_keterbatasan` (asumsi, bias, kekosongan) 6) Distribusi - `format` (GeoJSON/JSON) - `lokasi_file` (URL absolut) - `lisensi` (jika ada) ### Template Metadata (JSON Pendamping) Untuk setiap berkas final, siapkan file pendamping `nama_file.meta.json` dengan struktur berikut: ```json { "nama_layer": "jembatan", "layer_slug": "jembatan", "tema": "infrastruktur", "versi": "1.0", "sumber": "DPMD Lebak", "penanggung_jawab": "Admin Kabupaten", "cakupan_wilayah": "Kabupaten Lebak", "tanggal_pembaruan": "2025-09-15", "periode_data": "2024-2025", "tipe_geom": "Point", "properti_wajib": ["WADMKC","WADMKD","KODE_KEC","KODE_DESA","FTYPE"], "properti_opsional": ["NAMOBJ","BAHAN","PANJANG_M","LEBAR_M","KONDISI","TAHUN"], "satuan": {"PANJANG_M":"meter","LEBAR_M":"meter"}, "metode_validasi": ["skema","spasial","konsistensi"], "status_validasi": "final", "catatan_keterbatasan": "Koordinat hasil verifikasi lapangan 2025 Q3.", "format": "GeoJSON", "lokasi_file": "/assets/js/final_approved/jembatan_3602042015_20250801145241.json", "lisensi": "Open Data Kabupaten Lebak (atribusi wajib)" } ``` ### Kamus Data (Per Layer) Contoh ringkas layer `jembatan`: - `WADMKC` (string) – nama kecamatan - `WADMKD` (string) – nama desa - `KODE_KEC` (string) – kode kecamatan - `KODE_DESA` (string) – kode desa - `FTYPE` (enum) – `jembatan` - `NAMOBJ` (string) – nama jembatan - `BAHAN` (enum) – `Besi|Beton|Kayu|Lainnya` - `PANJANG_M` (number) – panjang meter - `LEBAR_M` (number) – lebar meter - `KONDISI` (enum) – `Baik|Sedang|Rusak` - `TAHUN` (number, 4 digit) Kamus data ditulis di `docs/` atau sebagai field `schema_properties` pada tabel `layer_tematik`. ### Proses Pembaruan Metadata 1) Perubahan data (unggah/ETL) selesai diverifikasi. 2) Tingkatkan `versi` dan `tanggal_pembaruan`. 3) Periksa `properti_wajib/opsional` tetap sesuai. 4) Perbarui `lokasi_file` bila nama berkas berganti (timestamp baru). 5) Simpan berkas `.meta.json` berdampingan dengan GeoJSON final. ### Dokumentasi Lapisan (Layer Catalogue) - Buat daftar `layer_tematik` berisi kolom: `slug`, `nama`, `tema`, `tipe_geom`, `schema_properties` (jsonb), `versi`, `tanggal_pembaruan`. - Buat halaman katalog sederhana (admin) untuk melihat metadata, mengunduh kamus data, dan tautan file. ### Kualitas dan Review - Checklist metadata minimal harus lulus (identitas, sumber, tanggal, status_validasi, pihak kontak). - Audit triwulanan: sampling 5–10 layer untuk cek konsistensi dan kelengkapan metadata. ### Contoh Cuplikan Validasi Metadata (PHP) ```php function validateMeta(array $m){ $required = ['nama_layer','layer_slug','tema','versi','sumber','tanggal_pembaruan','tipe_geom','properti_wajib','status_validasi','format','lokasi_file']; foreach($required as $k){ if(!isset($m[$k]) || $m[$k]===''){ return false; } } return in_array($m['status_validasi'], ['pending','verified','final'], true); } ``` ### Ringkasan Dokumentasi data dan metadata yang konsisten membuat DBANGLE transparan, mudah dipakai ulang, dan siap diaudit. Dengan template `.meta.json`, kamus data per layer, serta proses pembaruan yang sederhana, setiap rilis peta memiliki konteks yang jelas bagi publik dan pemangku kepentingan. \n \n ## 26. Versi Data Geospasial ### Tujuan Bab Menetapkan tata kelola versi (versioning) untuk data geospasial di DBANGLE agar perubahan dapat dilacak, dipublikasikan secara aman, dan mudah di-rollback bila terjadi masalah. Fokus pada penamaan berkas, metadata versi, penandaan status, dan prosedur rilis versi baru. ### Konsep Versi - Versi Aplikasi vs Versi Data: dokumen ini membahas versi data (layer/berkas), bukan versi aplikasi. Namun catatan rilis aplikasi dapat merujuk ke versi data. - Skema Penomoran: gunakan kombinasi `MAJOR.MINOR` (mis. `1.0`, `1.1`) untuk perubahan terencana, dan timestamp untuk identitas berkas fisik. ### Identitas Versi - Di metadata berkas (`.meta.json`) sertakan `versi: "1.1"` dan `tanggal_pembaruan`. - Nama berkas final membawa timestamp: `tema_kodeDesa_YYYYMMDDHHMMSS.json`. - Peta daftar (manifest) menautkan ke berkas final terbaru per tema/wilayah. ### Kapan Menaikkan Versi - MAJOR (1.x → 2.0) - Perubahan skema properti (hapus/ubah tipe kolom wajib) - Perubahan CRS (tidak dianjurkan; DBANGLE baku WGS84) - Perubahan definisi cakupan (mis. agregasi berbeda) - MINOR (1.0 → 1.1) - Penambahan fitur, perbaikan koordinat, koreksi metadata - Penambahan kolom opsional yang tidak memutus kompatibilitas ### Alur Rilis Versi Data 1) Siapkan paket data hasil ETL/QA di staging; validasi semua checklist (Bab 6–7–18) 2) Tentukan versi target (MAJOR/MINOR) dan perbarui metadata (`versi`, `tanggal_pembaruan`) 3) Publikasikan berkas final dengan nama bertimestamp ke `final_approved/` 4) Perbarui manifest daftar (atau indeks) untuk menunjuk berkas terbaru 5) Simpan berkas `.meta.json` berdampingan 6) Tulis catatan rilis data (ringkas) di `logs/data_release/` ### Penandaan Status (Lifecycle) - `draft` → `pending` → `verified` → `final` - Versi hanya diberikan pada berkas `final`; versi pada tahap lain opsional. ### Manifest Data (Contoh JSON) ```json { "tema": "jembatan", "latest": { "file": "/assets/js/final_approved/jembatan_3602042015_20250801145241.json", "versi": "1.2", "tanggal_pembaruan": "2025-08-01" }, "history": [ {"file":"/assets/js/final_approved/jembatan_3602042015_20250701110010.json","versi":"1.1"}, {"file":"/assets/js/final_approved/jembatan_3602042015_20250601102005.json","versi":"1.0"} ] } ``` ### Catatan Rilis Data (Release Notes) Minimal memuat: - Ringkasan perubahan (apa yang ditambah/diperbaiki/dihapus) - Dampak ke konsumen data (apakah perlu menyesuaikan klien) - Tanggal rilis dan penanggung jawab Contoh (Markdown): ``` ## Rilis Data – Jembatan v1.2 (2025-08-01) - Tambah 37 fitur (Kecamatan Bayah, Cikulur) - Perbaiki tipe `PANJANG_M` dari string → number - Perbarui metadata, tambahkan kolom opsional `LEBAR_M` Dampak: kompatibel mundur; klien yang menampilkan lebar jembatan dapat memanfaatkan kolom baru. ``` ### Rollback Versi Data - Jika terjadi masalah, ubah manifest untuk menunjuk ke berkas versi sebelumnya. - Jangan hapus berkas lama; pindahkan ke folder arsip bila diperlukan. ### Audit dan Riwayat - Simpan salinan `.meta.json` setiap rilis; berikan hash berkas (sha256) untuk verifikasi integritas. - Catat di `audit_log` entitas `layer_tematik` aksi `DATA_RELEASE` dengan `versi` dan `file`. ### Otomasi Ringan (Skrip) - Skrip menulis/merotasi manifest tema, mengurutkan `history` berdasarkan timestamp. - Validasi sebelum rilis: pastikan `versi` meningkat atau timestamp lebih baru. ### Checklist Versi Data - [ ] Metadata `versi` dan `tanggal_pembaruan` diperbarui - [ ] Berkas final ditaruh di `final_approved/` dengan nama bertimestamp - [ ] Manifest menunjuk berkas terbaru (dan simpan riwayat) - [ ] Release notes ditulis di `logs/data_release/` - [ ] Audit log dicatat ### Ringkasan Versioning data memastikan keberlanjutan dan akuntabilitas publikasi peta DBANGLE. Dengan penamaan konsisten, metadata versi, dan manifest yang terstruktur, konsumen data selalu mendapat berkas terbaru sekaligus dapat menelusuri riwayat perubahan kapan saja. \n \n ## 27. Kepatuhan dan Privasi ### Tujuan Bab Menetapkan pedoman kepatuhan (compliance) dan perlindungan privasi untuk DBANGLE agar pengelolaan data sejalan dengan regulasi nasional serta etika publik. Fokus pada klasifikasi data, dasar hukum, pengendalian akses, publikasi data terbuka, dan tata kelola permintaan data. ### Dasar Hukum (Ringkas) - Peraturan perundang‑undangan terkait keterbukaan informasi publik dan perlindungan data pribadi (PDP) di Indonesia. - Kebijakan internal Pemerintah Kabupaten Lebak tentang pemanfaatan data dan layanan digital. ### Klasifikasi Data 1) Data Terbuka (Open Data) - Data agregat/tematik non-pribadi: peta fasilitas, batas wilayah, statistik umum. - Dapat diterbitkan di web dengan lisensi terbuka dan atribusi. 2) Data Terbatas (Restricted) - Data operasional internal: audit log, catatan verifikasi, metadata internal. - Hanya untuk admin/OPD terkait; tidak dipublikasikan. 3) Data Pribadi (Sensitive) - Data yang dapat mengidentifikasi individu langsung/tidak langsung. - Wajib diproses minimal, dienkripsi saat transit (HTTPS), dan hanya dirilis dalam bentuk agregat/anonymized. ### Prinsip Privasi - Minimization: hanya kumpulkan data yang diperlukan untuk tujuan layanan. - Purpose Limitation: gunakan data sesuai tujuan yang disetujui. - Storage Limitation: retensi terukur; hapus/arsipkan data yang tidak diperlukan. - Integrity & Confidentiality: pengamanan teknis dan organisasi yang memadai. - Accountability: jejak audit dan pelaporan insiden. ### Pengendalian Akses - Role‑based access control (RBAC): desa/kecamatan/kabupaten/OPD. - Prinsip least privilege untuk akun aplikasi dan database. - Review akses berkala (triwulan) dan ketika personel berganti. ### Publikasi Data Terbuka - Hanya rilis dataset non-pribadi dan telah final (Bab 6 & 18). - Sertakan metadata, lisensi, tanggal pembaruan, dan kontak penanggung jawab. - Format ramah publik (GeoJSON, CSV/XLSX) dan dokumentasi cara pakai. ### Permintaan Akses Data (Prosedur) 1) Pengajuan: formulir permintaan (online/email) dengan tujuan penggunaan. 2) Penilaian: cek klasifikasi, risiko privasi, dan lisensi. 3) Keputusan: setujui, batasi (agregat), atau tolak dengan alasan jelas. 4) Pencatatan: log semua permintaan dan keputusan di `audit_log`. ### Anonymisasi & Agregasi - Hapus/acak pengenal langsung (nama, NIK) bila tidak esensial. - Agregasi spasial (per desa/kecamatan) alih‑alih titik individu bila berisiko. - Generalisasi geometri (snap ke grid) untuk mencegah re‑identifikasi lokasi sensitif. ### Keamanan Tambahan - TLS wajib untuk seluruh akses; header keamanan aktif (Bab 09–11). - Validasi upload: hanya format yang diizinkan; scanning pola berbahaya. - Backup terenkripsi untuk arsip yang menyimpan data sensitif (Bab 21). ### Manajemen Insiden Privasi - Definisi insiden: kebocoran data, akses tak sah, publikasi keliru. - Alur: identifikasi → containment → pemberitahuan pihak terkait → remediasi → postmortem. - Batas waktu pelaporan internal disepakati (mis. 24–72 jam). ### Edukasi & Kesadaran - Pelatihan rutin untuk admin/surveyor terkait privasi dan keamanan. - Panduan sederhana “boleh/tidak boleh” dalam mengumpulkan dan membagikan data. ### Checklist Kepatuhan - [ ] Klasifikasi dataset ditetapkan (Open/Restricted/Sensitive) - [ ] Metadata dan lisensi jelas pada dataset terbuka - [ ] RBAC dan least‑privilege diterapkan - [ ] Data pribadi diproses minimal & dianonimkan saat publikasi - [ ] Proses permintaan data terdokumentasi - [ ] Audit trail aktif untuk akses/data release ### Ringkasan Dengan klasifikasi yang jelas, kontrol akses ketat, dan proses publikasi yang memprioritaskan privasi, DBANGLE menghadirkan transparansi tanpa mengorbankan perlindungan data pribadi. Kepatuhan yang konsisten memperkuat kepercayaan publik dan keberlanjutan pemanfaatan data. \n \n ## 28. SOP Operasional Harian ### Tujuan Bab Memberikan prosedur operasional harian yang ringkas dan dapat dijalankan oleh tim kecil untuk menjaga DBANGLE tetap sehat: pemeriksaan rutin, penerimaan unggahan, verifikasi, rilis final, pemantauan, serta penanganan insiden ringan. ### Peran Singkat - Operator (Desa/Kecamatan): unggah data dan melengkapi atribut - Verifikator (Kecamatan): review tahap 1 - Administrator (Kabupaten): verifikasi final, publikasi, monitoring - Penanggung Jawab Server: konfigurasi dan backup ### Jadwal Harian (Rutin) 1) Pagi (08:00–09:00) - Cek status situs: `api/performance.php` harus `{ok:true}` - Tinjau antrian `assets/js/pending/` → prioritas sesuai tanggal unggah - Lihat log error 24 jam terakhir (Nginx & app) 2) Siang (12:00–13:00) - Verifikasi batch (kecamatan) → tingkatkan ke `verified` bila lolos - Komunikasikan revisi ke desa jika ada masalah atribut/koordinat 3) Sore (16:00–17:00) - Verifikasi final (kabupaten) → pindahkan ke `final_approved/` - Perbarui daftar peta/manifest bila perlu - Pantau 5–15 menit pascarilis (cek peta terkait) ### Prosedur Penerimaan Unggahan (Operator/Desa) - Pastikan file GeoJSON valid (FeatureCollection, UTF-8, WGS84) - Nama berkas sesuai: `tema_kodedesa_timestamp.json` - Isi properti wajib (`WADMKC`,`WADMKD`,`KODE_KEC`,`KODE_DESA`,`FTYPE`) - Jika koneksi lemah: simpan draf lalu unggah saat sinyal baik ### Prosedur Review Tahap 1 (Verifikator/Kecamatan) 1) Ambil 5–10 sampel fitur per berkas 2) Periksa koordinat dalam batas kecamatan/desa 3) Cek atribut sesuai kamus data (Bab 6 & 25) 4) Bila lolos → pindahkan ke `verified/`; bila tidak → kirim catatan perbaikan ### Prosedur Verifikasi Final (Admin/Kabupaten) 1) Cek konsistensi antar desa (tumpang tindih, out-of-bounds) 2) Periksa metadata: sumber, tanggal, versi 3) Tetapkan status `final` dan pindahkan ke `final_approved/` 4) Simpan `.meta.json` pendamping & catatan rilis singkat ### Publikasi dan Validasi Pasca Rilis - Muat peta terkait dan uji popup/filter/tabel - Pastikan kinerja halaman stabil (<3 detik untuk dataset kecil) - Arsipkan rilis (logs/data_release/) ### Pemeriksaan Harian Server - Cek disk usage: `assets/js/*`, `uploads/`, `logs/` → target < 80% - Cek error 5xx di log Nginx; tindak lanjuti bila >1% - Pastikan backup harian sukses (lihat Bab 21) ### Penanganan Insiden Ringan - 403 halaman peta: cek anti-view-source/WAF; whitelist `peta_*.php` - 413 unggah: tingkatkan `client_max_body_size`/`upload_max_filesize` - Peta “acak-acakan”: bungkus container (`.map-frame`), panggil `map.invalidateSize()`, atau pecah data ### Komunikasi Internal - Gunakan kanal resmi untuk menyampaikan catatan verifikasi & kendala teknis - Catat keputusan (rilis/tolak) pada audit log singkat ### Checklist Harian - [ ] Health-check OK, 5xx < 1% - [ ] Pending → Verified → Final diproses sesuai prioritas - [ ] Dataset final dilengkapi metadata - [ ] Peta terkait tampil normal (popup, filter, tabel, basemap) - [ ] Disk dan backup aman (kapasitas/hasil) - [ ] Log insiden singkat dibuat bila ada gangguan ### Ringkasan SOP operasional harian menjaga ritme kerja yang konsisten: unggah → verifikasi → final → publikasi, sembari memastikan server sehat dan pengguna publik mendapatkan pengalaman yang stabil dan andal. \n \n ## 29. Troubleshooting ### Tujuan Bab Menyediakan panduan pemecahan masalah cepat untuk isu umum di DBANGLE—mulai dari error HTTP (403/404/413/500), peta tidak tampil/acak‑acakan, hingga masalah login Android dan unggah GeoJSON. ### 1) HTTP 403 pada halaman `peta_*.php` Gejala: halaman peta ditolak (Forbidden). Langkah cepat: - Periksa skrip keamanan lokal (anti view source/WAF) yang mungkin memblokir file `peta_`. - Solusi: whitelist pola `peta_`, `public_`, dan file dokumentasi; atau hentikan pemanggilan otomatis fungsi blokir pada halaman peta publik. - Pastikan izin file: pemilik `www-data`, mode `644`. ### 2) HTTP 404 (Halaman/Endpoint Tidak Ditemukan) - Cek path file di server; gunakan `ls -la` pada direktori target. - Untuk API: pastikan blok `location /api/` Nginx meneruskan ke PHP-FPM dan file benar‑benar ada. - Periksa huruf besar/kecil pada nama file (case sensitive di Linux). ### 3) HTTP 413 (Request Entity Too Large) saat unggah GeoJSON - Tingkatkan `client_max_body_size` di Nginx (mis. 50–100M). - Naikkan `upload_max_filesize` dan `post_max_size` di `php.ini` (mis. 50M) lalu reload PHP-FPM & Nginx. - Sarankan pecah file besar per kecamatan/desa. ### 4) HTTP 500 (Kesalahan Server) - Lihat `error.log` Nginx dan log aplikasi untuk stack trace. - Jalankan `php -l file.php` untuk cek sintaks. - Pastikan dependensi/require path benar dan izin file sesuai. ### 5) Peta “Acak‑acakan” atau Keluar Area Gejala: peta mengecil/geser liar, marker tidak sesuai, atau tile tidak memenuhi kontainer. - Bungkus map dengan `.map-frame`/`.map-shell`; panggil `map.invalidateSize()` setelah render. - Pakai `fitBounds(LEBAK_BOUNDS)` pada inisialisasi; aktifkan `maxBounds` jika data sering keluar area. - Untuk Point: gunakan `L.circleMarker` (lebih stabil dibanding icon) dan radius 5–8 px. - Pecah dataset besar; hindari ribuan fitur polygon sekaligus. ### 6) Popup Tidak Muncul saat Klik Baris Tabel - Simpan referensi `id→layer` ketika merender fitur. - Pada klik baris: untuk Point gunakan `layer.getLatLng()` lalu `map.panTo()` dan `openPopup()`; untuk Polygon gunakan `getBounds()` dan `fitBounds()`. - Pastikan event listener terpasang setelah table render/pagination. ### 7) Login Android Gagal (PIN) - Pastikan endpoint `POST /api/v1/auth/login.php` ada dan mengembalikan JSON (bukan HTML/404). - Fallback PIN default: 6 digit terakhir `kode_desa` jika `pin_hash` belum ada; segera ganti setelah login pertama. - Periksa `Config.apiBaseUrl` di aplikasi mengarah ke `https://dbangle.id/api/v1`. ### 8) “Format exception unexpected character at character 1 html ^” - Indikasi respons HTML dikonsumsi sebagai JSON (biasanya 404/403 dari server). - Solusi: pastikan file endpoint ada, CORS benar, dan konten bertipe `application/json`. ### 9) Unggah Multipart Android Gagal - Periksa field wajib: `kode_desa`, `tema`, `file` (GeoJSON), `meta` opsional. - Cek batas ukuran di server (Bab 09) dan MIME type (`application/json`/`application/geo+json`). - Tinjau log aplikasi (`app.log`) untuk detail validasi. ### 10) Data Tidak Tampil di `satu_peta_lebak.php` - Pastikan fungsi mengambil data langsung dari array/manifest yang sudah dimuat (bukan fetch HTML). - Periksa konsol browser untuk error JS (path/JSON parse). ### 11) Kinerja Lambat - Pecah dataset; aktifkan pagination tabel; batasi `limit` pada API daftar. - Gunakan indeks PostGIS; hindari operasi spasial berat tanpa filter wilayah terlebih dulu. - Cache aset statis (Nginx) dan precompute agregasi dashboard. ### 12) Kesalahan Metadata/Kamus Data - Pastikan properti wajib ada (`WADMKC`,`WADMKD`,`KODE_KEC`,`KODE_DESA`,`FTYPE`). - Simpan file pendamping `.meta.json` untuk setiap berkas final. ### 13) Kesalahan Izin (Permission) - File `644`, direktori `755`, pemilik `www-data:www-data`. - Direktori upload tidak boleh dieksekusi; hanya baca/tulis. ### 14) Quick Commands (Diagnostik) ```bash # cek status file dan izin ls -la /var/www/dbangle/assets/js/final_approved | tail -n 20 # uji endpoint JSON curl -i https://dbangle.id/api/v1/auth/login.php -X OPTIONS # potong log error terakhir tail -n 100 /var/log/nginx/error.log ``` ### 15) Alur Eskalasi 1) Kumpulkan bukti (screenshot, pesan error, log potongan) 2) Coba langkah perbaikan cepat di atas 3) Jika tidak selesai: eskalasi ke admin server dengan ringkasan singkat dan waktu kejadian ### Ringkasan Bab ini merangkum solusi cepat untuk masalah yang paling sering terjadi. Dengan mengikuti langkah‑langkah di atas, sebagian besar kendala dapat diselesaikan tanpa downtime panjang. Jika gejala berulang, analisis akar masalah dan perbaikan permanen perlu dijadwalkan. \n \n ## 30. Roadmap ### Tujuan Bab Menyajikan arah pengembangan DBANGLE dalam 12–24 bulan ke depan agar seluruh pemangku kepentingan memahami prioritas, ketergantungan, serta dampak terhadap layanan publik dan kolaborasi OPD. ### Prinsip Roadmap - Impact‑first: fokus pada fitur yang paling besar dampaknya ke pelayanan dan akurasi data. - Iteratif: rilis kecil namun sering, dengan umpan balik cepat dari pengguna. - Backward‑compatible: perubahan yang memutus kompatibilitas dipersiapkan transisi jelas. - Secure & reliable: setiap fitur baru mengikuti standar keamanan dan observabilitas (Bab 11 & 24). ### Kuartal 1 (0–3 bulan) 1) Konsolidasi Data Final - Audit metadata pada 10 tema prioritas; lengkapi `.meta.json` (Bab 25). - Manifest per tema (Bab 26) → tautkan “latest” dan “history”. 2) Stabilitas Frontend Peta - Terapkan pola peta stabil (Bab 14–15) ke semua halaman `peta_*.php`. - Perapian tabel + pagination konsisten; tombol ekspor Excel. 3) Android Surveyor – Reliability - Penyimpanan draf offline yang lebih tahan gangguan; retry upload dengan backoff. - Validasi klien untuk properti wajib + pratinjau GeoJSON kecil. ### Kuartal 2 (3–6 bulan) 1) API v1.1 – Analitik Ringkas - Endpoint agregasi kecamatan/desa untuk tema inti (Bab 16). - Caching 5–15 menit untuk grafik publik. 2) Dashboard Admin Ringan - Grafik unggah/verified/final per bulan; ringkasan kualitas data. - Halaman monitoring internal: latensi p95, rasio 5xx, disk usage (Bab 24). 3) Keamanan Pengguna - Rotasi PIN desa terjadwal; kebijakan kompleksitas password admin. ### Kuartal 3 (6–9 bulan) 1) ETL Semi‑Otomatis - Skrip validasi & clipping batch; laporan QA otomatis (Bab 7 & 18). 2) Pemetaan Skala Besar - Pembagian dataset per kecamatan; opsi tiling untuk polygon heavy. 3) Open Data Portal - Indeks dataset final + metadata; unduh CSV/XLSX/GeoJSON; lisensi & atribusi jelas. ### Kuartal 4 (9–12 bulan) 1) Observabilitas Lanjut - Integrasi Prometheus+Grafana (opsional) untuk metrik server & aplikasi. - Log agregasi (Loki/ELK) bila volume meningkat. 2) Hardening Keamanan - Review header CSP yang lebih ketat, audit akses per peran, uji penetrasi ringan. 3) Rilis Zero‑Downtime Penuh - Formalisasi skrip atomic deploy + rollback (Bab 22); uji di staging → production. ### Tahun Kedua (12–24 bulan) 1) API v2 - Skema respons konsisten; dokumentasi OpenAPI; paging & filter standar. - Token dengan klaim yang lebih kaya dan manajemen refresh (bila diperlukan). 2) Peta Lintas Kabupaten (Provinsi Banten) - Harmonisasi batas, kode wilayah, dan kamus data lintas kabupaten. - Manfaatkan manifest versi provinsi; koordinasi dengan OPD provinsi. 3) Analitik Prediktif (Eksplorasi) - Kajian awal integrasi model sederhana (tren kepadatan, prediksi kebutuhan fasilitas) dengan data agregat yang anonim. ### Ketergantungan dan Risiko - SDM: pelatihan verifikator & admin kunci bagi kesinambungan proses. - Infrastruktur: kapasitas disk & bandwidth untuk dataset bertambah; rencana scale‑up. - Data Governance: konsistensi kode wilayah/atribut lintas OPD; komite kecil penyelaras. ### Indikator Keberhasilan - ≥ 95% halaman peta prioritas memuat < 3 detik pada koneksi normal - ≥ 90% dataset final memiliki metadata lengkap & versi yang tercatat - Penurunan 5xx > 50% setelah monitoring+alert aktif - Waktu pemulihan insiden (MTTR) < 2 jam untuk isu umum ### Tata Kelola Roadmap - Tinjau dan sesuaikan tiap kuartal berdasarkan progres & feedback pengguna. - Catat keputusan perubahan prioritas berikut alasannya (transparansi). ### Ringkasan Roadmap ini menyeimbangkan stabilitas layanan, peningkatan kualitas data, dan ekspansi fungsional secara bertahap. Dengan iterasi kuartalan dan disiplin keamanan/observabilitas, DBANGLE siap tumbuh dari kebutuhan kabupaten menuju kolaborasi tingkat provinsi. \n \n ## 31. Glosarium ### A - Admin Kabupaten: Peran verifikator final dan pengelola publikasi data di DBANGLE. - Admin Kecamatan: Peran verifikator tahap 1 untuk data desa dalam wilayahnya. - API v1: Kumpulan endpoint JSON sederhana DBANGLE untuk auth, unggah, dan daftar berkas. ### B - Basemap: Layer peta dasar (OSM/Esri) tempat data tematik ditumpangkan. - Bounding Box: Persegi panjang batas tampilan peta awal (`fitBounds`). ### C - CORS: Kebijakan berbagi sumber daya lintas domain untuk endpoint `/api/`. - CSP (Content Security Policy): Header keamanan untuk membatasi sumber konten. - CSV/XLSX: Format tabular untuk ekspor data dari DBANGLE. ### D - Desa (kode_desa): Identitas unik desa yang dipakai untuk otorisasi dan penautan data. - Dashboard: Halaman ringkas untuk analitik dan status proses (unggah/verified/final). - Dokumen `.md.txt`: Salinan Markdown dengan ekstensi `.txt` agar tidak diblokir server. ### E - ETL: Proses Extract–Transform–Load untuk standarisasi dan pembersihan data. ### F - FeatureCollection: Struktur utama GeoJSON berisi kumpulan fitur (features). - FTYPE: Kolom jenis fitur tematik (contoh: `jembatan`, `poskamling`, `sawah`). ### G - GeoJSON: Format data geospasial berbasis JSON (Point/Polygon/MultiPolygon). - GiST Index: Indeks spasial PostGIS untuk mempercepat kueri geometri. ### H - Health‑check: Pengecekan cepat layanan (`/api/performance.php`). ### I - i18n: Internationalization; dukungan bahasa untuk antarmuka. - Indeks: Struktur basis data untuk mempercepat pencarian dan agregasi. ### J - JSON: Format data pertukaran ringan untuk API dan metadata. ### K - KOPI: Kerja Optimis Penuh Inovasi; contoh tema yang dipetakan di atas DBANGLE. - Kamus Data: Daftar definisi kolom/properti per layer tematik. ### L - Leaflet.js: Pustaka JavaScript untuk peta interaktif di web. - Layer Tematik: Kumpulan fitur sejenis yang mewakili satu tema. ### M - Manifest: Daftar berkas dan metadata ringkas untuk pemuatan di frontend/API. - Metadata: Informasi konteks (sumber, versi, tanggal pembaruan, kontak, lisensi). - MultiPolygon: Tipe geometri GeoJSON berisi beberapa poligon. ### N - NAMOBJ/NAMMAP: Kolom nama objek/entitas pada fitur tematik. - Nginx: Server web yang menyajikan aplikasi DBANGLE dan aset statis. ### O - Open Data: Data non‑pribadi yang dapat diakses publik dengan atribusi. ### P - PIN (6 digit): Autentikasi tambahan untuk akun desa. - PostGIS: Ekstensi PostgreSQL untuk fungsi geospasial. - Popup: Kotak informasi pada suatu fitur di peta. ### Q - QA (Quality Assurance): Pemeriksaan mutu data (skema/spasial/konsistensi). ### R - RBAC: Role‑Based Access Control; kontrol akses berbasis peran di DBANGLE. - Rollback: Mengembalikan rilis/versi ke kondisi sebelumnya. ### S - Sawah/Pesawahan: Contoh tema; dapat berupa Point (lokasi) atau Polygon (luasan). - Session: Mekanisme login web; cookie `HttpOnly` + `Secure`. - Simplify: Pengurangan detail geometri untuk mengecilkan ukuran berkas. ### T - Tiling/Clustering: Teknik performa untuk memecah/kelompokkan data besar di peta. - Token: Bukti autentikasi ringan pada API v1 untuk Android. ### U - Upload Multipart: Metode unggah berkas (GeoJSON/foto) dari Android. - URL: Alamat sumber daya; untuk file final berada di `assets/js/final_approved/`. ### V - Verified/Final: Status verifikasi berlapis pada data sebelum publikasi. - Versioning: Penomoran versi data; metadata `versi` + timestamp berkas. ### W - WADMKC/WADMKD: Nama kecamatan/desa pada properti fitur. - WGS84 (EPSG:4326): Sistem koordinat standar yang dipakai DBANGLE. ### Z - Zero‑Downtime Deploy: Metode rilis atomik tanpa menghentikan layanan (symlink/switch). \n \n ## 32. Lampiran ### A. Template Metadata (.meta.json) ```json { "nama_layer": "", "layer_slug": "", "tema": "", "versi": "1.0", "sumber": "", "penanggung_jawab": "", "cakupan_wilayah": "Kabupaten Lebak", "tanggal_pembaruan": "YYYY-MM-DD", "periode_data": "YYYY–YYYY", "tipe_geom": "Point|Polygon|MultiPolygon", "properti_wajib": ["WADMKC","WADMKD","KODE_KEC","KODE_DESA","FTYPE"], "properti_opsional": ["NAMOBJ"], "satuan": {}, "metode_validasi": ["skema","spasial","konsistensi"], "status_validasi": "pending|verified|final", "catatan_keterbatasan": "", "format": "GeoJSON", "lokasi_file": "/assets/js/final_approved/.json", "lisensi": "Open Data Kabupaten Lebak (atribusi)" } ``` ### B. Contoh Payload GeoJSON Minimal ```json { "type": "FeatureCollection", "features": [ { "type": "Feature", "properties": { "WADMKC": "Banjarsari", "WADMKD": "BINTANGSARI", "KODE_KEC": "360225", "KODE_DESA": "3602042015", "FTYPE": "jembatan", "NAMOBJ": "Jembatan Cibogo" }, "geometry": {"type": "Point", "coordinates": [106.28, -6.96]} } ], "metadata": { "sumber": "DPMD Lebak", "tanggal_pembaruan": "2025-09-15", "status": "verified", "versi": "1.0", "kontak": "admin@dbangle.id" } } ``` ### C. Contoh cURL API v1 - Login PIN ```bash curl -s https://dbangle.id/api/v1/auth/login.php \ -H 'Content-Type: application/json' \ -d '{"kode_desa":"3602262004","pin":"123456"}' ``` - Daftar berkas tema ```bash curl -s 'https://dbangle.id/api/get_tema_files.php?tema=jembatan&status=final&limit=10' ``` ### D. Snippet Leaflet (Style/Popup) ```js function styleByFTYPE(p){ const m={jembatan:{color:'#1d4ed8',weight:2,fillOpacity:0.15},poskamling:{color:'#16a34a',weight:1,fillOpacity:0.15},sawah:{color:'#22c55e',weight:1,fillOpacity:0.25},default:{color:'#0ea5e9',weight:1,fillOpacity:0.2}};return m[p.FTYPE]||m.default;} function popupHtml(p){return `${p.NAMOBJ||p.NAMMAP||'-'}
Desa: ${p.WADMKD||'-'}
Kec.: ${p.WADMKC||'-'}
Jenis: ${p.FTYPE||'-'}`} ``` ### E. Checklist Singkat - GeoJSON: UTF‑8, WGS84, FeatureCollection, properti wajib ada - Nama file: `tema_kodedesa_timestamp.json` - Validasi: skema/spasial/konsistensi lulus - Metadata: `.meta.json` berdampingan - Rilis: pindah ke `final_approved/`, perbarui manifest ### F. Referensi Cepat - Leaflet: `https://leafletjs.com/` - PostGIS: `https://postgis.net/` - GeoJSON: `https://geojson.org/` - ColorBrewer: `https://colorbrewer2.org/` ### G. Kontak Teknis - Admin DBANGLE: admin@dbangle.id - Pemutakhiran data: melalui panel admin atau kanal internal yang disepakati \n