What is the difference between ISO 19115, FGDC, and a README?

ISO 19115 is the international metadata standard (often encoded as XML via ISO 19139); FGDC CSDGM is the older US federal standard. A README is human-readable and fine for internal handoff, but formal standards make metadata machine-discoverable in catalogues and APIs.

How do I read and set a dataset's CRS and metadata with GDAL?

Use gdalinfo or ogrinfo to inspect CRS, extent, and fields. Use gdal_edit.py -a_srs EPSG:32633 to assign a CRS to a raster, or ogr2ogr -a_srs / -s_srs for vectors. GeoPackage and GeoTIFF can also store arbitrary metadata tags.

What metadata should you re-check after a format conversion?

Re-verify CRS and axis order, geometry validity, field names and types (shapefile truncates names to 10 characters), character encoding (UTF-8 vs Latin-1), and null handling. Export success does not prove the data model survived intact.

Metadata Every GIS Dataset Needs

Q: What metadata fields does every GIS dataset need?

At minimum: a declared CRS (EPSG code), spatial and temporal extent, lineage/source, the attribute schema with field definitions and units, positional accuracy or source scale, geometry type and encoding, and a usage license. These map to the core elements of ISO 19115.

Short answer

A GIS dataset is only reusable if it carries enough metadata for someone who has never seen it to place it correctly in space and time, interpret its attributes, and know what they are allowed to do with it. The non-negotiable fields are: a declared coordinate reference system (with an EPSG code), spatial and temporal extent, lineage (where it came from and how it was processed), the attribute schema with field definitions and units, positional accuracy or source scale, geometry type and encoding, and a license. These correspond to the core of the ISO 19115 standard. Everything else is helpful; these are the fields whose absence silently breaks downstream work.

The fields that matter, and why

Coordinate reference system (CRS) with EPSG code

The single most important field. A geometry without a declared CRS is a set of numbers, not a location. "Latitude/longitude" is not a CRS — WGS84 geographic is EPSG:4326, Web Mercator is EPSG:3857, and a projected national grid (e.g. UTM 33N) is EPSG:32633. Record the EPSG code explicitly. Note also the axis order trap: EPSG:4326 is formally latitude-longitude, but GeoJSON (RFC 7946) mandates longitude-latitude, and many tools disagree. Documenting the authority code removes the ambiguity.

Spatial and temporal extent

