Vector geospatial data has a small vocabulary. A position, a sequence of positions, and an enclosed area. Everything else, every road network, cadastral map, flood extent, and points-of-interest database, is assembled from those three shapes and a set of attributes attached to them.
The vocabulary being small is a strength. It means one set of operations works across every dataset, and a tool that understands polygons understands administrative boundaries, building footprints, and lake outlines alike. It is also the point where the most consequential decisions get made, usually early and usually without discussion.
Choosing to represent a shop as a point rather than a footprint, or a road as a line rather than an area, is not a storage detail. It fixes which questions the dataset can answer, and no amount of downstream sophistication recovers what the choice discarded.
The three primitives
A point is a single position: a coordinate pair, sometimes with a third value for elevation. It has no extent and no dimension. Every operation involving a point is about where it is relative to something else, never about how big it is.
A line, more precisely a linestring, is an ordered sequence of positions connected by straight segments. Curves do not exist in this model. A curve is approximated by enough short segments that the approximation is invisible at the intended viewing scale, which means the smoothness of a river or a roundabout is a function of how densely it was digitised. A line has length and direction but no area, and the direction matters more than people expect: one-way streets, river flow, and the side of a road that a feature sits on all depend on the order of the vertices.
A polygon is an area enclosed by a ring: a closed linestring whose first and last positions coincide. A polygon may also carry inner rings, which cut holes in it. A lake with an island, an administrative area with an enclave, a building with a courtyard: each is one polygon with a hole rather than two shapes. The interior is defined by the rings rather than stored explicitly.
What each is appropriate for follows from what each supports. Points support counting, density, proximity, and containment. Lines support length, connectivity, routing, and the notion of along. Polygons support area, coverage, overlap, adjacency, and containment from the other side. If a question involves area, a point cannot answer it. If a question involves connectivity, a polygon cannot answer it without being converted into something that can.
Multi-geometries, and why they exist
Real things are frequently not connected. A country with islands is not one polygon. A river that splits around an island and rejoins is not one line. A retail chain treated as a single entity has many locations.
Multi-geometries handle this: a multipoint, a multilinestring, a multipolygon. Each is a collection of primitives of one type treated as a single feature with a single set of attributes. An archipelago nation is one feature, one name, one identifier, and forty separate polygons inside it.
They are necessary but they carry costs that show up in analysis rather than in storage.
- Bounding boxes become useless. A multipolygon whose parts are scattered across a wide area has a bounding box covering all of it, including the empty space between. Since spatial indexes filter on bounding boxes, such a feature becomes a candidate for almost every query and defeats the index.
- Centroids become meaningless. The centroid of a multipolygon can fall in open sea between the parts. Any process that reduces polygons to representative points needs a point-on-surface calculation rather than a centroid, and even then the point represents one part arbitrarily.
- Aggregations can double count. Operations that iterate over parts rather than features will process a forty-part country forty times unless they are written not to.
A geometry collection, which mixes types in one feature, is a further step and generally a sign that the data model is wrong. Most tools handle collections poorly, and a feature that is simultaneously a point and a polygon usually means two features were merged that should have stayed separate.
The modelling decision constrains every later question
The interesting decisions are not about how to store a shape. They are about what a real thing should be represented as, and the honest answer is that it depends on the questions the data has to support.
A road can be a line or a polygon. As a line, it is a centreline in a network: it connects to other roads at shared endpoints, it has length, it can be routed over, and a whole graph of the transport system falls out naturally. As a polygon, it is a paved surface with a width: it has area, it can be intersected with a flood extent to compute how much of the carriageway is submerged, it shows where the kerb is, and it supports questions about parking, obstruction, and encroachment.
Neither is more correct. A routing engine needs the centreline and cannot use the surface. A drainage model needs the surface and cannot use the centreline. Datasets that store the centreline and attach a width attribute are attempting a compromise, and it works for uniform roads and fails at junctions, laybys, and anywhere the carriageway changes shape.
A shop can be a point or a footprint. As a point, it is cheap, it is easy to count, it supports density and proximity, and it can be positioned even when nothing is known about the building. As a footprint, it has an area, which supports floorspace estimation, it can be checked for overlap with other features, and it distinguishes a large store from a kiosk.
The compromise most datasets reach is a point placed at or near the building, with the footprint held separately and linked if at all. That works until someone asks how much retail floorspace exists in a district, at which point the point representation has nothing to offer and the answer has to come from somewhere else entirely.
The general rule is that representation is lossy in one direction only. A footprint can always be reduced to a representative point. A point can never be expanded into a footprint. Where the choice is genuinely uncertain, storing the richer representation and deriving the simpler one on demand is the option that does not close doors.
Topology, and why shared boundaries matter
Adjacent areas share edges. Two districts that border each other are not two independent polygons that happen to be near each other, they are two polygons whose common boundary is the same line.
Whether the data model knows that is the difference between a topological dataset and a simple feature dataset. In a simple feature model, each polygon stores its own complete ring, and the shared boundary exists twice, as two copies of the same coordinates. In a topological model, the boundary is stored once and referenced by both areas.
The simple feature model is what most formats and most tools use, and it works, but three problems follow from storing the boundary twice.
Slivers and gaps appear when the two copies are not identical. If they differ by a fraction of a metre, the union of the two polygons contains a thin gap and their intersection a thin overlap. Neither is visible at any normal zoom level. Both break area calculations, produce spurious tiny polygons in overlay operations, and cause points near the boundary to fall in both areas or neither.
Edits diverge. Moving a boundary in one polygon without moving the identical edge in its neighbour creates an inconsistency that no validity check catches, because each polygon is individually perfectly valid.
Coverage cannot be assumed. A set of polygons that is supposed to tile a region without gaps or overlaps may not, and confirming that it does requires an explicit check rather than being guaranteed by the model.
Where a dataset is meant to be a partition of space, verifying that property directly is worth doing: compute the union, compare its area against the sum of the parts, and inspect the difference. A mismatch of a rounding error is fine. A mismatch that resolves into thousands of sliver polygons means the boundaries were assembled from sources that do not agree.
Invalid geometry, and what it breaks
A geometry can be syntactically well formed and still be invalid under the rules that spatial operations assume. Invalid geometry is one of the most common causes of pipeline failure, and the failures are frequently not where the invalid data is.
The recurring forms:
- Self-intersection. A ring that crosses itself, usually the result of a digitising error or an over-aggressive simplification. The interior of such a polygon is undefined, so area may come back negative, zero, or wrong, and overlay operations either fail or produce nonsense.
- Unclosed rings. The first and last positions differ. Many parsers will silently close the ring for you, which sounds helpful until the closing segment cuts across the shape.
- Ring orientation. Conventions differ on whether outer rings run clockwise or counterclockwise, with inner rings running the other way. Formats and standards do not all agree, and a polygon whose rings are wound the wrong way may render as a hole rather than a shape, or fail containment tests.
- Holes outside the shell, or holes overlapping each other. Structurally impossible, occasionally present, and usually the result of an automated process that assembled rings without checking their relationships.
- Duplicate consecutive vertices and zero-length segments. Harmless in rendering, awkward in geometric algorithms, and a frequent cause of division by zero in code that computes angles or bearings.
- Spikes. A single vertex far outside the rest of the shape, typically from a coordinate with a dropped digit or a sign error. A spike has almost no effect on area but destroys the bounding box, which destroys index performance for every query that touches the layer.
What breaks is worth being specific about. Overlay operations such as intersection and difference are the most sensitive, and they fail on invalid input in ways that produce empty results rather than errors. Area and length computations return numbers rather than failing, so an invalid polygon silently contributes a wrong figure to an aggregate. Spatial indexes degrade rather than break, so the symptom is a slow query rather than a wrong answer.
Repairing invalid geometry is possible and mostly automated, but repair is a decision, not a fix. A self-intersecting polygon can be repaired into several polygons or into one with a different area. Which repair is correct depends on what the shape was meant to be, and an automatic repair applied at load time without logging means nobody knows which features were changed.
Simplification trades precision away on purpose
Simplification removes vertices while attempting to preserve shape. It is unavoidable at scale: a boundary digitised at survey precision may carry tens of thousands of vertices, and rendering or joining against it at country scale wastes almost all of that detail.
The standard algorithms work by tolerance. A vertex is removed if doing so moves the line by less than a specified distance. Set the tolerance to a metre and city-scale detail survives. Set it to a kilometre and the coastline becomes a polygon with a dozen corners.
What simplification destroys is worth enumerating, because the shape still looks broadly right afterwards.
Small features disappear entirely. Islands smaller than the tolerance vanish. Narrow inlets close up. A parcel narrower than the tolerance collapses.
Topology breaks. Simplifying two adjacent polygons independently moves their shared boundary in two different directions, opening gaps and overlaps along a boundary that was previously exact. Topology-preserving simplification exists and is what should be used whenever the layer is meant to be a partition, but it is not the default in most tools.
Validity breaks. Aggressive simplification on a convoluted shape can pull a boundary across itself, producing a self-intersection where none existed.
Area and length change. Simplified boundaries are shorter, and simplified polygons have different areas. If measurements are taken from a simplified layer and compared against measurements from the original, the difference is systematic rather than random.
Containment changes near the edge. Points that were just inside can end up just outside. For any point-in-polygon analysis, simplification tolerance sets the width of the band in which results are unreliable.
The discipline is to simplify for display and measure on the original. Two versions of a layer, one for rendering and one for analysis, is not redundancy, it is the correct architecture.
Scale-dependent representation
A related idea is that the right primitive changes with scale, and a serious dataset holds more than one representation of the same thing.
At national scale a city is a point. At regional scale it is an outline. At street scale it is a set of blocks, and the individual buildings within them become the meaningful objects. A river is a line on a small-scale map and a polygon on a large-scale one. An airport is a point in a route network, a polygon in a land-use map, and a detailed set of lines and polygons in an operational one.
None of these is a simplification of the others in the sense that a tolerance could produce them. They are different models chosen for different questions, and the transitions between them are editorial decisions about what matters at each scale.
This has two practical implications. First, a dataset built for one scale will disappoint at another, and the disappointment is not a data quality problem but a scope mismatch. Second, any pipeline that mixes layers built at different scales is joining representations that were never meant to align, and the misalignment shows up as boundary disagreement rather than as an obvious error.
The rule that saves the most trouble
Choose the primitive that matches the smallest question the data will ever be asked, not the question in front of you today.
Downgrading is free and reversible in practice: footprints reduce to points, polygons reduce to centroids, networks reduce to counts. Upgrading is not possible at all. A points table with no footprints cannot answer an area question, and the only fix is to source the footprints, which means the original decision was not a modelling choice but a deferred acquisition cost.
Where the richer representation genuinely cannot be obtained, the honest response is to record why. A shop stored as a point because no footprint data exists for the region is a different situation from a shop stored as a point because points were sufficient at the time, and only the first one tells a future reader that the limitation is in the world rather than in the schema.