GIS glossary and learning hub

Also called: geographic information system, geographic information science

A geographic information system is software for capturing, storing, analysing, and presenting data tied to locations on Earth. It combines geometry (where things are) with attributes (what they are) so questions such as which parcels fall inside a flood zone can be answered systematically instead of by eye. Modern GIS spans desktop applications like QGIS, spatial databases, web services, and browser-based editors. The same abbreviation also names geographic information science, the research field studying the concepts behind the software.

In GeoCanvas: GeoCanvas is a browser-based GIS: layers are edited, styled, and analysed on an interactive deck.gl map, with collaboration built in.

Related: Spatial data, Layer, Feature, Attribute

Also called: geospatial data

Spatial data, also called geospatial data, records where something is on or near the surface of the Earth, usually as coordinates plus descriptive attributes. It comes in two big families: vector data, which draws the world as points, lines, and polygons, and raster data, which divides it into a grid of cells such as imagery or elevation. Because coordinates only mean something inside a coordinate reference system, every spatial dataset carries a CRS, either explicitly or by assumption. Losing track of that reference is one of the most common causes of misaligned data.

Related: Feature, Geometry, Raster, Coordinate reference system (CRS)

Also called: map feature

A feature is a single thing represented in a spatial dataset: one well, one road segment, one land parcel. In the simple features model used across modern GIS, and in GeoJSON, a feature bundles one geometry with a set of properties that describe it. Collections of similar features, such as all the roads in a region, form layers that can be styled and analysed together. Thinking in features keeps the distinction clear between the real-world object, its shape, and the numbers recorded about it.

In GeoCanvas: Every GeoCanvas vector layer is a collection of features with properties.

Related: Geometry, Attribute, Layer

Also called: shape

The geometry of a feature is its shape and position, expressed as coordinates arranged into a type such as Point, LineString, or Polygon. The OGC Simple Features standard defines the common geometry types, their multi-part variants, and the operations that can be applied to them, from distance calculations to overlays. Coordinates in a geometry are interpreted through a coordinate reference system, so the same numbers can place a feature in very different locations depending on the CRS in use.

Related: Feature, Point, Line, Polygon, Coordinate reference system (CRS)

Also called: field, property

Attributes are the non-spatial facts recorded about a feature: a road name, a parcel area, a sensor reading. They are stored as fields in a table aligned with the geometries, one row per feature. Attributes drive most practical work in a GIS: they decide how features are filtered, labelled, classified, and symbolised, and they carry the values that spatial analysis aggregates. Clean, consistently typed attributes matter as much as accurate geometry, because a perfect shape with unreliable attributes still produces unreliable answers.

Related: Feature, Layer, Classification

Also called: map layer, data layer

A layer is a named collection of spatial data rendered as one unit on a map, with its own style, visibility, and ordering. Maps are built by stacking layers: a basemap at the bottom, operational data like roads or sensors on top. Separating data into layers lets each dataset be managed, styled, and shared independently. In analytical tools the same concept appears as a table or a dataset, but the map layer adds the visual encoding: which colours, symbols, and scales apply.

In GeoCanvas: GeoCanvas layer configs are immutable: updates spread a new config, which keeps rendering and collaboration consistent.

Related: Feature, Map style, Basemap

Also called: map extent

An extent is the rectangular region of interest of a dataset or map view, expressed in a coordinate reference system as minimum and maximum x and y values. Extents appear everywhere: the current map window, the coverage of a layer, the area requested from a service, the region used to clip an export. Because an extent is only meaningful with its CRS, comparing extents across projections requires reprojecting one of them first. Many spatial queries start by testing extents because rectangles are cheap to compare before geometry is touched.

Related: Bounding box, Coordinate reference system (CRS)

Also called: scale

Map scale is the ratio between a distance on the map and the same distance on the ground, written as a representative fraction such as 1:24,000. A large-scale map shows a small area in fine detail; a small-scale map shows a large area with generalised detail. Interactive slippy maps replace a single scale with discrete zoom levels, each roughly doubling the resolution. Scale still governs design decisions: which features appear, how labels size, and how much detail a dataset should carry at each zoom.

Related: Slippy map, Spatial resolution, Map tile

Also called: ground sample distance, GSD

Spatial resolution is the size of the ground area represented by a single pixel or cell, often expressed as ground sample distance for imagery. A 30 m Landsat pixel averages everything inside a 30 m square into one value, while a 0.5 m aerial image resolves individual cars. Finer resolution reveals more detail but multiplies data volume and noise, and it often trades against temporal or spectral resolution in sensor design. Choosing a resolution means deciding what size of feature must remain visible for the analysis at hand.

Related: Raster, Pixel, Resampling

Also called: spatial predicate, topological relationship

A spatial relationship describes how two geometries sit relative to each other: does one contain the other, do they touch, do they cross? The Dimensionally Extended 9-Intersection Model formalises these relationships by comparing the interiors, boundaries, and exteriors of both geometries. Databases expose them as predicates such as intersects, contains, and within, which power spatial joins and overlay analysis. Choosing the right predicate matters: a point on a polygon boundary touches it but is not strictly within it.

Related: Topology, Spatial join, Intersection

Also called: coordinate pair

A coordinate is an ordered set of numbers that fixes a position relative to a coordinate reference system: a longitude and latitude, an easting and northing, often with a height. On its own the pair of numbers is ambiguous. The values (45, -75) mean different places depending on the CRS, the axis order, and the units. Every spatial pipeline therefore needs to carry the CRS alongside its coordinates and to declare the order it expects. Mixing up these assumptions is a classic source of data landing in the ocean.

Related: Coordinate reference system (CRS), Axis order, EPSG code

Also called: spatial reference system, SRS

A coordinate reference system defines how coordinate numbers map to real positions on Earth. It combines a datum, which anchors the model to the planet, with a coordinate system; projected CRSs add a map projection that flattens the curved surface into plane coordinates. Geographic CRSs work in angular degrees, projected CRSs in linear units like metres. Authorities such as EPSG assign numeric codes so software can exchange CRS definitions unambiguously. Distances, areas, and buffers are only meaningful once the CRS is known, which is why every dataset should declare one and every join should check that both sides match.

In GeoCanvas: GeoCanvas accepts data in any declared CRS and renders it in Web Mercator; analytics keep source coordinates intact.

Related: EPSG code, Datum, Map projection, Reprojection

Also called: EPSG, SRID

An EPSG code is a numeric identifier from the EPSG geodetic registry, maintained by the International Association of Oil and Gas Producers, that names a coordinate reference system, datum, or transformation. EPSG:4326 identifies WGS 84 latitude and longitude; EPSG:3857 identifies Web Mercator. Codes let software pass a short number instead of a full CRS definition. The number is only a key into the registry: axis order and units still come from the registered definition, which is why two tools can honestly disagree about the same code.

Related: Coordinate reference system (CRS), WGS 84, Web Mercator

Also called: geodetic datum

A datum is the reference frame that anchors coordinates to the Earth: it fixes an ellipsoid and its position and orientation relative to the planet. Coordinates in different datums disagree, sometimes by hundreds of metres, even for the same physical point. NAD 83 and WGS 84 are common North American and global examples. Converting between datums needs a datum transformation, not just a projection change, and tectonic motion means high-precision work must also track the reference epoch when the coordinates were valid.

Related: Ellipsoid, Geoid, Coordinate reference system (CRS)