The bounding box (in the dataset's CRS and ideally also in WGS84) lets catalogues and users filter by area without opening the file. The temporal extent — the date or date range the data represents, not the file's modification date — is just as important. A land-cover layer "from 2019" and one "current as of last week" support entirely different decisions.

Lineage / provenance

Where did it come from, and what happened to it? Original source and publisher, acquisition or survey date, processing steps (reprojected, generalised, clipped, snapped, manually edited), and the tools and versions used. This is what lets a later analyst reproduce or trust the result. ISO 19115 models this as LI_Lineage with process steps and source descriptions.

Attribute schema

Field names alone are not metadata. For each attribute record the data type, units, meaning, allowed values or domain, and how null/no-data is represented (empty string vs NULL vs a sentinel like -9999 matters enormously in analysis). A field called THK_M is opaque; "THK_M: bed thickness in metres, double, NULL = not measured" is usable.

Positional accuracy and source scale

A vector digitised from a 1:250,000 map is not interchangeable with one captured by RTK GPS, even though both store coordinates to many decimal places. Record source scale and/or RMSE positional accuracy so users do not over-trust apparent precision.

Geometry type, encoding, and structure

Geometry type (point, line, polygon, multipart, 2D vs 3D/Z), character encoding (UTF-8 preferred; legacy shapefiles often ship CP1252/Latin-1), and — for multi-layer containers — which layers travel together.

License and usage rights

What can the recipient do: use internally, redistribute, publish derivatives, sell? Name the license (e.g. CC-BY-4.0, OGL, proprietary) and attribution requirement. Without it the dataset is legally unsafe to share.

Standards: ISO 19115, FGDC, and the humble README

ISO 19115 / 19139 — the international geographic metadata standard; 19139 is its XML encoding. This is what spatial catalogues (GeoNetwork, CKAN, CSW endpoints) consume.
FGDC CSDGM — the older US federal Content Standard for Digital Geospatial Metadata, still common in USGS/agency data.
README / metadata sidecar — a plain-text or Markdown file beside the data. Perfectly adequate for internal handoff and far better than nothing; it just is not machine-discoverable.

For most production teams the pragmatic answer is: embed CRS and basic tags inside the file format, and ship a structured README (or ISO XML if you publish to a catalogue) alongside it.

Storing metadata inside the file

Metadata is most durable when it cannot be separated from the data:

GeoPackage (OGC, SQLite-backed) has built-in gpkg_metadata and gpkg_metadata_reference tables that can hold ISO 19115 XML, plus you can add arbitrary tables for a data dictionary.
GeoTIFF stores CRS in GeoKeys and supports arbitrary TIFFTAG/GDAL metadata domains.
Shapefile is the weakest: CRS lives in a sidecar .prj (easily lost), field names truncate to 10 characters, and the .dbf encoding is frequently undeclared. Treat the .prj and an accompanying .xml/README as mandatory companions.

Inspecting and setting metadata with GDAL

Read what is actually there before trusting any label:

gdalinfo dem.tif            # CRS, extent, pixel size, NoData, metadata tags
ogrinfo -so units.gpkg layer1   # geometry type, feature count, field schema, CRS

Assign a CRS to a raster that is missing one (without warping pixels):

gdal_edit.py -a_srs EPSG:32633 dem.tif

Reproject and re-declare for vectors, fixing axis/encoding at the same time:

ogr2ogr -t_srs EPSG:4326 -lco ENCODING=UTF-8 out.gpkg in.shp

Note -a_srs/gdal_edit only labels the data; -t_srs actually transforms coordinates. Confusing the two is a classic way to put data in the wrong place.

Worked example: a deliverable that survives handoff

A team ships bedrock_units.gpkg to a client. The package contains:

The feature layer, declared as EPSG:32633, geometry MultiPolygon, UTF-8.
A data_dictionary table: every field with type, units, domain, and null convention.
ISO 19115 XML in gpkg_metadata: title, abstract, lineage (source 1:50,000 survey, digitised 2024, generalised to 5 m tolerance), temporal extent, positional accuracy (±25 m), and CC-BY-4.0 license.
A short README repeating the essentials in human-readable form.

Six months later anyone can open it, know the CRS, read what every column means, see how it was made, and know they may publish it with attribution. That is the standard worth meeting.

Common pitfalls and why they happen

Shipping only .shp — a shapefile is at least .shp, .shx, .dbf, and .prj; dropping the .prj loses the CRS, dropping the .dbf loses all attributes. Zip the whole set or use GeoPackage.
Field-name truncation — groundwater_depth becomes groundwate in a shapefile, silently. Conversion to/from shapefile corrupts long names; check after every round-trip.
Encoding drift — accented characters turn to mojibake when an undeclared Latin-1 .dbf is read as UTF-8.
Confusing file date with data date — a 2024 modification timestamp on a 2008 survey misleads every downstream decision.
No-data ambiguity — treating 0 or -9999 as a real value in statistics because the no-data convention was never recorded.

QA and validation checklist

gdalinfo/ogrinfo confirm CRS, extent, geometry type, and field schema match the documentation.
CRS stored as an EPSG code, not free text; axis-order assumption stated.
Every attribute has a definition, type, units, and null convention.
Lineage records source, date, processing steps, and tool versions.
Temporal extent reflects the data's validity, not file mtime.
License and attribution stated.
After any conversion, field names, encoding, and geometry validity re-verified.

Bathyl perspective

We consider a dataset finished only when a stranger could pick it up and use it correctly without emailing us. Metadata is not paperwork added at the end; it is part of the data model, captured as the data is built and embedded in the file wherever the format allows. The cheapest insurance against a silent CRS, schema, or licensing failure is the metadata you wrote when you still remembered the answers.