SIDAKAR — Early Detection & Reporting of Forest and Land Fires in West Papua
SIDAKAR (Forest and Land Fire Control Information System) is the early warning and detection system for forest and land fires owned by the West Papua Provincial Forestry Service, available on Android and the web with the same data on both. The challenge is specific to West Papua: vast forests, villages far apart, and a signal that often drops — while satellite hotspot data already existed in SIPONGI, Indonesia's national fire monitoring system, it wasn't connected to action on the ground. SIDAKAR connects the whole chain: satellites detect, residents and field officers report, teams verify and put fires out, and everything is recorded as provincial data. A resident simply opens the app and taps Report a Fire — no account needed — then sends a photo and a GPS point; with no signal, the report is saved on the phone and sends itself once connected. Field officers (fire brigades and forest farmer groups) record suppression, patrols, and awareness campaigns; forest management unit staff manage reports, publications, and news; administrators verify accounts and compile burned-area estimates per regency. Screenshots on this page use sample data.
- Platform
- Android · Web
- Year
- 2025–2026
- Industry
- Government / Forestry & Disaster Management
- Role
- Full-cycle: architecture, Flutter app for Android & web, Cloud Functions ingesting satellite data, offline reporting, security rules & testing
Impact on the ground
What changes for the people who use it every day.
- 01
Reports get through, even without signal
Many fires start far beyond network coverage. The report and its photos are saved on the phone first, then send themselves once the phone reconnects — the reporter doesn't have to redo anything.
- 02
Residents can report in minutes
No account to create: a photo of the fire, coordinates from the phone's GPS, then send. The easier reporting is, the sooner officers know about a fire.
- 03
Officers know which areas come first
Hotspots from five satellites are pulled from SIPONGI every 10 minutes and mapped by regency and confidence level — not just a number, but a list of areas to check first.
- 04
Every control activity is on record
Suppression, patrols, and awareness campaigns are logged straight from the field with team, personnel, equipment, obstacles, and documentation — and every resident report clearly shows whether it has been handled.
- 05
A provincial recap without re-compiling
Burned-area estimates per regency per year live in one place and export to PDF for official reports, with no need to gather files from each regency again.
- 06
Yearly trends for planning
Monthly hotspot charts going back to 2019 reveal the high-risk months, so patrols and awareness campaigns can be prepared before the fire season arrives.
App screenshots
Click an image to zoom — swipe left/right to browse.
Key features
Report a fire without an account
From the welcome screen, anyone can report an incident with photos, location, and a GPS point — the reporter's name is optional, since some residents are hesitant to identify themselves.
Offline reporting
Reports and photos are stored on the phone, listed under My Reports, and sent automatically when the app opens, the signal returns, or the user signs in.
Satellite hotspot map & data
The last 48 hours of hotspots from five satellites, filterable by confidence level and satellite, plus a ranking of regencies with the most hotspots.
Monthly trend charts
Hotspots per month compared across years, per satellite and confidence level — with the total, peak month, and number of active months.
Five types of fire control reports
Fire incidents, suppression, patrols, awareness campaigns, and other activities — each with fields for team, personnel, equipment, area, obstacles, strategy, and documentation.
Handling status & verifier
Every incident report is marked as handled or not yet handled, along with the officer who verified it — shown as progress on the reports screen.
Burned-area estimates & PDF
A recap of estimated burned area per regency per year, with a trend chart, search, and PDF export for official reporting.
Publications & news hub
Staff upload fire-risk maps, patrol reports, suppression reports, and equipment reports, and publish news for the public.
Four roles & account verification
Residents, field officers, administration (forest management units and partner agencies), and administrators — officer accounts activate after an administrator verifies them.
Technical highlights
The advanced parts behind the scenes that make this system run smoothly.
- A scheduled Cloud Function pulls the last 48 hours of hotspots from SIPONGI every 10 minutes and splits them into Firestore documents of at most 1,500 points each. It runs as a single instance so two calls never overlap, and when SIPONGI fails the app keeps showing the last data that was fetched successfully.
- The SIPONGI server allows only 3 requests per minute and 15 per hour. The old version sent 12 requests per year of data, so many months failed silently and showed zero; now one year takes a single request, cached in layers (memory, device, shared Firestore), and completed years are fetched once for all users.
- Offline report queue: each report is its own folder on the phone holding the data and copies of the photos — because the camera's original files can be removed by the system at any time. Sends interrupted midway go back into the queue, with retry backoff so the server isn't flooded.
- Reporters without an account prove that follow-up photos are theirs with a secret code that exists only on their phone; the server keeps only its hash. A Cloud Function then attaches the photos to the report, so reporters never need permission to edit the report itself.
- Firestore security rules deny everything by default: roles and verification status can't be changed by the account owner, and the only write allowed without signing in is an incident report with strictly validated data — tested automatically on the Firebase emulator.
- Report definitions and the regency list, previously copied across ten files — and inconsistent between them — are unified into one schema, keeping the old Firestore field names so already-stored data still reads correctly.
Tech stack
Want an app like this for your business?
We've built systems like SIDAKAR from scratch all the way to production. Tell us what you need — the initial consultation is free, no strings attached.