Also called: spheroid, reference ellipsoid

An ellipsoid is the smooth mathematical surface used to approximate the shape of the Earth in geodesy: a sphere slightly flattened at the poles, defined by its semi-major axis and flattening. Datums build on ellipsoids; the WGS 84 ellipsoid underlies GPS coordinates worldwide. Heights measured by GPS reference the ellipsoid, which is not the same as height above sea level. Converting between the two needs a geoid model, and the difference can reach tens of metres in some regions.

Related: Datum, Geoid, WGS 84

The geoid is a model of mean sea level extended continuously across the globe, defined as the surface where the gravity potential is constant. Everyday phrases like metres above sea level refer to heights above the geoid, not above the ellipsoid that GPS uses. The separation between the two surfaces, called geoid undulation, varies with local gravity anomalies. Elevation datasets and surveying workflows must state which vertical reference they use, because mixing ellipsoid and geoid heights introduces systematic errors.

Related: Ellipsoid, Datum, Digital elevation model (DEM)

Also called: geographic coordinate system, latlon, lat-long

A geographic coordinate reference system describes positions directly on the ellipsoid using angular units: latitude and longitude in degrees. WGS 84, registered as EPSG:4326, is the universal example and the default for data exchange formats like GeoJSON. Because a degree of longitude shrinks toward the poles, distances and areas computed in degrees are distorted. Measure, buffer, or grid data in a projected CRS instead, and keep geographic coordinates for storage and interchange.

Related: Projected CRS, WGS 84, Axis order

Also called: projected coordinate system

A projected coordinate reference system flattens the curved Earth onto a plane using a map projection, giving coordinates in linear units such as metres or feet. Plane coordinates make distance, area, and grid arithmetic straightforward, which is why analysis and engineering work happen in projected systems. Every projection distorts something, so the choice depends on region and purpose: UTM zones for local accuracy, national grids for official mapping, Web Mercator for global web display. A projected CRS always references a geographic CRS and datum underneath.

Related: Map projection, Geographic CRS, UTM, Web Mercator

Also called: projection

A map projection is a systematic mathematical conversion of positions on the curved Earth to a flat map. No projection preserves everything: each one keeps some properties true, such as area, local shape, distance along certain lines, or direction, at the cost of distorting the rest. Conformal projections keep angles and local shapes, equal-area projections keep area, and compromise projections balance errors for display. Choosing a projection is an analytical and editorial decision, because the same data can look and measure very differently under different choices.

Related: Projected CRS, Datum, Reprojection

Also called: WGS84, World Geodetic System 1984

The World Geodetic System 1984 is the global datum and ellipsoid maintained for GPS. Its latitude and longitude CRS, registered as EPSG:4326, is the default interchange frame for web mapping and formats such as GeoJSON. WGS 84 is periodically refined to track plate tectonics, so centimetre-level work must record the realisation and epoch; for typical mapping at city scale and beyond, the differences between realisations are negligible. Most practical reprojection starts or ends in WGS 84.

Related: EPSG code, Geographic CRS, Web Mercator

Also called: EPSG:3857, Pseudo-Mercator, Spherical Mercator

Web Mercator is the spherical variant of the Mercator projection, registered as EPSG:3857, used by nearly every slippy map on the web. Treating the Earth as a sphere keeps tile maths simple and produces a square world map that divides cleanly into zoom levels. The cost is severe area distortion toward the poles and latitude-dependent scale, which makes it unsuitable for measuring distance or area. Treat it as a display standard: store and analyse in an appropriate CRS, then render in Web Mercator.

In GeoCanvas: GeoCanvas renders the interactive map in Web Mercator, like other slippy maps.

Related: Map projection, Slippy map, XYZ tiles

Also called: Universal Transverse Mercator

The Universal Transverse Mercator system divides the world into 60 zones of 6 degrees of longitude, each with its own transverse Mercator projection and coordinates in metres. Inside a zone, distortion stays small enough for field work, engineering, and topographic mapping, which made UTM a global standard for local coordinates. UTM is not one CRS but a family: every dataset must name its zone and hemisphere, and areas spanning zone boundaries need a different choice. EPSG codes exist for each zone.

Related: Projected CRS, Map projection, Datum

Also called: coordinate transformation, projection transformation

Reprojection converts coordinates from one coordinate reference system into another. The operation chains a datum transformation with a projection change, and it is lossy when datums differ or when grid-based shift files are required for accuracy. Libraries such as PROJ perform the maths; the analyst must still choose the right target CRS for the purpose and region. Silent reprojection assumptions cause subtle misalignment, so pipelines should declare CRSs explicitly at every step and verify that joined datasets share one.

In GeoCanvas: GeoCanvas normalises incoming data with PROJ-backed transforms so layers align on the shared map.

Related: Coordinate reference system (CRS), PROJ, Datum

Also called: coordinate order, latitude longitude order

Axis order states which coordinate comes first in a pair. EPSG formally defines EPSG:4326 as latitude then longitude, while GeoJSON and most web software write longitude then latitude. Neither is wrong, but mixing the conventions silently swaps positions, often across hemispheres. Problems surface when integrating GML, WFS, databases, and APIs that follow different rules. When data lands in an impossible place, axis order is one of the first suspects to check.

Related: EPSG code, Coordinate, GeoJSON

A point is a zero-dimensional geometry: a single coordinate marking a location with no length or area. Wells, addresses, sensor stations, and points of interest are typical point features. Points are the simplest vector type, yet they anchor much of GIS practice: geocoding produces them, clustering summarises them, and spatial joins attach the attributes of the areas they fall inside. The multi-part variant, MultiPoint, groups several coordinates into one feature with shared attributes.

Related: Line, Polygon, Multipart geometry

Also called: linestring, polyline

A line, formally a LineString, is an ordered sequence of connected vertices forming a path. Roads, rivers, pipelines, and GPS tracks are modelled as lines. Length calculations depend on the coordinate reference system, so measure in a projected CRS rather than in degrees. When lines connect into a network with topology, they support routing and flow analysis rather than simple display. MultiLineString is the multi-part variant, used for features like a river with braided channels.

Related: Point, Polygon, Routing

A polygon is a closed ring of vertices enclosing an area, optionally with interior rings that cut holes. Parcels, lakes, and administrative boundaries are polygon features. The model carries rules worth knowing: rings must close, exteriors and holes have conventional winding orders, and self-intersecting shapes are invalid in most engines. Area and perimeter are only meaningful in a projected CRS. MultiPolygon groups disjoint areas, such as the islands of one state, into a single feature.

Related: Geometry validity, Multipart geometry, Buffer

Also called: multi geometry, MultiPoint, MultiLineString, MultiPolygon

A multipart geometry bundles several parts of the same type into one feature: a MultiPolygon for an archipelago, a MultiLineString for a branching road. The parts share one set of attributes, which keeps related pieces together in the table. Multipart structures surprise new users when area or length aggregates across parts, or when an edit expects one shape per row. Most tools can explode multiparts into single-part features, or dissolve singles back into multiparts, as the analysis requires.

Related: Polygon, Feature, Dissolve

Topology is the set of spatial rules between geometries that survives continuous deformation: adjacency, connectivity, and containment. A topological data model stores shared boundaries once and knows which polygons neighbour each other or which lines meet at a node, preventing gaps and overlaps along shared edges. GRASS GIS famously enforces topology on import. Routing and network analysis depend on edge topology, and topological predicates such as touches or crosses express these relationships in queries.

