QField PostGIS: from the field to the web map, no export

The field, PostGIS, Lizmap chain

Three open source tools, three roles. QField collects on the phone. PostgreSQL and PostGIS store the spatial data. Lizmap, served by QGIS Server, publishes the QGIS project as a web map. The link between them is the sync service: LizPack Field, which relies on the same sync technology as QFieldCloud and works with the official QField app.

1. The surveyor captures data in QField, with or without a network.
2. Back in coverage, they sync: changes go up to LizPack Field.
3. With the Pro plan, LizPack Field writes the data directly into the project's PostGIS layers.
4. The Lizmap map that displays these PostGIS layers updates at each sync, with no manual step.

LizPack is an open source geospatial infrastructure: it is not the author of any of this software, it hosts, connects and maintains it. See what LizPack does.

The value of this chain lies in having no manual step. Without it, you must collect each surveyor's files, merge them, fix duplicates, then reimport everything into the database and republish the map: so many chances to lose or duplicate records, and days of lag between the field and what decision makers see.

What you need to connect QField and PostGIS

With the LizPack Field Free plan, data stays in the project files, which you retrieve in QGIS: the PostGIS connection requires the Pro plan, 15 USD per month at the time of writing. Current prices on the pricing page.

All these components are managed from the same LizPack account: the database, the LizPack Map instance and LizPack Field share the same sign-in. You therefore do not need separate credentials for each service, and the link between the database and the instance is made from the customer area, with no server work.

Choosing your LizPack Map instance

The web map in the QField PostGIS chain is served by Lizmap. At LizPack, that is the role of LizPack Map: a Lizmap instance on your subdomain, with QGIS Server, a PostGIS database and a tile cache, online in about four minutes, with an HTTPS certificate renewed automatically.

Two setups are possible. Either the data goes into a dedicated database, created separately and sized from 1 to 10 GB, which both the instance and LizPack Field read. Or it goes into the database included with the instance. The dedicated database has the advantage of being independent from the instance: you can keep it if you change instances.

Prices at the time of writing: LizPack Map Basic 10 USD per month, Pro 20 USD per month. Current pricing on the pricing page.

Prepare the PostGIS layers in the QGIS project

The core rule: collection layers must be PostGIS layers in the QGIS project, not local files. Those are the layers LizPack Field feeds.

1. In QGIS, add the connection to your PostGIS database with the host, port and credentials provided when it was created.
2. Create the collection tables in the database, with an auto-increment primary key and a geometry column of the right type and coordinate system.
3. Add these tables to the project as PostGIS layers and configure their forms: value lists, constraints, default values, photos.
4. Add the basemaps and context layers useful in the field.
5. Save the project and publish it to LizPack Field from QGIS.

• A reliable primary key avoids conflicts when several surveyors create features offline at the same time.
• Keep field names simple, without spaces or accents: they will be easier to use in SQL and in Lizmap.
• Test a full round trip with a single surveyor before opening the project to the whole team.

Example: a collection table ready for QField

Here is a water point table as you might create it in the database, from the QGIS DB Manager or pgAdmin. It applies the rules from the previous section.

CREATE SCHEMA IF NOT EXISTS survey;

CREATE TABLE survey.water_points (
  id serial PRIMARY KEY,
  structure_type text NOT NULL,
  condition text NOT NULL,
  survey_date timestamptz DEFAULT now(),
  surveyor text,
  photo text,
  validated boolean DEFAULT false,
  geom geometry(Point, 4326) NOT NULL
);

CREATE INDEX ON survey.water_points USING gist (geom);

CREATE VIEW survey.water_points_validated AS
  SELECT * FROM survey.water_points WHERE validated;

• id serial: a primary key numbered automatically by the database, which avoids collisions between surveyors.
• NOT NULL on type and condition: the database rejects an incomplete record, on top of the form constraints.
• DEFAULT now(): the entry date fills itself in.
• geometry(Point, 4326): an explicit type and coordinate system that QGIS and Lizmap read without ambiguity.
• The spatial index speeds up display in QGIS and in the Lizmap map as the number of records grows.
• The validated-records view feeds the public map: only features marked as validated by the lead appear there.

Then add the table to the QGIS project as a PostGIS layer, configure its form, and add the view to the project published in Lizmap. Adapt the coordinate system to your country if your reference data uses a different one.

Display the data in Lizmap

