Dataset Detail

A dataset is the unit of content in GeoLens: every layer on a map, every record in a search, every export comes from a dataset. The detail page is where you see all of it: a quick overview, the actual feature rows, the full metadata form, the attribute schema, where the data came from, and the access controls that govern who can see what.

Tabs

The detail page uses a tab strip across the top. Tabs are URL-hash-driven, which means each tab has its own deep-link URL:

https://your-instance/datasets/<id> (defaults to Overview)
https://your-instance/datasets/<id>#overview
https://your-instance/datasets/<id>#metadata
https://your-instance/datasets/<id>#data
https://your-instance/datasets/<id>#structure
https://your-instance/datasets/<id>#sources
https://your-instance/datasets/<id>#access

Bookmarking a tab-specific URL takes you straight to the right view: useful for handing a colleague a “look at this metadata” link, or for embedding a preview deep-link in a ticket.

Not every tab appears for every dataset. Overview, Metadata, Source, and Access are always present; Data and Structure appear for vector and table datasets only. Deep-linking to Data or Structure on a dataset that doesn’t show them falls back to Overview.

Overview tab

Above the tab strip, and so visible from every tab, the page renders a map preview of the dataset for spatial datasets; non-spatial tables get a short “no map preview” note there instead, and their rows live on the data tab. The preview uses default styling; for full styling control, open the dataset in the Map Builder.

The overview tab itself is the dataset’s at-a-glance view:

About this dataset: the summary text, editable inline if you have permission.
Details card: license, source organization, source format, PostGIS table, maintainer, created date, and update cadence. Bounding box and CRS are deliberately not repeated here; they live on the metadata tab.
Right-hand rail: Similar datasets, Used in maps, Appears in (the collections that include the dataset), tags, and a provenance timeline.

Actions live in the page header rather than on the tab: Add to map, Download (vector and table datasets) or Download COG (rasters), Connect, Publish or Unpublish, Re-upload, Create VRT (rasters) and Delete, each shown only when it applies to this dataset and your permissions.

Data tab

The data tab is a table view of the actual feature attributes: one row per feature, one column per attribute. It’s deliberately spreadsheet-like to make ad-hoc inspection fast.

Sorting: click a column header to sort ascending; click again for descending. From v1.26.0 the sort runs on the server across the whole dataset, not just the rows on the page, and paging continues in that order. Empty values sort last in both directions, and rows with equal values are ordered by gid. Number, text, date and time, boolean, UUID and interval columns can be sorted, as can inet, cidr and bytea. Columns of other types, such as JSON, arrays and geometry, have no sort control. The rows API takes the same choice as sort and order=asc|desc, and returns the sortable column names in sortable_columns; an unsortable column answers 400.
Filtering: type into the filter row beneath the column headers to filter that column; filters are applied server-side. A Columns dropdown above the grid hides and shows columns.
Pagination: the data tab paginates large datasets; the footer shows current page and total row count. Use the page-size dropdown to adjust how many rows render at once (25, 50, or 100; default 50).

Cells are read-only unless an admin has turned on dataset editing for the instance, which is off by default. With it on, and with edit rights on the dataset, click a cell to edit its value inline; the change saves straight to the feature. A table dataset without geometry offers no cell editing and no row selection. For bulk changes, export the dataset, edit externally, and re-import. See Importing data for the round-trip flow.

Deleting rows. When the table is editable and has geometry, each row has a checkbox, and the header has Select all rows on this page. Selecting rows shows a Delete N rows button in the toolbar. It opens a dialog that reads “Delete N selected rows? This cannot be undone.” Deletion is all or nothing, and it works on rows that have no geometry.

Rows whose id is past 2^53 show a disabled checkbox, because the browser cannot hold that id exactly, and select-all skips them. The selection covers one page. It clears when you change the page, the sort, a filter or the page size. If a selected row was already deleted elsewhere, nothing is deleted and GeoLens says so. If all the selected rows disappear while the dialog is open, it closes without sending anything. There is no action to delete every row that matches a filter. The same operation is available through the API; see Delete many features.

Metadata tab

The metadata tab is the editable metadata form. If you hold the editor capability and own this dataset (or you’re an admin), most fields are editable inline; everyone else sees them read-only.