Related: Spatial relationship, Geometry validity, Routing

Also called: valid geometry, simple feature validity

A valid geometry obeys the rules of its type: polygon rings are closed and do not self-intersect, holes sit inside their shell, lines contain no degenerate spikes. Invalid input creeps in through digitising errors, format conversions, and clipped data, and it breaks predicates, overlays, and renderers in unpredictable ways. Functions such as ST_IsValid detect problems and ST_MakeValid repairs them. Validating on import, rather than at analysis time, turns mysterious mid-pipeline failures into clear, early diagnostics.

Related: Topology, Intersection, Polygon

The centroid is the geometric centre of a geometry: the average of its vertices weighted appropriately, and for a polygon the balance point of its area. Centroids convert areas into representative points for labelling, symbol placement, and quick distance estimates. One caveat matters in practice: the centroid of a concave or crescent-shaped polygon can fall outside the shape, so labelling and join workflows often prefer a point guaranteed to lie on the surface instead.

Related: Polygon, Spatial join, Point

Also called: bbox, envelope, minimum bounding rectangle

A bounding box is the smallest axis-aligned rectangle that contains a geometry, stored as four numbers: minimum and maximum x and y. Rectangles are cheap to store and compare, so bounding boxes act as a first filter in spatial indexes, tile requests, and API queries such as the bbox parameter in OGC API - Features. A bbox overlap says nothing certain about the geometry inside; it only proves the shapes are worth a more expensive exact test.

Related: Extent, Spatial index, R-tree

A spatial index organises geometries by location so that queries test a handful of likely candidates instead of scanning every row. Indexes typically store bounding boxes in a structure such as an R-tree or a GiST tree: a query rectangle first finds overlapping boxes, then runs exact geometry tests only on that shortlist. Without an index, joins and lookups degrade to full-table comparisons and quickly become unusable as data grows. Creating the index is a one-time cost that pays back on every query.

Related: R-tree, Bounding box, Spatial join

Also called: R tree

An R-tree is a balanced tree index that groups nearby objects inside nested rectangles. Each node holds the bounding boxes of its children, so a search descends only the branches whose boxes intersect the query area. The design generalises the B-tree idea from one dimension to many and remains the workhorse of spatial indexing: SQLite and SpatiaLite expose R-trees directly, FlatGeobuf embeds a packed R-tree for range reads, and variants sit inside PostGIS GiST indexes.

Related: Spatial index, FlatGeobuf, Bounding box

Also called: grid, gridded data

A raster divides space into a regular grid of cells, each holding one or more values. Satellite imagery, elevation models, weather grids, and land cover maps are rasters. The grid is anchored to the world by its extent, cell size, and coordinate reference system. Where vector data excels at discrete objects, rasters excel at continuous phenomena, and raster algebra applies maths cell by cell: subtracting two dates of imagery, thresholding elevation, or combining bands into an index.

In GeoCanvas: GeoCanvas serves raster layers from a cloud-native Zarr store.

Related: Pixel, Band, Spatial resolution

Also called: cell

A pixel is a single cell of a raster grid. Its value summarises whatever the cell footprint covers: averaged reflected light in imagery, mean height in an elevation model, a class code in land cover. Once the raster is georeferenced, pixel size equals the ground resolution, which sets the smallest feature the data can honestly show. Resampling to smaller pixels never adds real detail; it only reshapes the same information into more cells.

Related: Raster, Spatial resolution, Bit depth

Also called: raster band, channel

A band is one layer of values inside a raster. A photograph has red, green, and blue bands; a satellite scene adds near-infrared and beyond; an elevation model usually has a single band of heights. Multiband rasters stack these grids, and band arithmetic combines them: vegetation indices like NDVI are ratios of two bands. Each band can carry its own data type and NoData value, so tools track band-level metadata alongside the shared grid definition.

In GeoCanvas: Raster bands are stored as separate variables in the GeoCanvas Zarr store.

Related: Raster, Spectral band, NDVI

Also called: nodata value, missing value

NoData is the sentinel value marking raster cells that hold no valid measurement: outside the imaged scene, under cloud, beyond the survey boundary. Sentinels like -9999 or NaN look like ordinary numbers unless the software knows to exclude them, so formats record the NoData value explicitly and statistics, styling, and analysis must honour it. Treating NoData as real data corrupts histograms, averages, and elevation products in ways that are easy to miss visually.

In GeoCanvas: GeoCanvas ingest honours NoData when tiling rasters for display and analytics.

Related: Raster, Cloud mask, Bit depth

Also called: data type, pixel depth

Bit depth is the number of bits used per pixel value, which fixes the range and precision a raster can express. Eight-bit data stores 256 values, typical for display imagery; sixteen-bit data preserves the subtle reflectance differences sensors measure; 32-bit floats hold continuous model output without clipping. Deeper types cost storage and bandwidth, so pipelines choose deliberately: keep measurement precision through analysis, then convert thoughtfully for display.

Related: Band, Radiometric resolution, NoData

Also called: georeference

Georeferencing ties an image or grid to real-world coordinates. Without it, a scan or photo is just a picture; with it, every pixel has a map position and the raster can align with other layers. The link is established with ground control points or a stored transform, and modern formats like GeoTIFF persist it as an affine transform plus a CRS tag. Georeferencing historical maps and aerial photos is a common first step that unlocks decades of archived imagery for analysis.

In GeoCanvas: Ingested rasters carry their georeferencing into the tile-aligned Zarr store.

Related: Affine transform, Coordinate reference system (CRS), GeoTIFF

Also called: geotransform

An affine transform is the six-parameter linear mapping between pixel row and column coordinates and map x and y coordinates. It encodes the origin, the pixel size in each direction, and optional rotation or shear. GDAL calls this the geotransform, and it is how most rasters record georeferencing. Because the mapping is linear, it cannot correct terrain displacement or lens distortion; those cases need orthorectification or a full warp with control points instead.

Related: Georeferencing, Resampling, Raster

Resampling computes new pixel values whenever a raster grid changes: during reprojection, up- or down-scaling, or alignment to another grid. The method choice changes the data. Nearest neighbour copies the closest value and preserves categories, making it right for land cover. Bilinear and cubic convolution average neighbours and suit continuous data like elevation. Resampling never creates detail; it only re-expresses what the source grid held, so the method should match the measurement type.

Related: Reprojection, Spatial resolution, Affine transform

Also called: image pyramid, raster overviews

An overview pyramid is a stack of precomputed lower-resolution copies of a raster. When a viewer zooms out, it reads a small overview instead of decimating the full grid, which keeps rendering fast at every scale. Cloud Optimized GeoTIFFs embed overviews internally, and tile services build equivalent pyramids. The trade is storage for speed: pyramids add roughly a third more data but remove the need to process full resolution for every low-zoom request.

In GeoCanvas: GeoCanvas stores rasters as tile-aligned Zarr so overview reads map directly onto chunked object storage.

Related: Raster, Cloud Optimized GeoTIFF (COG), Zarr

A digital elevation model is a raster where each cell holds an elevation value. DEM is the umbrella term; it splits into digital terrain models, which show bare earth, and digital surface models, which include buildings and vegetation. Slope, aspect, hillshade, watersheds, and visibility are all derived from DEMs. Two details decide fitness for use: the vertical reference, since ellipsoid and geoid heights differ, and the resolution relative to the terrain features being studied.

