XLSForm with rules
Writes survey and choices with geopoint, a photo conditioned by relevant, constraint and required, and converts with xls2xform before publishing.
Octo for QField, Mergin Maps, ODK and KoboToolbox
A QGIS project on a phone with QField or Mergin Maps, an XLSForm with ODK or KoboToolbox: all open source, all with an API. Octo writes the form, prepares the project, measures each team's sync and checks accuracy, area, duplicates and photos before the data goes into the database. What is collected about each person, what is accepted and what goes back for a revisit stay with the technical lead, the field coordinator and the data protection officer.
Six possible deliverables, taken from the survey. All of them start by reading the project, the form or the server without changing anything, and all go through the coordinator before reaching the field team.
Writes survey and choices with geopoint, a photo conditioned by relevant, constraint and required, and converts with xls2xform before publishing.
Checks relative paths, layer constraints, the attachment widget and the orthophoto clip before packaging for QField or Mergin Maps.
Deliverable: packaged project and list of what was adjustedPulls from the server with mergin pull, qfieldcloud-cli or pyodk and counts by team and by day; a team with no increase becomes a question.
Flags points with accuracy above the round's limit, points outside the team's area and points in another team's area, already in SIRGAS 2000 / UTM.
Deliverable: exceptions by team for revisitChecks that every required photo exists, that every photo has a record and that no file arrived empty; photos with people in them enter the LGPD discussion.
Deliverable: list of missing, orphaned and empty photosThe same rules in SQL in PostGIS, as an exceptions view; nothing is deleted or moved, and what is accepted goes in with a note.
Deliverable: exceptions view + summary by teamThe same Octo cycle, applied to the field. Each arm has a narrow role; people decide what is collected, what goes in and what goes back.
Layers, fields, rules, paths, form version, sync server and who has an account.
Types, domains, relationships, a task layer and the check rules written with the coordinator.
Name, ID and phone fields with no need, photos with people, tokens in files, a server with open sign-up.
QGIS project on a phone or XLSForm; hosted or in-house server; external GNSS when accuracy calls for it.
XLSForm, project preparation, daily count and check, with the source of each rule noted.
The test submission arrived with point, accuracy and photo; the count matches. A form that converts without errors can still have a wrong rule.
Form publishing, project upload and schema changes happen between rounds and with the coordinator's approval.
Form or project version, teams, accepted exceptions and who approved, so the next round starts from the right point.
Octo works with read access and as support. It does not publish forms, delete submissions, move points or decide what is collected about a person.
The criteria Octo uses to choose, with each project's documentation.
| Task | Path | Note |
|---|---|---|
| Edit existing features in the field | QField ou Mergin Maps | The layer is the same as in the office |
| Inspection with many questions and skips | XLSForm in ODK or KoboToolbox | relevant, constraint, required |
| Convert and validate the form | xls2xform (pyxform) | Structure, not rules |
| Download submissions from ODK Central | pyodk, submissions.get_table | Configuration in ~/.pyodk_config.toml |
| Property list that goes out and comes back | ODK Entities (/projects/:id/datasets) | One form updates, another looks up |
| List projects in QFieldCloud | qfieldcloud-cli --json list-projects | Token in QFIELDCLOUD_TOKEN |
| Pull a project from Mergin Maps | mergin download and mergin pull | Token in MERGIN_AUTH |
| Export from KoboToolbox | API v2 (JSON, CSV, XLSX) | v1 is deprecated |
| Centimeter accuracy | QField with external GNSS and NTRIP | Reference system decided by the technical lead |
| Daily check | GeoPandas or a view in PostGIS | Exceptions table, nothing deleted |
Three steps. Each one only makes sense after the previous one has shown results on your team.
A proposal, not a promise
Octo reads the project, the form and the server and lists missing rules and personal data, without changing anything.
A form with rules, a checked test submission and the round's exceptions table.
Each round with a logged version, a nightly check and database entry with a note of what was accepted.
Each point below has a source published by the project or by the organization responsible for the standard. The sources are in the next section.
5
points with a published source, each with its reference shown alongside.
mergin CLI with download, pull and push.Source: MerginMaps/server, mobile and python-api-client repositories/projects/:id/datasets; submissions as a table with submissions.get_table.Source: getodk/central releases, Central API and pyodk documentationOcto prepares everything, but it does not sign. The document of record stays with whoever is accountable for it.
Surveys, calculates, organizes and produces the documents: spreadsheets, reports, maps and drafts.
Deliverable: material ready to checkThe licensed professional checks what Octo delivered before signing. If something doesn't add up, it goes back to Octo with the correction.
Step: review by the signerOcto does not sign. Projects, technical reports, ART/RRT, accountability reports and any official document are still signed by the company's or agency's licensed professional: here, the technical lead for the map or the survey.
Signature: technical lead for the map or surveyRepositories, release pages, project documentation, PyPI and the LGPD, consulted on Oct 31, 2026.
The assessment starts by reading the project, the form and the server, without changing anything. You get the list of missing rules, personal data collected and the decisions only your team makes, and you decide with it in hand.