What is the difference between raster and vector data?

Raster stores the world as a regular grid of cells, each holding a value, ideal for continuous phenomena like elevation. Vector stores discrete features as points, lines, and polygons with explicit coordinates and attributes, ideal for boundaries and objects.

When should I use raster instead of vector?

Use raster for continuous surfaces (elevation, temperature, satellite imagery, interpolated fields) and for fast cell-based map algebra. Use vector for discrete objects with sharp boundaries and rich attributes, such as parcels, faults, and wells.

How do I convert vector to raster and back?

Rasterise vector with gdal_rasterize (burning an attribute into cells) and vectorise raster with gdal_polygonize.py (tracing equal-value cells into polygons). Both change the data model, so expect loss or generalisation.

Does vector data have a resolution?

Vector has coordinate precision rather than resolution; positions are exact within the coordinate system. Raster has a fixed cell size that caps the finest detail it can represent.

Raster vs Vector GIS Data: When to Use Each Model

Short answer

Raster and vector are two data models, not two file formats. Raster divides space into a regular grid of cells, each storing one value, which suits continuous phenomena: elevation, slope, temperature, rainfall, satellite reflectance, anything that varies smoothly across space. Vector represents discrete features as points, lines, and polygons with explicit coordinates and attached attributes, which suits objects with sharp boundaries: parcels, fault traces, boreholes, geological unit polygons.

The practical question is rarely "which is better" but "which model matches the phenomenon and the operation," because the answer drives storage size, the analysis you can run, and how much fidelity you keep.

The two data models in detail

Raster. A raster is an array with an affine georeference (origin, cell size, CRS). Its defining parameter is cell size, the ground length of one pixel side. A 10 m Sentinel-2 band cannot resolve a 3 m path; the path is averaged into the cells it touches. Rasters store one value per band per cell, so multi-band rasters (RGB, multispectral, time series) stack naturally. Strengths: uniform structure makes map algebra trivial and fast (slope > 30 AND aspect_south), and continuous surfaces are represented honestly. Weaknesses: file size grows with the square of resolution, sharp boundaries become blocky, and per-feature attributes do not exist beyond the cell value.

Vector. A vector feature is a geometry (an ordered set of coordinate pairs) plus a row of attributes. Geometry types follow the OGC Simple Features model: Point, LineString, Polygon, and their Multi- variants. Strengths: exact geometry at any scale, rich attribute tables (a parcel can carry owner, area, zoning, date), small files for sparse features, and clean topology for boundary analysis. Weaknesses: representing a continuous surface forces an awkward proxy (dense contours or a TIN), and overlay operations on complex polygons are computationally heavier than cell math.

Resolution vs precision

A frequent confusion: vector data does not have a resolution, it has coordinate precision. A polygon vertex at (412355.27, 5403891.84) is an exact position in its CRS; you can zoom in indefinitely and it stays a crisp line. A raster has a hard resolution limit set by cell size; below that, detail is gone permanently. This is why a coastline at 1:10,000 is naturally vector, and why rasterising it discards the very precision that made it useful. Conversely, an interpolated groundwater surface is naturally raster, and forcing it into vector contours throws away the value at every point between contour lines.

When each model wins

Task	Better model	Why
Elevation, slope, aspect	Raster	continuous surface, cell neighbourhood math
Satellite / aerial imagery	Raster	inherently a pixel grid
Land-cover classification	Raster	per-cell class, fast overlay
Cadastral parcels, licence blocks	Vector	sharp legal boundaries, attributes
Fault traces, drainage lines	Vector	linear features with attributes
Borehole locations	Vector	discrete points with logs
Suitability modelling by overlay	Raster	weighted map algebra across layers
Distance/adjacency queries with attributes	Vector	topological relationships, indexed queries

Converting between models, and what it costs

Conversion is routine but lossy; know what you give up.

Vector to raster (rasterise). Burn an attribute or a constant into a grid:

gdal_rasterize -a unit_id -tr 25 25 -a_nodata -9999 \
  -ot Int16 -l units units.gpkg units_25m.tif

-a unit_id writes each polygon's attribute value into the cells it covers; -tr 25 25 sets the cell size. The cost: every boundary is now quantised to 25 m and snaps to the grid, so two adjacent units no longer share an exact edge, and small slivers may vanish or grow by a cell. Choose a cell size fine enough to preserve the narrowest feature you care about.

Raster to vector (vectorise). Trace contiguous equal-value cells into polygons:

gdal_polygonize.py landcover.tif -f GPKG landcover.gpkg landcover class

The cost: output polygons have staircase boundaries following cell edges. For categorical rasters this is faithful; for anything continuous it is meaningless, which is why you contour continuous rasters (gdal_contour) rather than polygonise them. Expect to simplify (ogr2ogr ... -simplify) and clean topology afterward.

Either conversion is a one-way generalisation in practice: rasterise then vectorise will not recover the original geometry.

A hybrid reality

Most real projects are hybrid. A mineral-prospectivity workflow might rasterise geology, faults (as proximity), and geochemistry to a common grid for weighted overlay, produce a raster suitability surface, then vectorise the high-suitability zones back into polygons for field planning and reporting. The discipline is to keep each layer in its native model as long as possible and convert only at the step that demands it, recording the cell size and snap grid used (see cell alignment) so the rasterised layers co-register.

Common pitfalls and why they happen

Rasterising at too coarse a cell size drops narrow polygons and merges thin units. Match cell size to the smallest feature, not to convenience.
Polygonising a continuous raster produces a fake "vector" surface with staircase edges and per-cell classes. Use gdal_contour for continuous data instead.
Assuming conversion is reversible. Each direction generalises; round-tripping degrades geometry.
Storing dense imagery as vector (or vice versa) bloats files and cripples performance because the model fights the data.
Ignoring NoData on rasterise. Without -a_nodata, background cells default to 0, which then masquerades as a real class in later overlay.

Validation

After rasterising, compare the cell-counted area per class against the source polygon areas; large discrepancies signal too-coarse a cell size.
After polygonising, overlay the polygons on the source raster and confirm boundaries follow cell edges with no spurious dissolve across classes.
Confirm CRS and (for rasters) cell size, origin, and NoData are explicit in the output metadata.
For hybrid pipelines, verify every rasterised layer shares the same grid (cell size, origin) before any map algebra.

Bathyl perspective

We pick the data model from the phenomenon and the operation, not from the format we happen to receive. Continuous ground belongs in a grid; discrete objects belong in geometry with attributes. We convert only when a specific step requires it, document the cell size and snap grid at that step, and treat every rasterise or vectorise as a generalisation to be justified, not a free transformation.

Raster vs Vector GIS Data