Related: Digital surface model (DSM), Digital terrain model (DTM), Geoid

A digital surface model records the elevation of the top surface visible to the sensor: rooftops, treetops, and everything else above the ground. Lidar and photogrammetry naturally produce surface models from first returns. Subtracting a bare-earth terrain model from a surface model yields object heights, which drives building-height mapping, forest structure estimates, and line-of-sight analysis. Confusing a DSM with bare earth is a common pitfall in flood and viewshed work.

Related: Digital elevation model (DEM), Digital terrain model (DTM), LiDAR

Also called: bare earth model

A digital terrain model shows bare-earth elevation with vegetation, buildings, and other surface objects removed. Producing one means classifying ground returns in a point cloud or filtering a surface model, so a DTM is a derived product rather than a direct measurement. Terrain models are the base layer for hydrology, flood simulation, and earthworks, where water and soil respond to the ground surface, not to the canopy above it.

Related: Digital elevation model (DEM), Digital surface model (DSM), Point cloud

Also called: orthoimage, orthophotograph

An orthophoto is an aerial or satellite photograph that has been orthorectified: geometrically corrected so scale is uniform and every pixel sits in its true map position. Unlike a raw photo, an orthophoto measures like a map, so it serves as a trusted basemap and a backdrop for digitising. Quality depends on the source imagery, the elevation model used for correction, and the acquisition date, which matters when comparing against current conditions on the ground.

Related: Orthorectification, Basemap, Raster

GeoJSON is a JSON encoding of geographic features, standardised as RFC 7946. A Feature wraps one geometry with properties; a FeatureCollection groups them. Because it is plain JSON, every programming language and browser can parse it without special libraries, which made it the default of web mapping. The specification fixes coordinates as WGS 84 longitude-latitude order. GeoJSON is verbose and unindexed, so it suits small to medium datasets rather than planetary-scale delivery.

In GeoCanvas: GeoCanvas imports and exports GeoJSON for interchange with other tools.

Related: Feature, Well-Known Text (WKT), GeoPackage, Axis order

Also called: ESRI shapefile, shp

The shapefile is the veteran Esri vector format: a .shp of geometries, a .shx index, and a .dbf of attributes, usually with a .prj declaring the CRS. Decades of adoption made it the most exchangeable GIS format, and nearly every tool reads it. Its limits are real: a 2 GB size cap, ten-character field names, dBASE encoding quirks, and multiple sidecar files that must travel together. For new work, GeoPackage avoids these traps while remaining just as open.

In GeoCanvas: GeoCanvas accepts shapefile uploads, converting them at ingest.

Related: GeoPackage, GeoJSON, Feature

Also called: gpkg

GeoPackage is an open OGC standard that stores vector features, tile pyramids, and rasters inside a single SQLite file with spatial indexes. One self-contained .gpkg replaces the shapefile and its sidecar files, with none of the field-name or size limits, and any SQLite-capable tool can open it. Desktop GIS, mobile apps, and data portals use it for exchange and offline work. It is the recommended default when a modern, file-based vector format is needed.

In GeoCanvas: GeoCanvas imports GeoPackage layers through its GDAL-based ingest.

Related: Shapefile, Spatial index, R-tree

Also called: fgb

FlatGeobuf is a binary encoding of vector features built on FlatBuffers, with a packed R-tree index at the front of the file. The layout lets clients stream features and answer bounding-box queries with HTTP range requests, downloading only the bytes they need. That makes it a strong fit for web applications showing one region of a large dataset. GDAL, QGIS, PostGIS, and JavaScript libraries all read and write it.

Related: R-tree, GeoParquet, GeoJSON

GeoParquet adds standardised geospatial metadata to Apache Parquet, the columnar storage format of the analytics world. Geometries live in a column, typically as Well-Known Binary, with CRS and encoding declared in file metadata. Columnar layout, compression, and partitioning make analytical queries over huge vector datasets fast and cheap on object storage. GeoParquet is a cloud-native analytics format rather than a streaming display format like FlatGeobuf.

In GeoCanvas: GeoCanvas analytics runs SQL over GeoParquet in object storage through embedded DuckDB.

Related: GeoArrow, DuckDB Spatial, Well-Known Binary (WKB)

GeoArrow defines an Apache Arrow memory layout for geometries and their coordinates. Arrow stores data in columnar form that tools can share without serialisation, so GeoArrow lets GDAL, DuckDB, Python, Rust, and JavaScript pass geometry between each other at memory speed. It complements GeoParquet: Arrow is the in-memory layout, Parquet the on-disk one. Adoption is driven by pipelines that move large vector data between analytics engines.

Related: GeoParquet, Well-Known Binary (WKB), DuckDB Spatial

Well-Known Text is the standard text encoding of geometry: POINT (30 10), LINESTRING, POLYGON, and their multi-part forms, defined by OGC Simple Features. Being readable, WKT is the lingua franca of spatial SQL, CSV exports, and debugging output. A related WKT grammar also describes coordinate reference systems and projections. WKT carries no CRS for geometry on its own, so the reference system must travel separately in the column metadata or the query context.

In GeoCanvas: DuckDB Spatial analytics in GeoCanvas accept and return geometries as WKT.

Related: Well-Known Binary (WKB), Geometry, GeoJSON

Well-Known Binary is the binary twin of Well-Known Text: the same geometry model serialised to compact bytes. WKB parses faster and stores smaller than text, so databases and file formats use it as their wire and storage encoding; GeoPackage and GeoParquet both embed WKB geometry columns. It is not human-readable, which is the deliberate trade for efficiency. Variants such as EWKB add embedded CRS identifiers on top of the base standard.

Related: Well-Known Text (WKT), GeoArrow, GeoParquet

Also called: geo tiff

GeoTIFF is the TIFF image format extended with tags that record georeferencing: the affine transform, the CRS, and NoData values. It has been the workhorse of raster exchange for decades, and essentially every GIS and image-processing library reads it. The format is flexible about compression and tiling, which matters for performance: an untiled GeoTIFF forces readers to scan whole rows, while a tiled, compressed one is also the foundation of the Cloud Optimized GeoTIFF profile.

In GeoCanvas: GeoCanvas ingests GeoTIFF rasters into its cloud-native tile store.

Related: Cloud Optimized GeoTIFF (COG), Georeferencing, Raster

A Cloud Optimized GeoTIFF is a GeoTIFF arranged so clients can read windows and overviews over plain HTTP range requests: internally tiled, with embedded overview pyramids and headers placed first. The layout lets a viewer fetch one screenful of a terabyte image without downloading the file. COGs require no special server, only object storage, which made them the backbone of public cloud raster archives. Any valid COG is also a valid GeoTIFF for existing software.

In GeoCanvas: GeoCanvas reads source rasters as COGs when ingesting to its Zarr store.

Related: GeoTIFF, Overview (pyramid), Zarr

Zarr is a cloud-native format for chunked, compressed N-dimensional arrays. An array is split into chunks, each stored as an independent object with its own compression, so readers fetch exactly the chunks they need in parallel. Version 3 of the specification standardised the layout for interoperability. Zarr suits large raster cubes: imagery time series, climate grids, and elevation stacks, especially when paired with object storage where each chunk is one object.

