What Is Geospatial Data? Types, Formats and the Traps

Geospatial data is any data with a location attached to it. That definition is broad enough to include a spreadsheet with a postcode column, and that is the point: most business data is already geospatial, it just has not been treated that way.

What distinguishes geospatial data from ordinary tabular data is that the relationships between records carry information. Two rows can be near each other. One can contain another. A third can be reachable from the first in eight minutes by car. None of those relationships exist in a normal table, and all of them are the reason the data is worth mapping at all.

Vector and raster

Almost everything you encounter falls into one of two representations.

The choice is not aesthetic. A heatmap is a raster because density is continuous; forcing it into polygons imposes boundaries the phenomenon does not have. A set of stores is vector because each store is a discrete thing with attributes; rasterising it throws away everything except position.

Coordinate reference systems, and the mistake everyone makes

A coordinate reference system defines what the numbers mean. EPSG:4326, plain latitude and longitude in degrees, is the default for data exchange and the wrong system for almost any calculation.

• EPSG:4326 — latitude and longitude in degrees. For storage and exchange, not for measurement.
• EPSG:3857 — Web Mercator. For rendering slippy maps. Areas are badly distorted away from the equator.
• UTM zones — metres, accurate within a zone. A good default for city and regional analysis.
• National grids — the right answer when working inside one country and matching official data.
• Equal-area projections — required whenever you compare areas or compute density across a large region.

Topology: the errors you cannot see

Geometry can be visually perfect and structurally broken. A polygon whose boundary crosses itself will render fine and return a nonsensical area. Two adjacent districts that overlap by half a metre will double-count every point in the sliver. A road network that looks continuous may have endpoints 2 cm apart at a junction, which makes the junction impassable to a routing engine.

-- Find invalid geometry and why it is invalid
SELECT id, ST_IsValidReason(geom)
FROM boundaries
WHERE NOT ST_IsValid(geom);

-- Find overlapping neighbours that should only share edges
SELECT a.id, b.id, ST_Area(ST_Intersection(a.geom, b.geom)) AS overlap
FROM boundaries a
JOIN boundaries b ON a.id < b.id AND ST_Overlaps(a.geom, b.geom);

Run these checks before analysis, not after a result looks strange. Every hour spent on validation up front saves several spent explaining a number nobody can reproduce.

Where geospatial data comes from

• National mapping and statistical agencies: boundaries, addresses, census attributes. Authoritative, usually free, often awkward to work with.
• Open collaborative mapping: roads, buildings, POIs with global coverage and uneven density. Excellent when validated for your area.
• Commercial providers: consistent multi-country coverage, licensed, priced accordingly.
• Remote sensing: satellite and aerial imagery and everything derived from it.
• Collected data: web sources, sensors, your own operational systems, geocoded.

A sensible starting point

If you are beginning a spatial project, do these four things before anything else: state the coordinate system of every input explicitly, validate all geometry, decide which projected system you will measure in, and record the vintage of every layer. That sounds like bureaucracy and it is the difference between an analysis that survives review and one that does not.