For the web map, publish a QGIS project that reads the same PostGIS layers on your Lizmap instance. It can be the collection project itself or a separate viewing project, with other styles and without internal fields. Upload it from the browser or from QGIS with the LizPack Publisher plugin, as described in publish a QGIS project online.

Since Lizmap reads the database directly, there is nothing to republish after a campaign: each QField sync updates the database, and the map shows the current state on the next load. PostGIS layers served by Lizmap can also be edited online, from the office.

To share the data by link without a Lizmap project, LizPack Viewer, included with LizPack Field, builds a map from the layers of your projects. See create a map online and share it.

If office staff need to correct records from the web map, enable editing for the layer in the project's Lizmap configuration, with the Lizmap plugin in QGIS, and restrict it to the relevant user groups. Corrections are written to the same PostGIS table as the QField records.

Check that the chain works

Before opening the campaign to the whole team, do a full round trip and check each link. If a record does not make it to the end, this list helps find where it stops.

1. On a phone, capture a test feature in QField and sync.
2. In the LizPack Field dashboard, check that the change appears among the changes received and in the job log.
3. In QGIS Desktop, open the PostGIS table and look for the feature by date or surveyor.
4. Open the Lizmap map and reload the page: the feature should appear, or appear only in the public view once validated.
5. Delete the test feature, then check that the deletion is carried through everywhere.

• The change does not appear in LizPack Field: the sync did not complete; check the phone's network and run it again.
• It appears in LizPack Field but not in PostGIS: check that the account is on the Pro plan and that the project layer is really a PostGIS layer, not a local file.
• It is in PostGIS but not on the map: check that the Lizmap project reads the same table or the right view, and that the feature meets the view's filter.

Several surveyors on the same database

As soon as several surveyors collect into the same PostGIS layers, a few rules prevent conflicts and inconsistent data. They are decided when preparing the project, not after the first campaign.

• Create rather than edit. New features combine easily: each surveyor adds their own points. Edits to the same feature by two surveyors are trickier; assign sectors so that an existing feature is touched by only one person.
• Track where each record comes from. Add fields for author and entry date, filled automatically by an expression. They serve quality control and progress statistics.
• Separate collection and publication. Surveyors write to the collection tables; the public map reads a view that shows only validated records. The lead validates at the office by changing a status field.
• Keep reference layers read-only. Administrative boundaries, cadastre or existing networks serve as context in the field and do not need editing from QField.

Another point to plan: changes to the data model. Adding a field to a PostGIS table during a campaign is possible, but the QGIS project must then be updated and republished to LizPack Field, and surveyors must get the new version before continuing. Group these changes and make them between campaigns, after telling the team.

Finally, think about volume. Photos taken in the field quickly take up more space than the data itself. Watch the storage of your LizPack Field plan and your database, and choose a reasonable photo resolution in the form.

Before each new campaign, hold a quick check-in with the team: which layers are open for editing, which sectors are assigned to whom, which fields have changed. Five minutes of coordination save hours of cleanup in the database, and the published Lizmap map stays consistent for those who view it.

Put the QField PostGIS database to work

Once the data is in PostGIS, all your tools can reach it without export: QGIS Desktop, pgAdmin, DBeaver, your scripts, and GeoServer if you publish OGC services with GeoServer Cloud.

• Monitoring SQL queries: features collected per day, per surveyor, per area.
• Views for the public map that hide internal fields.
• Quality checks: invalid geometries, empty required fields, duplicates.
• Storage monitoring: emails warn you as soon as the database reaches 60% of its volume, then at 75, 80, 90 and 95%.

For project preparation and fieldwork, see the QField field data collection guide.

Since the database is a standard PostgreSQL database, you can also take its contents out at any time with the usual PostgreSQL tools, for an archive or a transfer. Nothing in the chain locks your field data into a proprietary format.

Common mistakes in the QField PostGIS chain

• Collecting into a GeoPackage while expecting PostGIS to fill up. Only the project's PostGIS layers are written to the database; a file layer stays in the project files.
• A table without a primary key. QGIS sometimes loads it read-only or handles it poorly; always add a primary key before publishing.
• A different coordinate system between the table and the project. Features show up in the wrong place or not at all; set it when creating the table.
• Changing the structure mid-campaign without republishing. Surveyors work on the old version of the project and some fields do not come back.
• Publishing the raw table on the public map. Unchecked records and internal fields become visible; go through a view.

None of these mistakes is serious if caught during the test described above. That is why a full round trip with a single surveyor remains the most worthwhile step of the whole setup.

Frequently asked questions