In GeoCanvas: GeoCanvas stores raster layers as tile-aligned Zarr v3 on object storage and reads chunks directly in the server.

Related: NetCDF, Cloud Optimized GeoTIFF (COG), Overview (pyramid)

Also called: netCDF, Network Common Data Form

NetCDF, the Network Common Data Form, is a self-describing format for array-oriented scientific data: dimensions, variables, and attributes travel together in one file, with the CF conventions standardising how coordinates and units are recorded. It is the long-standing standard of climate, ocean, and atmospheric modelling. On cloud object storage the same community increasingly uses Zarr, and tools bridge the two, but NetCDF files remain common in scientific archives.

Related: Zarr, Raster, Band

A slippy map is the familiar interactive web map that pans smoothly and zooms in discrete steps, popularised by Google Maps and OpenStreetMap. Under the hood it is a grid of pre-rendered or pre-built tiles in Web Mercator: each zoom level doubles the resolution, and the viewer loads only the tiles in view. The pattern turned planetary map delivery into a simple static-file problem, and it remains the default mental model for interactive mapping on the web.

In GeoCanvas: The GeoCanvas editor is a slippy map with deck.gl data layers on top.

Related: XYZ tiles, Web Mercator, Basemap

Also called: base map

A basemap is the background map that gives operational layers geographic context: streets, terrain, imagery, or a neutral blank canvas. Good basemap design supports the data rather than competing with it, which is why cartographers keep reference labels and colours subdued where overlays will sit. Basemaps are delivered as raster or vector tiles with their own styles, and switching between a street and an imagery basemap is a standard feature of any map editor.

In GeoCanvas: GeoCanvas connects directly to basemap providers without a proxy.

Related: Layer, Map style, XYZ tiles

Also called: tile

A map tile is one small square chunk of a larger map, identified by its zoom level and x/y position, typically 256 or 512 pixels on a side. Tiles make world-scale maps practical: instead of one enormous image, the server offers millions of small, cacheable pieces, and clients fetch only what is visible. Tiles come in two families: raster tiles are pre-rendered images, while vector tiles carry clipped geometry and attributes for the client to draw.

Related: XYZ tiles, Vector tile, Tile matrix set

Also called: XYZ scheme, slippy map tiles, z/x/y tiles

XYZ is the de facto standard URL scheme for map tiles: /z/x/y.png addresses one tile of a Web Mercator quadtree with the origin at the top-left. Its simplicity made it universal across tile servers, CDNs, and client libraries. The older TMS convention differs only in flipping the y axis, a mismatch that silently mirrors tiles when the two are confused. Most modern services default to XYZ and mark TMS variants explicitly.

In GeoCanvas: GeoCanvas serves its tile endpoints in the XYZ scheme behind a CDN.

Related: TMS, Tile matrix set, Slippy map

Also called: Tile Map Service

The Tile Map Service is an OSGeo-era specification for addressing map tiles, similar to XYZ but with the y axis origin at the bottom-left instead of the top-left. Serving TMS tiles through an XYZ client, or the reverse, flips the map vertically, a classic integration bug. New work usually standardises on XYZ for ad-hoc tiles or on the formal OGC tile matrix set model for services. The acronym now collides with tile matrix set, so context matters.

Related: XYZ tiles, Tile matrix set, Map tile

Also called: OGC tile matrix set

A tile matrix set is the formal OGC description of a tiling scheme: the coordinate reference system, the set of zoom levels called tile matrices, tile sizes, and the grid origin. Publishing the matrix set lets any client compute tile addresses without guesswork, even in projections other than Web Mercator. WebMercatorQuad is the common shared set, and OGC API - Tiles and WMTS both advertise tile matrix sets in their capabilities documents.

Related: TMS, Web Mercator, OGC API - Tiles

A vector tile is a map tile that carries clipped vector geometries and attributes instead of a rendered image. Because styling happens in the client, one tile set supports many map styles, stays crisp on high-density screens, and often weighs less than raster tiles. The Mapbox Vector Tile encoding dominates, rendered by MapLibre GL, deck.gl, and most modern web map stacks. Tiles are usually built once, then served as static files or archives.

In GeoCanvas: GeoCanvas vector layers are delivered as vector tiles built at ingest.

Related: Mapbox Vector Tile (MVT), PMTiles, Map style

The Mapbox Vector Tile specification encodes tiled vector data with Protocol Buffers: each tile holds named layers of features with geometry and key-value attributes. The compact binary form and the layer/feature model became the de facto standard for vector tiles far beyond Mapbox itself. Renderers decode MVT in the browser and apply styles at draw time. The specification is openly licensed and versioned, which encouraged its adoption across the ecosystem.

In GeoCanvas: MVT is the wire format GeoCanvas uses between its tile service and deck.gl.

Related: Vector tile, PMTiles, WebGL

PMTiles is a single-file archive format for tile pyramids. A header and directory at the front of the file let clients fetch any tile with one or two HTTP range requests, so an entire planet of tiles can live as one object on S3-style storage. That removes the need for a tile server and for uploading millions of small objects. The format works for vector and raster tiles alike and has seen wide adoption for serverless map publishing.

In GeoCanvas: GeoCanvas serves vector layers from PMTiles archives on S3-compatible object storage.

Related: Mapbox Vector Tile (MVT), XYZ tiles, Cloud Optimized GeoTIFF (COG)

Also called: style document, map stylesheet

A map style is the document that decides how data draws: which source layers appear, with what colours, line widths, labels, and zoom-dependent rules. The MapLibre style specification is the open dialect: JSON that pairs a tile source with a list of styled layers and expressions. Separating style from data is the vector-tile revolution in one idea: the same tiles can render as a dark navigation map, a print basemap, or an analysis backdrop without rebuilding anything.

In GeoCanvas: GeoCanvas basemaps are selectable map styles rendered over shared tiles.

Related: Basemap, Vector tile, Classification

WebGL is the browser API that gives JavaScript access to GPU-accelerated graphics inside a canvas element. It knows nothing about geography: it draws triangles with programmable shaders very fast. Map libraries such as MapLibre GL and deck.gl build geospatial smarts on top, using the GPU to render millions of vertices smoothly. WebGL made interactive visualization of large spatial datasets practical in a plain web page, with WebGPU now emerging as its successor.

In GeoCanvas: All GeoCanvas map rendering runs on WebGL through deck.gl.

Related: deck.gl, Vector tile, Map style

deck.gl is a WebGL-powered framework for large-scale geospatial visualization, developed by the vis.gl community under the OpenJS Foundation. It offers declarative layer types, from GeoJsonLayer and MVTLayer to hexagon aggregations, composited on the GPU and designed to sit over any basemap. Its data-driven model updates rendered output when data changes, which suits live editing and dashboards. It is framework-agnostic and works with any JavaScript stack.

In GeoCanvas: deck.gl is the rendering engine behind every layer on the GeoCanvas map.

Related: WebGL, Mapbox Vector Tile (MVT), Layer

Also called: Web Map Service

The OGC Web Map Service standard serves map images rendered on demand: a client sends a GetMap request with a bounding box, size, layers, and CRS, and the server returns a picture. WMS made maps from many agencies viewable in any compatible client, and thousands of public services still run. The trade-off is that images cannot be restyled or queried client-side, and every pan asks the server to render again, which is why tiles and vector data have taken over interactive maps.

Related: WMTS, WFS, OGC API - Features

Also called: Web Feature Service

