How FieldPoint is put together, and how to describe it in your own work.

Getting started

Setting up a new project follows the same four steps regardless of discipline.

1. Create the project

   Name it, add a description, and record the principal investigator and institution. Turn on weather if the project needs it, it stays off by default.

2. Build the schema

   Check off the auto-capture fields you want from the catalog below, then add any custom fields your discipline needs. Mark required fields and set units before you collect a single point.

3. Collect points

   Opening "Add point" immediately captures the location and device fields you selected, then presents your custom fields for you to fill in. Attach photos if the schema includes them.

4. Export or sync

   Generate a research export, GeoJSON or CSV, when you're ready to analyze or publish. Export a backup any time as a safety net, or sync to the cloud if you're on the paid tier.

Core concepts

Schema per project, not schema per app

Every project defines its own field set independently. There is no single global form that every dataset is forced into, a soil survey and a coastal erosion study can share the app while producing structurally different records.

Versioning, not mutation

If a field is added or removed mid-project, FieldPoint snapshots a new schema version instead of altering the existing one. Older points keep the schema they were collected under, and every point stores which version applies to it.

Capture raw, derive later

Sensor readings are stored exactly as the device reported them, with their original units and precision. Rounding or unit conversion happens at export or display time, never at the moment of capture, so nothing is lost upstream.

Provenance as a first-class field

Collector identity, device model, GPS accuracy, and both UTC and local timestamps are recorded automatically on every point. This is the metadata a reviewer typically asks for, already attached rather than reconstructed later.

Local-first, cloud-optional

The device is the source of truth. Cloud storage is an opt-in, paid convenience layer for backup and device migration, never a dependency for core functionality.

Field catalog

These fields are available to any project's schema and, once selected, are captured automatically with no extra input required at the moment of collection.

Custom field types

Custom fields cover whatever a device cannot report on its own, species, counts, site condition, anything specific to the discipline.

Weather data and the end-of-session sweep

This section is written so it can be adapted directly for a methods section, supervisor question, or peer review response.

Why a sweep instead of per-point fetching

Weather is gathered in a single batch after a collection session ends, rather than one call per point while you're in the field. This keeps network calls off the critical path during collection, a poor-signal area never leaves you waiting on a request, and a failed call never costs you a data point. The sweep can be run once you're back on a stable connection, and retried in full if needed.

How points are grouped

Two points fall into the same group when they share both a location, rounded to roughly 0.1 degrees of latitude and longitude, about a 10 kilometre cell, and a time, rounded to the same hour. One request is made per group, using a representative point, and the result is applied to every point in it. These thresholds are adjustable per project if a study needs finer resolution, for example work spanning a strong elevation or coastal gradient.

How provenance is recorded

Because grouped points share a reading, not every point was independently measured, and FieldPoint makes that explicit rather than implied. Every point stores:

• Weather source, either direct (queried using that point's own coordinates and time) or cluster (inherited from another point in the group)
• Cluster source point, a reference to the specific point that was actually queried, for any inherited value
• Fetch time and the complete raw response from the weather service, retained for audit

Export formats

GeoJSON

One FeatureCollection per project holding every point as a Feature. Coordinates are three dimensional, longitude, latitude, altitude, since QGIS and ArcGIS both render 3D point geometry natively. Altitude is also duplicated into properties.altitude_m so it stays legible in an attribute table and survives a CSV re-export where geometry can be dropped.

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": { "type": "Point", "coordinates": [-76.7936, 17.9712, 812.4] },
      "properties": {
        "field_number": 42,
        "soil_ph": 6.4,
        "_meta": {
          "collector": "K.B.",
          "collected_at_utc": "2026-07-02T19:32:05Z",
          "gps_accuracy_m": 3.1,
          "schema_version": 3
        }
      }
    }
  ]
}

CSV

One row per point, every field flattened to a column, separate latitude and longitude columns for a straightforward "Add Delimited Text Layer" import, plus an altitude_m column and ISO 8601 timestamps throughout.

Data dictionary

A generated table of field name, type, unit, and description ships alongside every export. This is the piece that makes a dataset defensible as publication supplementary material.

Backup and restore

The .fpa archive

Backups use a .fpa extension, but the file underneath is a standard zip archive: a raw copy of the local database, the project's photo folder, and a small manifest. Renaming .fpa to .zip and opening it any other way works fine, since zip readers identify files by signature, not extension.

What the custom extension actually buys you:

• Tapping a .fpa file in Files, Drive, or a mail attachment offers to open it directly in FieldPoint
• Casual tampering is discouraged, since a .fpa looks less inviting to unzip and hand-edit than an obvious .zip
• Before trusting any data, FieldPoint validates the archive: is the manifest present and correctly formed, does the format version match what this build understands, does the database checksum match

Restoring and merging

Restoring is picking a saved .fpa file and importing it, safe to do even on a device that already has local data, since every ID is globally unique, so a restore is always "insert if not already present," never a collision. If an incoming record and an existing one share the same ID but genuinely differ, FieldPoint shows both versions side by side so you decide which to keep. For a batch with too many conflicts to review individually, the newest edit wins automatically, and the auto-resolved records are logged for later review.

The Web Portal

A browser-based companion for viewing a synced project without installing anything, deliberately kept lightweight rather than trying to replace desktop GIS software.

Because editing only ever touches a project once it has synced to the cloud, the server is the single source of truth for that copy the moment sync happens, which is what makes browser editing safe without a complex offline-merge system.