Edits to the summary, source, lineage, attribution, and governance fields are staged in the page’s Save/Discard bar. Save commits the pending changes; Discard restores the saved values. These controls are separate from feature cells, which save individually.

Standard metadata fields:

Title: short, human-readable name, edited inline in the page header (required).
Summary: the longer description, edited on the overview tab (required for full quality score; see below).
Tags: the dataset’s keywords, added and removed here.
License: read-only in the UI; it can only be set through the dataset API.
Attribution, usage constraints, access constraints, and sensitivity classification: the governance block.
Lineage, source URL, source organization, update frequency, quality statement, and theme category: the ISO-style descriptive set.
Spatial extent: bounding box and CRS/SRID for the dataset.
Temporal extent: data vintage start/end for time-aware datasets.
Contacts: the people or organizations responsible for the dataset.

A Validation card counts the required and recommended fields still missing (for example “2 required”) and has a Review issues button that jumps to them.

Quality score

The quality score is a 0-100 number computed from four dimensions, each weighted as it appears on the metadata tab:

Dimension	Weight	What’s checked
Metadata completeness	30%	Ten optional fields: summary, keywords, license, source organization, data vintage start, lineage, update frequency, usage constraints, access constraints, theme category
Geometry validity	30%	Percentage of valid geometries (`ST_IsValid`)
Attribute completeness	25%	Average non-null percentage across the non-geometry columns
CRS defined	15%	A CRS/SRID is declared (yes/no)

For non-spatial table datasets the geometry and CRS dimensions don’t apply, and the score is renormalized over the other two.

The quality score card lists each dimension with its score and weight, and notes when the assessment was last checked and whether it is due again. Improve a low score by filling in missing metadata, fixing geometry errors at re-import time, or declaring a CRS during import. A score above 80 is generally fine for production sharing; below 50 is a warning sign and worth investigating.

Structure tab

The structure tab is the dataset’s attribute metadata: one row per column, showing its field name, title, description, data type, and units. Useful for confirming what a dataset’s columns mean before exporting, joining, or building against it.

If you can edit the dataset and an admin has enabled dataset editing for the instance, title, description, and units are editable inline and a Manage Columns button opens the schema editor. With dataset editing off, the tab says so and stays read-only.

CRS and bounding box are not on this tab: they’re on the metadata tab, under spatial extent. The feature count is in the stats strip above the tabs and on the sources tab.

The structure tab is shown for vector and table datasets only.

Retention

From v1.26.0, a dataset with geometry and a date or timestamp column shows a Retention card on this tab. Retention keeps only the last N days of rows, judged by the date column you choose, and deletes older ones. It is off by default.

Choose the Date column and Days to keep (a whole number from 1 to 3650), then Save. If the setting would delete rows right away, GeoLens shows how many and asks you to confirm. Turn off clears it.

An hourly background run deletes the old rows in batches, so a large backlog can take several runs. Rows with no value in the date column are kept. Deleted rows cannot be recovered. Retention needs the data in an ordinary table, and it is refused when child tables inherit from the table, a foreign key points at it, or it has a DELETE trigger or rule. While retention reads a column, that column cannot be renamed, retyped or removed; turn retention off or move it first. It works with dataset editing switched off. The retention API is described under Write features through the API.

Saving edits

Wait for a save to finish before leaving the page. If it fails, your pending changes remain available to retry, and edits stay attached to the dataset you were editing when you navigate.

Dates use YYYY-MM-DD. For timestamp columns with a time zone, the date/time form shows your browser’s local time and saves the equivalent UTC instant. Timestamps without a time zone keep the entered clock time without conversion.

Source tab

The source tab is the dataset’s provenance record, and it is present for every dataset:

Origin and storage mode: where the data came from (upload, service, PostGIS, STAC, VRT, or created in GeoLens) and how it is stored.
Source pointers: the identifying details for that origin, such as file name and fingerprint, table name, service type/layer/endpoint, or STAC collection/item/asset.
Metrics: last refreshed, last checked, feature count, plus health, freshness, and schema-drift badges.
History: earlier versions of the source binding and past refresh runs.

If you can edit the dataset and its origin supports refreshing (service, PostGIS, or STAC), a Refresh from source action sits in the panel header. Uploaded and virtual-raster datasets have no refresh action.