The OGC Web Feature Service standard serves the vector features themselves, not pictures: clients request feature types with spatial and attribute filters and receive GML or GeoJSON back. Because real geometries arrive, clients can analyse, edit, and restyle them. WFS versions differ in encodings and axis-order behaviour, which historically caused integration pain. The modern successor, OGC API - Features, re-expresses the same capability over REST and JSON.

Related: WMS, OGC API - Features, Feature

Also called: Web Map Tile Service

The OGC Web Map Tile Service standard formalises tile access: a capabilities document advertises the available layers, tile matrix sets, and URL templates, and clients fetch pre-rendered tiles accordingly. WMTS brought the cache-friendliness of tiles into the standards world that WMS left to ad-hoc conventions, and it supports both RESTful and key-value-pair request encodings. OGC API - Tiles now carries the same ideas into the OpenAPI generation of standards.

Related: WMS, Tile matrix set, OGC API - Tiles

Also called: OGC API Features

OGC API - Features is the modern OGC standard for serving vector features over REST and JSON. Collections are listed at predictable paths, items page with stable links, and queries filter by bounding box, time, and properties, all described with OpenAPI. It replaces WFS integration patterns with conventions every web developer already knows, and servers like pygeoapi and GeoServer implement it alongside the older service standards.

Related: WFS, Bounding box, GeoJSON

Also called: OGC API Tiles

OGC API - Tiles is the modern OGC standard for tiled access to maps, vector data, and coverages. It builds on the tile matrix set model: servers declare which sets and formats they offer, and clients fetch tiles through OpenAPI-described endpoints. The standard carries the WMTS capability model into the REST and JSON era while staying compatible with plain XYZ-style consumption, letting one service satisfy both simple and formal clients.

Related: WMTS, Tile matrix set, Vector tile

A buffer is the polygon of all points within a given distance of a geometry: a hundred-metre strip around a river, a one-kilometre zone around a school. Buffering is the staple of proximity analysis, usually paired with a clip or spatial join to ask what falls inside the zone. Distance is a projected-CRS concept: buffering in degrees produces nonsense shapes, so reproject first or use geodesic buffers for global data.

In GeoCanvas: GeoCanvas analytics can compute buffers with DuckDB Spatial SQL.

Related: Polygon, Clip, Spatial join

Clipping cuts the features of one layer to the boundary of another, keeping only the parts inside the cookie-cutter polygon. It is the standard way to reduce national data to a study area. The clipped features keep their original attributes; only the geometry is trimmed. Under the hood, clipping is an overlay operation related to intersection, and large clips benefit from spatial indexes and valid input geometry on both sides.

Related: Intersection, Buffer, Geometry validity

Dissolving merges geometries that share an attribute value, or all geometries in a layer, into fewer and larger shapes, erasing the internal boundaries. Municipalities dissolve into regions; fragmented parcels dissolve into one ownership unit. Attribute values are aggregated alongside, by sum, mean, or another rule. Dissolve is the natural inverse of exploding multipart features into single parts, and engines implement it with union-style operations such as ST_Union.

Related: Union, Multipart geometry, Attribute

The intersection of two geometries is the part they share: the overlapping area of two polygons, the common segment of crossing lines. As an overlay tool, intersection keeps only the shared pieces while combining the attributes of both inputs, which answers questions like which land uses fall inside the flood zone. Intersection depends on valid geometry and a shared CRS, and it appears in SQL as ST_Intersects for the predicate and ST_Intersection for the resulting shape.

In GeoCanvas: GeoCanvas analytics evaluates intersections in DuckDB Spatial.

Related: Union, Clip, Spatial relationship

Union combines geometries into a single coverage. As an overlay, it keeps all areas from both inputs, splitting features where boundaries cross and merging attributes from each side. As an aggregate, it merges many geometries into one shape, which is how dissolves are computed. Union is the complement of intersection: where intersection keeps only the overlap, union keeps everything, including the parts present in only one input.

Related: Intersection, Dissolve, Multipart geometry

A spatial join attaches rows from one dataset to another based on a spatial relationship instead of a shared key: each point gets the attributes of the polygon containing it, or each parcel the nearest road. Predicates like intersects, within, and nearest define the match rule. Spatial joins are where spatial indexes pay off, turning a quadratic comparison of every pair into an indexed lookup. They are the everyday workhorse for enriching points with zones and zones with contents.

In GeoCanvas: GeoCanvas analytics supports spatial joins over GeoParquet in DuckDB.

Related: Spatial relationship, Spatial index, Nearest neighbour

Also called: nearest neighbor, KNN

Nearest neighbour analysis finds the closest feature or features to a target: the three nearest clinics to each address, the closest road to each sensor. Tools expose it as sjoin_nearest, KNN operators such as PostGIS distance ordering, or dedicated index structures. Two practical cautions apply: measure in a projected CRS so distance is honest, and define the tie behaviour, because equidistant candidates are common on grids and road networks.

Related: Spatial join, Centroid, Spatial index

Interpolation estimates values at unsampled locations from surrounding measurements, turning scattered weather stations, soundings, or survey points into a continuous surface. Methods range from inverse distance weighting and TINs to kriging, each with its own assumptions about how values vary across space. Every interpolated cell is a model output, not a measurement, so surfaces should be validated against held-out samples before decisions rely on them.

Related: Raster, Spatial autocorrelation, Heat map

Also called: address geocoding

Geocoding converts addresses and place names into coordinates using reference data: street networks, address points, and administrative hierarchies. It is the bridge between spreadsheets full of addresses and mappable points. Results carry quality metadata such as match type and confidence, which deserve attention because rooftop matches and postcode centroids are very different things. Services like Nominatim publish usage policies, so batch jobs should cache results and respect rate limits.

Related: Reverse geocoding, Coordinate, Point

Reverse geocoding converts coordinates into the nearest address or place name: click a map, get a description of what is there. The service searches its reference data by proximity and hierarchy and returns the best candidate. Results are approximations: a point in a park may return the nearest street address, and rural areas resolve at village level. Reverse geocoding powers location pickers, photo tagging, and the what-is-here question in most map applications.

Related: Geocoding, Point, Nearest neighbour

Also called: route planning, network routing

Routing computes the best path through a network, usually roads, by minimising a cost such as travel time or distance. It needs more than line geometry: the network must carry topology, so the engine knows which segments connect, plus attributes like speed, direction, and turn restrictions. Engines such as OSRM, Valhalla, and pgRouting pre-process OpenStreetMap into routable graphs. Output is the ordered path with its cost, ready for directions or isochrone generation.

Related: Isochrone, Topology, Line

Also called: travel time polygon, drive time area

An isochrone is the polygon of everywhere reachable from a starting point within a time or distance budget: the 15-minute walking zone around a station. Unlike a circular buffer, an isochrone follows the real network, so rivers, motorways, and one-way streets shape it. Isochrones are computed from routing graphs, for example with pgRouting driving-distance functions, and they power accessibility analysis for services, retail, and emergency planning.

Related: Routing, Buffer, Nearest neighbour

Also called: Moran's I

Spatial autocorrelation measures the degree to which nearby values resemble each other, formalising the first law of geography that near things are more related than distant things. Statistics such as the Moran I index test whether a pattern is clustered, dispersed, or indistinguishable from random, and local variants find hotspots. The concept underpins interpolation, hotspot detection, and much of spatial statistics. Ignoring it breaks ordinary statistical assumptions, because neighbouring observations are not independent.

