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>#data
https://your-instance/datasets/<id>#metadata
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, Sources, 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: Related datasets, Used in maps, collection badges, tags, and a provenance timeline.

Actions live in the page header rather than on the tab: Add to map, Connect, Publish/Unpublish, Re-import, Create VRT, Download COG, 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 any column header to sort ascending; click again for descending.
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. For bulk changes, export the dataset, edit externally, and re-import. See Importing data for the round-trip flow.

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.

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. 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.

Editing improvements (unreleased)

The development branch includes fixes for saving and discarding metadata drafts and for keeping edits attached to the correct dataset when you navigate. Wait for a save to finish before leaving; if it fails, your pending changes remain available to retry.

Date and timestamp editing is also being improved. 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.

Sources tab

The sources 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) 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.

GeoLens does not retain a restorable prior table after a successful refresh. Keep an independent backup if you need to recover the previous 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).
Export: the format picker (vector and table datasets; raster and virtual-raster datasets have no export card).
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.

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.

Exports are triggered from the Export card on the access tab: pick a format, then download.

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 export card; 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.

In the right-hand rail of the overview tab, the Related datasets card surfaces other catalog entries that are conceptually similar, such as datasets sharing tags or with overlapping spatial extent. Used in maps sits next to it and lists the maps this dataset is a layer in.

The matching is heuristic: useful for browsing, not authoritative. To find related datasets on your own terms, run an explicit search with the same tags or in the same bbox; see Search & Discovery.

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. Refresh history is durable and the API’s GET /datasets/{id}/refresh-runs endpoint is paginated. Starting with the next release, the panel adds blocked runs, page controls, and stable links to individual runs.