Before a Service replacement is published, GeoLens verifies the source feature count against the fetched count. An unavailable source count, an empty replacement, a removed column, or a retyped column blocks publication for review. A one-time acceptance can approve a blocked run only when the next fetch has the same source, attributes, and geometries as the reviewed result. Equal counts still do not prove that a mutable provider served every page from one snapshot.

After a successful refresh GeoLens keeps the data it replaced as one previous version, which you can bring back from Metadata > History; see Restore the previous version. Rasters, mosaics, tilesets, point clouds, partitioned tables and registered PostGIS datasets keep no previous version, so keep an independent backup if you need to recover their earlier contents.

For a virtual raster (VRT), the history block is replaced by the member list: each source Cloud-Optimized GeoTIFF behind the mosaic with its health, position, CRS, band count and resolution, plus a generation history of past builds. Both tables require you to be signed in, and the member list is read-only in the UI: adding a source, removing one, and regenerating the mosaic are API operations.

Access tab

The access tab holds this dataset’s URLs and its visibility setting:

Distributions: the service URLs registered for this dataset, plus an XYZ tile URL for raster and virtual-raster datasets.
API snippet: copy-paste curl, Python, and QGIS examples against the OGC API Features endpoint (vector and table datasets).
Visibility: one of private (the owner and admins), internal (any signed-in user), or public (anyone, including anonymous visitors if the instance allows that). A legacy restricted value still displays on datasets stored that way, but it can’t be selected and there is no per-user grant list behind it.
Write keys: from v1.26.0, API keys bound to this dataset alone, for a webhook or script that edits it. Editors create, list and revoke them here.

Only the owner (or an admin) can change visibility; everyone else sees the current value as a badge. Who can read or edit a dataset comes from that visibility plus your role’s capabilities, not from per-dataset grants. See User management & RBAC for the role model.

Write keys

A write key reads and writes this dataset’s features and nothing else. Tick Add features only when creating one to make it add-only: it can create features but not read, change or delete them, so a leaked key cannot expose or alter the data. Add-only keys suit webhooks and IoT feeds.

Create write key asks for a name and an Expires in choice: 30 days, 90 days or 1 year. The key value appears once. A key acts as the person who created it and stops writing if they lose edit rights on the dataset. It keeps working when Enable Dataset Editing is off for the site. The dataset’s owner and admins see every key bound to the dataset; other editors see their own. Revoke a key with the trash icon next to it. See Write features through the API for the routes and rules.

Exports start from the Download menu in the page header: pick a format and the file downloads. The same links also appear as rows in the Distributions card on the access tab.

GeoPackage (.gpkg): vector with metadata preserved; the best general-purpose format.
GeoJSON (.geojson): portable, web-friendly; good for embedding in another system.
Shapefile: legacy GIS interop, delivered as a .zip; required by some older tools.
CSV (.csv): tabular only; geometry is preserved as WKT in a single column.
GeoParquet (.parquet): columnar and lakehouse-native; selecting it also shows a copy-paste DuckDB snippet for querying the downloaded file.
FlatGeobuf (.fgb): single-file vector with a built-in spatial index; streams efficiently over HTTP.
PMTiles (.pmtiles): a single archive of vector tiles that a static file server can host without a tile server in front, as long as it honors HTTP range requests (plus CORS for cross-origin browser clients). See Exports & Integrations for how the zoom pyramid adapts to the dataset’s extent.

Non-spatial table datasets can export CSV only. Raster and virtual-raster datasets have no Download menu; a raster offers Download COG in the page header once its tiles are ready.

For live access instead of a file, use the Connect dropdown in the page header or the Distributions card on the access tab: they hand you an OGC API Features URL, a vector-tile URL, a CSV export URL, and, for rasters, COG and XYZ tile URLs you can plug into QGIS, GDAL, or a Python client.

The export endpoint also accepts bbox, where (an attribute filter) and target_crs query parameters, so a machine client can pull a subset rather than the entire dataset. See Exports & Integrations for the full reference, including machine-client examples.

Ask AI about this dataset

When AI features are enabled on the instance and your role holds the use_ai_chat capability, an Ask AI button appears on the dataset detail page. It opens a chat panel scoped to this one dataset, so you can ask questions in plain language instead of writing a filter or export first:

“How many features are there, and what’s the range of the population column?”
“Which records have no name?”
“Show the ten largest polygons by area.”