Related: Interpolation, Clustering, Heat map

Also called: choropleth

A choropleth map shades areas, such as districts or countries, according to a statistical value. Done well it is one of the most readable thematic map types. The classic pitfalls are shading by raw counts instead of normalised rates, choosing a classification that hides or invents patterns, and using rainbow colours that imply false ordering. Normalise first, classify deliberately, and pick a sequential or diverging scheme from ColorBrewer, which was designed exactly for this task.

In GeoCanvas: GeoCanvas styles vector layers with classed and unclassed choropleth fills.

Related: Classification, Map style, Attribute

Also called: data classification, choropleth classification

Classification groups a continuous attribute into a small set of classes for display: equal interval splits the range evenly, quantiles put equal counts in each class, and natural breaks algorithms search for gaps in the distribution. The choice changes the story a map tells, sometimes dramatically, so honest mapping documents the method and class count. Classification also applies to imagery, where it assigns land-cover categories pixel by pixel.

Related: Choropleth map, Map style, Attribute

Also called: heatmap, density map

A heat map renders point events as a continuous density surface, usually with kernel density estimation: crimes, sightings, or check-ins blur into smooth hotspots. It reveals patterns that thousands of overlapping markers hide. The smoothness is a parameter choice, not a discovery: the kernel radius controls how local or diffuse the result looks, and a heat map shows where events concentrate, not the value of anything at those places. Reading it as a measurement surface is a common mistake.

Related: Clustering, Interpolation, Spatial autocorrelation

Also called: point clustering

Clustering groups nearby points into aggregate symbols so dense datasets stay readable. On web maps, marker clustering merges points into count badges that expand as you zoom, computed client-side by MapLibre or deck.gl. In analysis, clustering algorithms such as k-means or DBSCAN group observations by location and attributes to find structure in the data itself. The two meanings share a goal: turn overwhelming counts of points into comprehensible groups.

In GeoCanvas: GeoCanvas clusters large point layers client-side with deck.gl.

Related: Heat map, Vector tile, Point

Also called: remote sensing

Earth observation is the collection of information about the planet from satellite and airborne sensors rather than from instruments in contact with the ground. Passive sensors record reflected sunlight and emitted heat; active sensors like radar and lidar send their own signal and time the echo. Programmes such as Landsat and the Copernicus Sentinels provide decades of free global imagery that feeds agriculture, disaster response, climate monitoring, and mapping.

Related: Spectral band, Synthetic aperture radar (SAR), LiDAR

Also called: wavelength band

A spectral band is the interval of wavelengths a sensor records in one channel: blue, green, red, near-infrared, shortwave infrared, thermal. Different materials reflect each band differently, so band combinations expose what the eye cannot separate: vegetation health, open water, burn scars, bare soil. Ratio products like NDVI are arithmetic on two bands. Band definitions differ between sensors, so comparing products across satellites starts with checking the wavelength tables.

Related: Band, NDVI, Spectral resolution

Also called: revisit time

Temporal resolution is how often a sensor collects new imagery of the same place: the revisit time. Landsat revisits every 16 days, the Sentinel-2 pair about every 5, and geostationary weather satellites stare continuously. Revisit trades against spatial resolution in mission design, because a satellite cannot be everywhere at once with a narrow detailed swath. Clouds cut the effective rate further, so time-series work often composites several passes to build one clean view.

Related: Earth observation (EO), Analysis-ready data (ARD), Cloud mask

Spectral resolution describes how finely a sensor divides the spectrum: the number and width of its wavelength bands. Multispectral sensors record a handful of broad bands; hyperspectral sensors record hundreds of narrow ones, enough to discriminate minerals, crop species, or materials by their spectral fingerprints. Finer spectral resolution adds analytical power at the cost of data volume and signal per band, so missions balance it against swath and spatial detail.

Related: Spectral band, Radiometric resolution, Earth observation (EO)

Radiometric resolution is how finely a sensor can distinguish small differences in incoming energy, expressed as the bit depth of each pixel. A sensor with 12-bit radiometry records over four thousand brightness levels, revealing subtle contrast that 8-bit data flattens. It interacts with spectral and spatial resolution: finer radiometry supports precise indices and classifications, and analysis-ready products preserve the native depth rather than clipping to display range.

Related: Bit depth, Spectral resolution, Reflectance

Also called: surface reflectance

Reflectance is the fraction of incoming radiation that a surface reflects, a physical quantity rather than a raw sensor count. Top-of-atmosphere reflectance still contains the atmosphere; surface reflectance has been atmospherically corrected to estimate what the ground itself reflects. Indices like NDVI and any comparison across dates or sensors need reflectance, not digital numbers, which is why analysis-ready products deliver surface reflectance as their baseline.

Related: NDVI, Analysis-ready data (ARD), Spectral band

Also called: Normalized Difference Vegetation Index

The Normalized Difference Vegetation Index is the ratio of near-infrared minus red over their sum, ranging from minus one to one. Healthy vegetation reflects strongly in near-infrared and absorbs red, so high NDVI indicates dense, vigorous canopy, while water and bare soil score low or negative. NDVI is computed from reflectance, not raw counts, and it saturates over thick vegetation. It remains the most widely used vegetation index in monitoring and agriculture.

Related: Spectral band, Reflectance, Earth observation (EO)

Synthetic aperture radar is an active microwave instrument that transmits pulses and records their echoes, building images from signal processing rather than sunlight. SAR sees at night and through clouds, which makes it indispensable for flood mapping and tropical monitoring, and phase comparisons between passes measure ground deformation at millimetre scale. SAR data brings its own artefacts, speckle and terrain-related distortion among them, so it rewards dedicated processing and calibration before interpretation.

Related: Earth observation (EO), Orthorectification, Temporal resolution

Also called: lidar, light detection and ranging

LiDAR, light detection and ranging, measures distance by timing laser pulses from an aircraft, drone, vehicle, or tripod. Millions of returns per second build dense 3D point clouds of terrain and structure. Because pulses can slip through canopy gaps, lidar maps both the forest top and the ground beneath, producing surface and bare-earth elevation models. Programmes like USGS 3DEP collect national lidar coverage, and the point clouds feed flood modelling, forestry, and engineering.

Related: Point cloud, Digital terrain model (DTM), Digital surface model (DSM)

A point cloud is a set of three-dimensional points, usually from lidar or photogrammetry, each carrying coordinates plus attributes such as intensity and classification. Point clouds are the raw material of elevation products: ground points build terrain models, first returns build surface models, and classified points identify buildings and vegetation. LAS and its compressed twin LAZ are the standard encodings, with COPC adapting them for range-request access in the cloud.

Related: LiDAR, Digital surface model (DSM), Digital terrain model (DTM)

Also called: cloud masking, QA band

A cloud mask is a per-pixel quality layer that flags clouds, cloud shadows, snow, and other contamination in satellite scenes, delivered as quality-assessment bands alongside the imagery. Applying the mask before compositing or computing indices prevents clouds from masquerading as signal. Masks are algorithmic products with their own errors, so critical work checks the QA documentation and, where needed, compares masks across sensors.

Related: NoData, Analysis-ready data (ARD), Reflectance

