What is a GIS knowledge base and how is it different from a folder of files?

A GIS knowledge base is an organized, searchable collection of spatial datasets with consistent metadata, naming, and lineage, so a layer can be found and trusted by someone who did not create it. A folder of files has data but no discoverability, provenance, or reuse guarantees.

How should I name and organize GIS layers so they stay findable?

Use a consistent, lowercase, machine-readable convention encoding theme, area, and CRS or year, such as geol_contacts_aoi_25831. Avoid spaces, versions in the name like final_v2, and ambiguous abbreviations.

What metadata standard should a GIS catalog use?

ISO 19115 for dataset-level metadata and OGC Catalogue Service or STAC for cataloging are the established options. Even a lightweight catalog should record CRS, extent, lineage, update date, and licensing per dataset.

Should a GIS knowledge base be file-based or database-backed?

Small or low-change collections work well as versioned GeoPackages in a structured tree. Multi-user, frequently updated, or query-heavy collections belong in PostGIS, which adds concurrency, indexing, and SQL-based discovery.

Building a GIS Knowledge Base That Scales

The short version

A GIS knowledge base is the difference between having spatial data and being able to find and trust it. It is an organized, searchable collection where every dataset carries consistent metadata (CRS, extent, lineage, update date, licence), follows a naming convention, and lives in a backbone — versioned GeoPackages for small collections, PostGIS for anything multi-user or frequently updated. The goal is concrete: a colleague who has never seen your data can locate the right layer, know where it came from, and use it without asking you.

Most teams accumulate data faster than they organize it, so they end up with twelve folders, three "final" versions of the same shapefile, and institutional knowledge that walks out the door when someone leaves. A knowledge base fixes that by making discovery and provenance properties of the system, not of a person's memory.

Three layers of a knowledge base

A working GIS knowledge base has three concerns, and conflating them is the usual reason these efforts stall:

Storage — where the bytes live and how they are versioned.
Metadata — the structured description that makes each dataset discoverable and trustworthy.
Catalog/search — the index that lets someone find a dataset by area, theme, date, or keyword.

You can start lightweight on all three and harden each independently as the collection grows.

Naming conventions: the cheapest big win

Before tooling, fix names. A consistent, machine-readable convention removes more friction than any catalog software, because it makes layers self-describing and sortable. A workable pattern encodes theme, area, and CRS or year:

geol_contacts_aoi_25831
hydro_streams_basin12_25831
dem_aoi_10m_25831
landuse_municipality_2025_3035

Rules that pay off: lowercase only; underscores, never spaces or special characters (which break shapefile fields, URLs, and SQL); no final, v2, or latest baked into names (versioning belongs to the storage layer); and stable abbreviations defined in a short glossary. Consistent names also let you query the catalog by prefix and keep related layers adjacent when sorted.

Storage backbone: GeoPackage or PostGIS

Pick the backbone by how the data changes and who touches it.

GeoPackage suits small or low-change collections. One .gpkg holds many vector and raster layers plus their styles, it is a single OGC-standard file, and it versions cleanly when paired with a structured tree and dated snapshots. Build and extend with GDAL:

ogr2ogr -f GPKG kb.gpkg geol_contacts.shp -nln geol_contacts_aoi_25831
ogr2ogr -f GPKG -update -append kb.gpkg hydro_streams.shp -nln hydro_streams_basin12_25831

PostGIS is the right backbone once you have concurrent editors, frequent updates, large volumes, or query-driven discovery. It adds spatial indexing (GiST), SQL search, row-level history, and access control. Load and index:

ogr2ogr -f PostgreSQL "PG:dbname=kb" geol_contacts.shp -nln geol_contacts_aoi_25831 -lco GEOMETRY_NAME=geom

CREATE INDEX ON geol_contacts_aoi_25831 USING GIST (geom);

In PostGIS, organize by schema (geology, hydrology, terrain) rather than dumping every table in public, which gives you a coarse but effective top-level taxonomy.

Metadata: what to record per dataset

Discoverability and trust both come from metadata. ISO 19115 is the established dataset-level standard; you do not need every element, but each dataset should carry at least:

Title and abstract — what it is, in plain language.
CRS and units — the authority code, e.g. EPSG:25831.
Spatial extent — bounding box, for "find data over my area" queries.
Temporal extent and update date — currency.
Lineage — source datasets and the processing applied, so results are reproducible.
Licence and provenance — redistribution rights and originator.
Keywords — controlled vocabulary terms for search.

In PostGIS you can hold this in a metadata table keyed to each layer; in GeoPackage, use the gpkg_metadata and gpkg_metadata_reference tables. The principle is that metadata lives with the data, not in a spreadsheet that drifts out of sync.

Catalog and search

For browsing and discovery, the spatial-data world offers established options rather than bespoke search:

STAC (SpatioTemporal Asset Catalog) is well suited to raster and Earth-observation collections, indexing assets by space, time, and properties through a simple JSON model and API.
OGC Catalogue Service (CSW), often via GeoNetwork, is the heavier ISO-19115-based option for institutional metadata catalogs.
A PostGIS-backed catalog table is enough for many internal teams: a single table of dataset records with extent, theme, and keywords, queried with SQL or exposed through OGC API - Features.

A useful discovery query — "what layers cover my AOI?" — falls straight out of recorded extents:

SELECT layer_name, theme, updated
FROM   catalog
WHERE  ST_Intersects(extent, ST_MakeEnvelope(:xmin,:ymin,:xmax,:ymax,25831));

Worked example: consolidating a consultancy's archive

A consultancy had eight years of projects across a shared drive: shapefiles named Contacts_FINAL, contacts_final2, Contacts_use_this_one. We did not migrate everything blindly. We defined the naming convention and a minimal metadata schema, loaded the actively reused layers into a PostGIS database under theme schemas, populated the catalog table with extent and lineage, and left the archive in place as cold storage with a README pointing to the live database. Within a month, "do we have geology over this licence area?" went from a half-day of folder spelunking to a single spatial query, and duplicate "final" files stopped multiplying because there was now one authoritative place to look.

QA for the knowledge base itself

Every dataset has a CRS, extent, update date, and lineage entry — enforce with a query that lists records missing any of these.
No two layers share a name; the convention is applied without exceptions.
Extents in the catalog match the actual data extent (recompute and compare).
Licensing is recorded for anything that might be redistributed.
A new team member can find a known dataset using only the catalog, with no tribal knowledge — test this literally.

Bathyl perspective

We treat a knowledge base as infrastructure that outlives any single project. Bathyl builds these around consistent naming, ISO-aligned metadata, and a PostGIS or GeoPackage backbone chosen to match the team's pace of change, so a dataset's value compounds with every project instead of being rediscovered each time. The test we hold ourselves to: someone who has never met the original analyst can find the layer, trust its lineage, and use it correctly.

Building a GIS Knowledge Base