The panel is read-only: the assistant queries the dataset’s data to answer, but it never edits attributes, metadata, or access. When an answer comes from a query, a compact result table appears beneath the reply.

For datasets with geometry, a result also offers Open in builder — this creates a new map and opens the Map Builder with this dataset added and the query’s matching features carried in, so you can style and share what the answer surfaced. Non-spatial tables can still be chatted with, but have no map handoff.

Similar datasets

In the right-hand rail of the overview tab, the Similar datasets card lists up to five other catalog entries whose descriptions are semantically close to this one, each with a percentage match. It is built from the same embeddings as semantic search, so it appears only when the instance has an embedding provider configured and this dataset has been embedded; otherwise the card is absent. Used in maps sits next to it and lists the maps this dataset is a layer in.

Change history

The History block at the bottom of the metadata tab expands into two timelines. Version history is shown to anyone who can see the tab. Change history is shown only if you can edit the dataset: each entry records the action, who did it, when, and which fields changed.

Both are filtered to events on this dataset only. The instance-wide audit log lives under Admin -> Audit Log and requires admin permissions.

The Source panel lists recent refresh attempts, including failures and runs held for review. Refresh history is durable, each run has a stable link, and the API’s GET /datasets/{id}/refresh-runs endpoint is paginated.

Restore the previous version

When a refresh or file replacement succeeds on a vector or table dataset, GeoLens keeps the data it replaced. In the Version History block, the kept version has a Restore button for anyone who can edit the dataset. It asks you to type the dataset’s name, then queues the restore; the run appears in refresh history. Restoring brings that version back as the current data, and the data it replaces becomes the new previous version, so a restore can be undone until the next replacement.

Feature edits made since that version are discarded. The button is disabled while a refresh, replacement or restore is running, and while a feature is selected on the map. A restore also holds the dataset’s scheduled sync. Rasters, mosaics, tilesets, point clouds, partitioned tables and registered PostGIS datasets keep no previous version.

Re-upload and replacement review

Re-upload in the page header replaces a vector, table or raster dataset’s data from a new file (or, for vector datasets, a service layer) while keeping its ID, URL, metadata and permissions. The button appears when you can edit the dataset. VRT, 3D Tiles and point cloud datasets don’t have it; upload those again as a new dataset. The dialog’s steps are described under Re-importing to update.

Before anything is published, the dialog previews the result. For a vector dataset it shows the column differences and lists Changes that need review when the new data would:

empty a dataset that has rows;
remove columns or change their types;
change the geometry type, such as points to polygons (single and multi parts of the same type don’t count);
change the coordinate system, or drop a coordinate dimension such as Z or M.

Confirming the dialog approves the changes it listed, and the replacement publishes with them. There is no second approval step, so read the list before you confirm. Once a replacement is published, Restore the previous version brings the old data back. Raster re-uploads skip the comparison.

A replacement is held instead when the changes the worker finds are not the ones that were approved: the commit carried no acknowledgment or a stale one (an API client that skips the preview, for example), or the data turned out different from what the preview showed. A file re-upload is also held when features were edited after the file was uploaded. A held replacement shows “This replacement was held for review” in the dialog, the live data keeps serving, and the run shows as Needs review in the refresh history on the source tab, listing the reasons. Admins can also find held replacements in the Jobs list by filtering on Awaiting review. A re-upload from a service layer isn’t held over feature edits: its job fails with live_data_changed, nothing is replaced, and you start the re-upload again.

Someone who can edit the dataset decides what happens to a held run, with Review and retry. For a file re-upload it opens Publish the reviewed replacement, and Publish replacement publishes the file GeoLens kept from that upload if its changes still match the ones listed for the run. If newer data has replaced the dataset since the hold, the retry is refused; upload the file again. For a re-upload from a service layer, the retry fetches the dataset’s source again and publishes if the review reasons and the column and geometry changes match the held run. It does not check that the data is the same, so the feature count and values can differ from what the held run fetched. If the dataset’s source is no longer the one the re-upload fetched, the retry is refused with origin_changed. (Retrying a held Refresh from source run is stricter: it publishes only if the fetched data matches the run you reviewed.) When the changes no longer match, the run is held again. If you would rather not publish, start a new re-upload with corrected data.