Built for the field
Enumerators and coordinators record each machine and implement, and who owns it, on-site, syncing automatically once connectivity returns.
Philippine sugarcane mechanization
Mechanization Resource Mapping, Monitoring and Data Analysis System.
M3DAS collects field data on agricultural machines and their implements, from respondents across sugar mill districts nationwide, even without a signal, then verifies, maps, and analyzes it to support evidence-based mechanization planning.
From field records to policy-ready insight
Built around one governed set of records.
Collected in the field, often offline, then verified, mapped, and analyzed for planning across the sugarcane industry's mill districts.
Reviewed, not just collected
Survey managers and administrators verify every uploaded record by mill district before it counts toward the shared picture.
Seen on the map, read in reports
Verified records become an interactive map and district-level statistics that support evidence-based mechanization planning.
One shared system
Six components, one governed set of records.
A mobile app for the field, and a desktop suite for managing, mapping, analyzing, and administering what it collects.
Field surveys, even without signal
Enumerators and coordinators record respondents, machines, and their implements, with everything queued locally until sync.
- Works fully offline after initial setup
- GPS position and photos captured with each record
- Client-generated IDs prevent duplicate uploads
Review, verify, and export records
Survey managers and administrators inspect, filter, and correct uploaded data by mill district before it counts as verified.
- Search, filter, and sort by any field
- Manual verification before a record is trusted
- CSV, JSON, and SQL export
See where the machines are
An interactive map of surveyed machines and implements, filterable by mill district, commodity, and survey period.
- Sugar mill and SRA district office reference layers
- Marker clustering for a clear view at any zoom
- Deep links to a specific record's own details
Statistics for planning
Descriptive statistics and charts over verified survey data, per mill district and survey period.
- Available power per hectare, by machine type
- CSV export of any table
- Scoped to what each role may see
Accounts, roles, and reference data
Role-based account approval, mill district and office reference data, and platform-wide settings, all audit-logged.
- Seven roles, from Enumerator to System Administrator
- Every sensitive change written to an audit log
- System Administrator succession with no single point of failure
A public account for the map and reports
Anyone may create a public account to view a map and reports explicitly marked public, kept separate from operational survey data.
- Account creation and sign-in still required, at the lowest access level
- A distinct Public Web Map, not the operational one
- No access to Database Management or the full Reporting view
Built for real-world connectivity
A foundation designed for the field, not just the office.
The mobile app stays fully usable without a connection, and nothing is silently overwritten when it reconnects: a conflicting change is always queued for a person to review.
Offline sessions stay secureSession material lives in the device's own secure storage, not plain local storage.Sync resolves conflicts by handNo automatic merge; a conflicting record waits for manual review.
Trust is a design principle
Records handled with care, on-device and on the server.
Concrete protections already designed into the platform.
Backups use vetted encryption
Local encrypted backups rely on an established, vetted cryptographic method, never custom-built encryption.
One authorization boundary
Every permission check runs through a single, centrally defined boundary in the backend, not scattered across screens.
Every sensitive action is logged
Approvals, role changes, and reference-data edits are written to an audit log administrators can review.
Protection in layers
Trust should be visible in how the system works.
Identity, permission, and accountability checks work together around every protected action, not a single gate.
- 01Identity is verifiedAn account needs a verified email before it holds any capability, checked at the same central boundary as its status.
- 02Every action is authorizedThe backend/API is the sole authority for authentication and authorization; no component implements its own.
- 03Sensitive changes are recordedEvery approval, role change, and status change is written to an audit log, together with who acted.
Request access to view the outputs of the M3DAS project.
Create an account, or sign in if you already have one. An administrator reviews every request.