Skip to content
getgeolens.com

Collections

Collections are named, ordered groups of datasets. Unlike a saved search (which is a query that re-runs against the catalog), a collection has explicit membership — you decide what’s in it, the order, and who can see it. Collections show up in their own list in the sidebar, render a custom landing page with cards for each member dataset, and can be shared like any other catalog object.

A collection is a small piece of metadata pointing at a list of dataset IDs. There’s no copy of the data — adding a dataset to a collection doesn’t duplicate it; removing a dataset from a collection doesn’t delete the dataset. The collection is purely a curation surface.

Typical use cases:

  • Project deliverables — group all the datasets you produced for a specific project so a stakeholder can browse them in one place.
  • Thematic catalogs — “Population & demographics”, “Hydrology”, “Land cover 2024” — small curated sub-catalogs organized by theme.
  • Quarterly reviews — collect the datasets in scope for a specific review and share the URL with reviewers.
  • Onboarding — give a new team member a “Start here” collection of the most-used datasets.

A dataset can belong to any number of collections; collections can overlap. Collections themselves can’t be nested (no collections-of- collections), but tags work as a coarser grouping above the collection level if you need a hierarchy.

The Collections entry in the sidebar opens the collection list — every collection visible to you, sorted by recently-updated.

Each collection card shows:

  • Collection name and description
  • Dataset count (e.g., “12 datasets”)
  • Visibility badge (public, private, restricted)
  • Owner and last-updated timestamp

Click a card to open the collection’s detail page.

The collection detail page lists every member dataset using the same card layout as Search & Discovery, with one key difference: collection-scoped search. The search bar at the top of the collection page runs against the collection’s members only, not the full catalog.

This makes collections useful as small catalogs in their own right — a team member exploring “Hydrology” can keyword-search and filter just within that scope.

Creating a collection requires the editor role (you can read collections without being an editor; you just can’t make new ones). If you don’t see a New collection button on the Collections page, you don’t have the editor role on this instance — see User management & RBAC for how roles are assigned.

To create a collection:

  1. Open Collections in the sidebar.
  2. Click New collection.
  3. Fill in the create dialog:
    • Name (required) — short, human-readable name.
    • Description — markdown-supported longer description.
    • Visibilitypublic, private, or restricted (see below).
    • Initial members (optional) — pick datasets from the catalog picker. You can also add members after creation.
  4. Click Create. The collection is saved and you land on its detail page.

Collection visibility works the same way as dataset visibility:

  • Public — anyone (including unauthenticated visitors, if your instance allows that) can see the collection and any of its public member datasets. Private member datasets are hidden from public viewers.
  • Private — only you and admins can see the collection.
  • Restricted — explicit access list of users or groups, with read-only or read-write permission per user.

A collection’s visibility is independent from its members’ visibility. Making a collection public doesn’t make its private members public — non-permitted viewers see the collection, but private datasets in it are filtered from view.

Once a collection exists, the detail page has an Edit menu (visible to editors) with several options:

  • Add datasets — opens the same catalog picker as the create dialog. Select one or many datasets and click Add to push them into the collection.
  • Remove datasets — multi-select datasets in the collection and click Remove to take them out.
  • Reorder — drag handles on each dataset card let you reorder; the collection landing renders in the order you set.
  • Edit metadata — update name, description, visibility.
  • Delete — remove the collection. Members are not affected.

You can also add a dataset to a collection from the dataset itself — the Add to collection action on any dataset detail page opens a picker showing collections you can edit; click any to add the dataset there.

For larger reorganizations, the catalog picker supports filter-based bulk add: search by tag, geometry type, or bbox in the picker, then select all matches and add them in one operation. Useful when you’ve curated a saved search and now want to materialize it as a collection.

It’s worth being explicit about the distinction, because the two features look similar at first glance:

  • A saved search is a stored query. Its membership changes as the catalog changes — new datasets matching the query auto-appear, deleted datasets disappear. Use it when the criteria are what matter (“every hydrology dataset in California”).
  • A collection is an explicit list of dataset IDs. Membership only changes when you add or remove a dataset. Use it when the specific datasets are what matter (“the seven datasets we used for the Q3 review”).

If you need both behaviors — a query result that’s also a stable shareable list — start with a saved search, then materialize the result into a collection. The collection captures a snapshot; the saved search keeps tracking the live query.

See Search & Discovery → Saved searches for the saved-search side.

Collection URLs are stable: https://your-instance/collections/<id>. Once you’ve published a collection (visibility set to public or restricted with the right people on the access list), anyone with the URL who has permission can open it. The collection page renders the same for editors and viewers — viewers just don’t see the Edit menu.

If you need a chrome-free version of the collection (for embedding in a project portal, for example), append ?embed=1 to the URL — same convention as map embeds. The embedded view drops the GeoLens header and sidebar but keeps the collection-scoped search bar so visitors can still filter within the collection.

Each collection exposes an RSS feed at https://your-instance/collections/<id>/feed.xml listing every dataset in member order with a link back to the dataset’s detail page. RSS is a useful integration surface for tools that want to watch a collection without running a custom integration — feed readers, build pipelines, status dashboards.

  • Naming — short collection names render better in the sidebar. Aim for 2-4 words.
  • Description as a landing page — the description supports markdown, including images, links, and headings. Treat it as a brief landing page for the collection, not just a summary.
  • Order with intent — the order datasets render in is the order visitors encounter them. Lead with the most-important or most-recent datasets.
  • Visibility migrations — moving from private to restricted is cheap (just add users). Moving the other direction is also cheap but silently revokes access; double-check who’s currently using the collection before tightening it.
  • Use thumbnails for visual recognition. A collection landing page thumbnails each member dataset using the dataset’s overview map preview. For collections shared with non-technical stakeholders, this visual indexing is far more useful than dataset titles alone.