Orthorectification removes the geometric distortions of sensor tilt and terrain relief from imagery so that every pixel sits in its true map position. The process combines a rigorous sensor model with an elevation model; in rugged terrain the quality of that elevation model limits the result. The output is orthoimagery and orthophotos that align with maps and can be measured directly. SAR data undergoes an analogous terrain-correction step for its own geometry.

Related: Orthophoto, Georeferencing, Synthetic aperture radar (SAR)

Also called: SpatioTemporal Asset Catalog

The SpatioTemporal Asset Catalog specification describes geospatial assets, imagery, terrain, data cubes, as JSON items with a footprint, a time range, and links to the data files. Catalogs and collections organise items, and an API makes them searchable. STAC gave the community one catalog language, so a single client can search Landsat on one provider and Sentinel on another. It pairs naturally with cloud-native formats that the items point to.

Related: Analysis-ready data (ARD), Earth observation (EO), Metadata

Analysis-ready data is imagery preprocessed so users can start analysis immediately: surface reflectance in geophysical units, cloud masks applied, consistent tiling and alignment across dates, and complete metadata. The CEOS ARD initiative defines the minimum processing and metadata a product needs to earn the label. ARD removes the duplicated correction work every team used to repeat, and it is the form in which cloud platforms serve most modern satellite archives.

Related: Reflectance, Cloud mask, STAC

A spatial database is a database engine that understands geometry: it stores spatial types, indexes them with structures like R-trees, and answers spatial questions in SQL, from containment tests to overlays. PostGIS extends PostgreSQL this way, SpatiaLite does the same for SQLite, and DuckDB Spatial brings it to embedded analytics. Putting spatial logic in the database turns GIS questions into queries that scale, and it lets many tools share one consistent copy of the data.

In GeoCanvas: GeoCanvas splits the two roles: PostgreSQL holds application state while embedded DuckDB runs geospatial analytics.

Related: PostGIS, DuckDB Spatial, Spatial index

PostGIS is the open-source spatial extension for PostgreSQL. It adds geometry and geography types, GiST spatial indexes, and hundreds of functions for measurement, predicates, overlays, and format conversion, effectively turning Postgres into the reference spatial database. Because it builds on a mature relational engine, it scales from laptop projects to national infrastructure, and most GIS tools, from QGIS to GeoServer, connect to it directly.

In GeoCanvas: GeoCanvas uses PostgreSQL for application state; geospatial SQL analytics run in embedded DuckDB rather than PostGIS.

Related: Spatial database, DuckDB Spatial, GEOS

DuckDB Spatial is the geospatial extension for DuckDB, the embedded analytical database. It adds geometry types, spatial predicates and joins, and GDAL-backed readers for dozens of formats, including direct SQL over GeoParquet on local disk or object storage. Because DuckDB runs in-process with no server to manage, it fits analytics workloads inside applications, notebooks, and edge services where a full spatial database would be too heavy.

In GeoCanvas: GeoCanvas embeds DuckDB with the spatial extension as its analytics engine.

Related: Spatial database, GeoParquet, GDAL

Also called: Geospatial Data Abstraction Library

The Geospatial Data Abstraction Library is the open-source translator and processor for raster and vector formats. Its command-line tools, gdal_translate, gdalwarp, and ogr2ogr, convert, reproject, clip, and inspect data in hundreds of formats, and its library sits underneath QGIS, GeoServer, and most of the geospatial stack. When data refuses to cooperate, GDAL is usually the tool that explains why, and the one that fixes it.

In GeoCanvas: GeoCanvas uses GDAL-based tooling when ingesting uploaded layers and rasters.

Related: PROJ, GEOS, GeoTIFF

Also called: PROJ.4, proj4

PROJ is the open-source library for coordinate reference system transformations. It ships with a database of thousands of CRS definitions, performs projections and datum shifts, and is called by GDAL, QGIS, PostGIS, and countless pipelines whenever data moves between reference systems. Modern PROJ versions emphasise explicit, high-accuracy transformation pipelines, including time-dependent shifts for tectonic motion.

In GeoCanvas: GeoCanvas relies on PROJ-backed transforms to normalise incoming data.

Related: Reprojection, EPSG code, GDAL

Also called: Geometry Engine Open Source

GEOS, the Geometry Engine Open Source, is the C++ implementation of the OGC simple features geometry model: predicates such as intersects and contains, plus operations like buffer, union, and intersection. It is a port of the Java Topology Suite and it quietly powers Shapely, PostGIS, QGIS, and much of the Python and database geometry world. When two different tools agree exactly on a spatial predicate, they are often both calling GEOS.

Related: Spatial relationship, Geometry validity, GDAL

Also called: extract transform load

ETL, extract, transform, load, is the pipeline pattern that moves data from source systems into a target store: read it out, clean and reshape it, write it where it will be used. Geospatial ETL adds its usual transforms: reprojection, geometry repair, format conversion, and tiling, often with ogr2ogr and GDAL at the core. Pipelines earn trust when each step is scripted and logged, which also produces the lineage record that later debugging and audits need.

Related: Data lineage, GDAL, Spatial database

Metadata is structured documentation about data: what it contains, who made it, when, how it was produced, its quality, license, and lineage. The ISO 19115 family defines the geospatial metadata model, and catalogs from national portals to STAC indexes live or die by its completeness. Metadata is what turns a file into an asset: without it, nobody can judge whether data is fit for their purpose, or even find it in the first place.

Related: Provenance, Data lineage, FAIR principles

Data lineage is the record of where a dataset came from and every transformation applied along the way: which source files, which scripts, which parameters, in what order. Lineage makes results reproducible and debuggable, because any output can be traced back through the pipeline that built it. The practical rule is to capture lineage as pipelines run, not to reconstruct it afterwards from memory, and to keep it alongside the data it describes.

Related: Provenance, ETL, Metadata

Provenance is the origin and custody history of data: who created it, from what inputs, by which process, and who has handled it since. The W3C PROV family models provenance as entities, activities, and agents. Provenance emphasises derivation and responsibility, complementing the step-by-step process detail of lineage. For shared and open data, provenance is what lets a reuser judge trust and attribute correctly.

Related: Data lineage, Metadata, FAIR principles

Also called: FAIR data

The FAIR principles ask that data be Findable, Accessible, Interoperable, and Reusable: persistent identifiers, rich metadata, standard protocols and formats, and clear licenses. FAIR targets machines as much as humans, since most reuse now flows through automated discovery and processing. The principles are guidance rather than a certification, and they pair with governance frameworks like CARE that address who data serves and who controls it.

Related: CARE principles, Metadata, ODbL

Also called: CARE Principles for Indigenous Data Governance

The CARE principles, Collective benefit, Authority to control, Responsibility, and Ethics, come from the Global Indigenous Data Alliance as a governance complement to FAIR. Where FAIR focuses on making data reusable, CARE asks who that reuse serves, insisting that data about Indigenous peoples be subject to their authority and used for their benefit. Projects working with community or Indigenous data should read CARE alongside any open-data checklist.

Related: FAIR principles, Metadata, Provenance

Also called: Open Database License

The Open Database License is a share-alike license designed for databases rather than creative content: users may copy, adapt, and build on the database provided they attribute, share adaptations under the same terms, and keep the database open. OpenStreetMap is the most prominent user. ODbL differs from Creative Commons licenses in addressing database rights specifically, which matters in jurisdictions that treat databases as protectable collections separate from their contents.

Related: FAIR principles, Metadata, CARE principles