Skip to content

GIS

systems for data that has a place on a map

What it is

A GIS, short for geographic information system, is the combination of data, software and working habits that lets people store, analyse and draw things that have a position on the Earth. The QGIS project’s own introduction to the subject is careful to say that the term covers more than a program: it lists the digital data and the computers alongside the software, and treats GIS as everything involved in managing and using geographic data. The field took shape in the 1970s on equipment that only universities and large companies could afford. Today a laptop runs a desktop GIS, and a phone shows a web map built on the same ideas.

Every GIS works with two kinds of data.

  • Vector data records a feature as geometry: a point for a well, a line for a road, a polygon for a parish. Each feature carries a row of attributes, so a road knows its name, its surface and its speed limit, and the map can be coloured by any of them.
  • Raster data records a grid of cells, each holding one value: the colour of a pixel in an aerial photograph, the height of the ground in an elevation model, the rainfall over a month. Zoom in far enough and the cells show as blocks.

Features of one kind are grouped into layers, and layers are stacked on top of one another. That stacking is where most of the value comes from. Rivers over property parcels over a flood model answer a question that none of the three answers alone.

What lets the layers line up is the coordinate reference system. Every layer has one, and it tells the software how the numbers relate to real places, whether they are degrees of latitude and longitude or metres east and north of a national origin. A desktop GIS can reproject layers on the fly, so that data captured in different systems is drawn in one, but it can only do that for a layer whose system is declared correctly.

Around those ideas sit four kinds of work: capturing data by survey, GPS, digitising or laser scanning; storing it in files or in a spatial database; analysing it with operations such as buffers, overlays and interpolation; and presenting it as a printed map, a web map or a report.

Why it matters

The first useful decision is whether a question is spatial at all. Plenty of data has a location column without needing a GIS: counting orders per city is a group-by on a text field. A question becomes spatial when the answer depends on where things are relative to one another, so that moving one of them would change the answer. Which households lie inside the flood extent, which customers are more than half an hour’s drive from every depot, which stretches of a power grid serve the most new connections: those need geometry, a coordinate reference system and operations that understand both.

Once a question is spatial, the next decision is how much GIS to build, and there are roughly three levels. A web map that shows pins and outlines from a file needs a map library and little else. A product that answers spatial questions for its users needs a spatial database underneath, so that the questions run where the data lives. An organisation that captures and maintains its own geographic data, correcting it, versioning it and publishing it to others, needs analysts, desktop tools and written rules for data quality, because the data has become an asset in its own right. Each level costs more than the one before, and each is wasted if the question never needed it.

A map also exposes data problems that tables hide. A customer address geocoded into the middle of the North Sea passes every check in a spreadsheet and is obvious the moment it is drawn. That alone makes a quick look at the data on a map worth doing before any spatial analysis is trusted.

What it looks like in practice

The breadth of the field shows across more than thirty made-to-measure GIS projects that were built, deployed and then supported in production. Their stack lines up with the parts of a GIS described above. PostgreSQL with PostGIS stored the spatial data. GDAL/OGR moved it between formats, among them shapefiles, GeoJSON, GeoTIFF, KML and vector tiles. QGIS and JOSM handled the data work itself, and the part people saw was a web map drawn with Mapbox GL and Leaflet. The work ran from 2D and 3D mapping through LiDAR processing, georectification and vectorisation to indoor mapping and navigation.

GIS can also be the product rather than the tooling behind it. A SaaS platform for tracking renewable energy assets such as solar panels and wind turbines lacked the geospatial side its clients needed to see where those assets stood and how they performed. A GIS map application was built into the platform on a modular architecture of open-source GIS libraries, chosen to keep the system light enough for a small team to run. It grew from a basic prototype into a cornerstone of the platform, with analytics and custom dashboards, and drove a 10x increase in revenue through upsells, data licensing and new customers.

Where it goes wrong

Layers that should overlap sit apart. Roads from one supplier run beside the parcels from another instead of along their edges, or a whole layer appears in the wrong part of the world. The cause is nearly always a coordinate reference system that is missing or wrong: a shapefile delivered without its .prj file, a spreadsheet of coordinates with no word on what they mean, or data on one datum labelled as another. On-the-fly reprojection can only move a layer whose system it knows. Fix it at import: record the system of every incoming layer explicitly, reproject everything into one working system for analysis, and check the result against a point whose position on the ground is known.

Measured areas disagree with the land register. A field or a building plot measured on the map comes out larger than its official figure, and the gap grows with distance from the equator. The measurement was taken in the projection used for display. Web maps commonly use a Mercator variant, which keeps angles and shapes correct locally and pays for it by distorting area. Measure in an equal-area projection or in the national grid made for that region, or let a spatial database compute the area on the ellipsoid.

Neighbouring polygons leave gaps and overlaps. Municipal boundaries, delivery zones or fields digitised one at a time do not quite meet: thin slivers open between them, or two zones both claim the same strip. Lines that should join stop short or run past each other, which QGIS calls undershoots and overshoots, and a route search then treats the road network as broken at that spot. The features were captured independently with no topology rules. Digitise with snapping to existing vertices, run a topology check that flags gaps and overlaps, and keep each shared border as one shared line.

Attribute names arrive cut short. A layer exported as a shapefile comes back with population_density renamed population and a second column renamed populati_1. The format keeps attributes in a dBASE file, which limits a field name to 10 characters and supports only integers, reals, strings and dates, so times of day and lists are lost as well. Exchange data as GeoPackage, an OGC standard that stores layers and attributes in one SQLite file, and keep shapefiles for the tools that accept nothing else.

Further reading

  • A Gentle Introduction to GIS — the QGIS project’s free course, from vector and raster data to map production and spatial analysis.
  • Coordinate Reference Systems — the chapter on projection families, what each preserves, and reprojection on the fly.
  • Topology — gaps, overlaps, undershoots, overshoots and the snapping distance that prevents them.
  • Shapefile driver — GDAL’s notes on the format’s field-name, type and size limits.
  • GeoPackage — the OGC encoding that carries vector layers, tiles and attributes in one SQLite file.

Glossary