Frequently asked questions

Straight answers, including the ones that are still open questions.

If something below raises another question, the documentation goes deeper on most of these topics.

Getting started and pricing

The core app is free for everyone: schema building, offline collection, the full auto-capture field set, and manual backup and restore to your own cloud storage all work with no account and no payment. The paid tier adds automation on top of that, scheduled backups you don't have to remember to trigger, optional hosted cloud storage, and multi-device sync for teams. Nothing about basic data-loss protection is gated behind a paywall.

Convenience and automation, not a different level of data safety. Free users can back up and restore manually at any time. Paid adds automatic backups triggered by collection activity rather than a fixed schedule, hosted storage if you'd rather not manage your own, and near real time sync for labs with more than one collector working the same project.

FieldPoint is a mobile app. Most fields work on any modern phone, though barometric pressure depends on a sensor that not every device has, the schema builder marks it as possibly unavailable rather than failing silently if yours doesn't.

Data model and schema

FieldPoint snapshots a new schema version rather than editing the existing one. Points already collected keep the schema they were captured under, and every point records which version applies to it. Nothing already recorded changes shape retroactively, which matters for defending the dataset later.

Yes. Every record gets a globally unique identifier generated on the device, so a second collector or a second device can join a project later with no data migration and no clashing sample numbers. A human-facing sequential number and collector initials keep the display friendly while the underlying IDs stay collision-safe.

Yes, by default. Points and photos write to the device immediately and nothing about core collection depends on connectivity. The one feature that needs the internet is weather, and it's deliberately handled separately from the moment of collection so a dead zone never costs you a data point.

Weather data

Fetching weather needs a connection, and fieldwork often happens without one. Doing it during collection would mean waiting on a network request in the field, and a failed call would cost you a data point. Instead, FieldPoint offers a single weather sweep at the end of a session, run whenever you're back on a stable connection, and it can be retried in full if it fails.

Points collected close together in space and time share one weather reading instead of each making an independent call, since conditions do not meaningfully differ between two samples a few metres apart within the same hour. Every point records whether its weather was queried directly or inherited from a nearby point, plus the source point it came from, so the method is fully traceable rather than hidden. It's a disclosed, tunable method, not a shortcut that gets papered over.

Yes. The default groups points within about 0.1 degrees and the same hour, but the thresholds are adjustable per project, useful if your study spans a steep elevation or coastal gradient where conditions genuinely change over short distances.

Export and backup

GeoJSON with 3D coordinates for QGIS and ArcGIS, a flattened CSV with separate latitude and longitude columns for delimited text import, and a generated data dictionary describing every field, its type, its unit, and its description.

It's a standard zip file with a custom extension, so tapping one opens it directly in FieldPoint, but renaming it to .zip and opening it any other way works fine too. What the extension actually buys you is validation: before anything is imported, FieldPoint checks that the archive is genuinely a FieldPoint backup, that the version is one it understands, and that the database inside matches its recorded checksum.

On purpose. A backup exists to recover fieldwork after a lost or broken device, and a forgotten passphrase would defeat that entirely. For research field data, integrity and version safety matter more than secrecy, so encryption isn't the default. It's not credentials or medical records.

Not unless you choose to sync it. The device is the source of truth by default, and cloud storage is an opt-in paid convenience for backup and device migration, never a requirement for core functionality.

The Web Portal

No. It's a companion for viewing and lightly editing a project from a browser once it's synced to the cloud. If you collect on mobile and export straight to QGIS or ArcGIS, you never need to touch it.

No, and this is deliberate. The portal allows attribute edits, correcting a mistyped value or a misspelled species name, but never geometry edits. If a point's coordinates are genuinely wrong, that's a data integrity event worth flagging and investigating, not something to silently drag to a new spot on a map.

No. It's intentionally lightweight, for viewing data and fixing obvious mistakes without installing desktop GIS software. Anyone doing spatial analysis, buffering, intersecting, reprojecting, is still better served exporting to QGIS or ArcGIS and working there.

Still have a question?

The documentation covers the data model, field catalog, and export formats in full detail.

Go to documentation