Chapter 2: Vector Data Structures and Topology#

Think of a digital map of your city. Behind every road, building, and park is a clever system for storing locations and relationships. In this chapter, we’ll see how vector GIS uses points, lines, and polygons to represent the world, and how topological rules keep those features connected and consistent.

The Big Picture#

When you look at a map, you see separate things: a street, a fire hydrant, a lake. Vector GIS captures these things by breaking them down into a few simple shapes. But raw shapes aren’t enough—roads must meet at intersections, counties must share borders without gaps, and we need to attach names and attributes to everything. This chapter answers two big questions: how do we store those shapes in a computer, and what invisible rules let the computer understand how the shapes relate to each other? Getting these basics right makes editing reliable, analysis powerful, and maps meaningful.

Geometric Primitives: Points, Lines, and Polygons#

Vector GIS reduces nearly everything you see on a map to three building-block shapes: points, lines, and polygons. Think of them as the nouns of geographic language.

Point: A zero-dimensional geometry defined by a single coordinate pair . It has no length or area.

A point is the simplest feature—a single location. A weather station, a tree, a bus stop, or the peak of a mountain are all stored as points. On the screen, a point might be drawn as a tiny dot or a symbol, but underneath it is just one pair of numbers.

Line (or polyline): A one-dimensional geometry consisting of an ordered list of connected straight segments. It has length but no area.

Lines record paths. A hiking trail, a river centerline, a power line, or a street are all lines. Even when a feature curves gently, the computer stores it as a series of short, straight segments—a polyline. The more segments you give it, the smoother the curve looks, but it is always a chain of vertices.

Polygon: A two-dimensional geometry formed by a closed ring of line segments that encloses an area. It has both area and perimeter.

Polygons represent things that cover a patch of ground: a lake, a building footprint, a county, a forest stand. To be valid, a polygon’s ring must close back on itself, creating an inside and an outside. Polygons can also have holes—a doughnut‑shaped park with a pond in the middle, stored as an outer ring and an inner ring.

These primitives fit naturally into a simple table:

All vector data is ultimately a collection of these three types. Every mountain, sidewalk, and voting district is made of the same few Lego pieces.

📝 Section Recap: Points mark single spots, lines trace paths, and polygons enclose areas. Together they are the basic vocabulary of vector GIS, no matter how complex the landscape looks.

Nodes, Vertices, and the Impact of Map Scale#

Points, lines, and polygons are built from lists of coordinates—but not all coordinates do the same job. Let’s look at two important terms.

Vertex: Any coordinate point that helps define the shape of a line or polygon boundary. A line is made of a string of vertices.

Node: A vertex with a special job—it marks the endpoint of a line or a junction where two or more lines meet.

Imagine a winding country road. The GIS stores its centerline as a polyline with dozens of vertices tracing every bend. At each end of the road, where it joins another road, we place a node. At a four‑way intersection, that single node belongs to all four street segments, telling the computer they share a connection. Vertices give a feature its shape; nodes give it its relationships.

Now, how do we decide whether to store something as a point, a line, or a polygon? That choice depends on map scale—the ratio between distance on the map and distance on the ground. Scale completely changes how we represent a feature.

Think of a city. On a globe or a small‑scale map of an entire country (say 1:10,000,000), a city is too small to show its detailed shape; it appears as a dot—a point. Zoom in to a large‑scale city map (1:10,000), and suddenly that dot unfolds into a polygon with a detailed boundary. A river behaves the same way: on a state map it’s a thin line, but on a local planning map it becomes a wide polygon with real banks.

This isn’t a minor detail—it affects how we store the data and what analyses we can do. If a city is stored as a point, you can’t ask for the population density of its neighborhoods; you need a polygon for that. Scale dictates whether a feature is represented as a point, a line, or a polygon, and good GIS design keeps that trade‑off in mind from the start.

📝 Section Recap: Vertices shape lines and polygons; nodes anchor them at ends and intersections. Map scale determines whether we capture a feature as a point, a line, or a polygon—the same real‑world object can change its geometric type depending on how much detail we need.

Topological Rules: Connectivity, Adjacency, and Containment#

Coordinates and shapes alone don’t tell the whole story. If two counties share a border but the digital line is stored twice—once for each county—tiny slivers or overlaps can creep in. Topology solves this by explicitly storing relationships between features.

Topology: A set of rules and linked data structures that keep track of spatial relationships—like connectivity, adjacency, and containment—no matter the exact coordinates.

Think of a subway map. The map is geometrically simplified—distances are stretched, curves are straightened—but you can still tell exactly which stations are connected and which line is next to which. That’s topology at work: the essential relationships survive, even when detailed coordinates are less precise.

Three relationship types form the backbone of vector topology:

• Connectivity: Lines are connected if they share a node. In a road network, every street segment ends at a node that is shared with the streets it meets. If you drive along one segment, the computer knows which segments you can turn onto, because connectivity is stored explicitly. This lets you trace a route from A to B without having to guess whether two lines are supposed to touch.

• Adjacency: Polygons are adjacent if they share a common boundary. Topology stores that boundary only once, as a shared edge. The system records that “polygon A lies on the left side of this edge and polygon B lies on the right.” If you later move the edge to fix a surveying error, both polygons update together—no gaps or overlaps appear.

• Containment: One polygon can sit completely inside another. A country contains states, a forest contains a clearing, a lake contains an island. Topology tracks which features nest inside which, so queries like “find all parks inside this city boundary” work instantly.

Without topological rules, a vector dataset is just a bag of disconnected shapes. A line that is supposed to meet a node might fall a millimeter short, breaking network analysis. Adjacent polygons might drift apart, creating tiny empty spaces—slivers—that ruin area calculations. Topology acts like a digital plumbing system that snaps everything together and keeps it tight.

📝 Section Recap: Topology stores how features connect (through shared nodes), how they touch (through shared edges), and how they sit inside one another. These rules turn a jumble of coordinates into a clean, analyzable map.

The TIGER Data Structure: 0‑Cells, 1‑Cells, and 2‑Cells#

One neat way to put topology into practice is the TIGER (Topologically Integrated Geographic Encoding and Referencing) data structure, first made by the U.S. Census Bureau. It builds a whole map from three levels of simple parts, each pointing to the others in a clear order. The names come from geometry: 0‑cells are points, 1‑cells are edges, 2‑cells are area polygons. But every piece carries clear topological links.

0‑cell: A geometric point that acts as a topological node. Each 0‑cell stores its coordinates and a list of all 1‑cells that start or end there.

A street intersection is a 0‑cell. It “knows” which road segments feed into it. That is pure connectivity.

1‑cell: A directed edge connecting two 0‑cells. A 1‑cell has an ordered string of vertices to define its shape, but only its start and end points are 0‑cells. Crucially, it also records which polygon lies on its left side and which on its right.

In TIGER, every interior road segment, creek, or parcel boundary is a 1‑cell. Because the 1‑cell knows its left and right polygons, adjacency is built right into the edge—there is no separate record of the border stored with each polygon.

2‑cell: A polygon formed by a closed loop of 1‑cells. A 2‑cell may have holes (an inner ring of 1‑cells) and can contain other 2‑cells.

A city block, a census tract, or a lake is a 2‑cell. Its boundary is not stored as a separate ring of coordinates; instead it is defined by the chain of 1‑cells that make up its perimeter. If the boundary is shared with the neighboring block, the same 1‑cell appears in both, but only once in the data.

Let’s walk through a tiny mental model. Picture a square city block. Its four corners are 0‑cells (A, B, C, D). The four sides are 1‑cells: AB, BC, CD, DA. Each 1‑cell knows that the block polygon lies on one side (say, left) and the street right‑of‑way polygon lies on the other. The block itself is a 2‑cell composed of those four 1‑cells. Now imagine we subdivide the block diagonally. We add a new 1‑cell from A to C, which splits the single 2‑cell into two new 2‑cells. The diagonal 1‑cell records that polygon 1 is on its left and polygon 2 is on its right. No coordinates were duplicated; the topology kept everything consistent.

This hierarchical design makes queries like “find all streets that border this census tract” extremely efficient—just follow the 2‑cell → 1‑cell → 0‑cell links. It also makes editing safer: moving a 0‑cell automatically updates all connected 1‑cells and the polygons they bound.

📝 Section Recap: The TIGER data structure uses 0‑cells (points/nodes), 1‑cells (directed edges with left/right polygon info), and 2‑cells (area polygons) to store geometry and topology in a clean, integrated way. Every spatial relationship is coded directly into the data, eliminating duplication and reducing errors.

Attribute Tables: Storing Non‑Spatial Data#

Shapes and topology give us the where. But a map of roads is only useful if we know their names, speed limits, and surface types. That’s where attribute tables come in.

Attribute Table: A database table in which each row corresponds to one map feature, and each column stores a descriptive characteristic—an attribute—of that feature.

Think of it as a spreadsheet glued to your map. Each point, line, or polygon in your vector layer gets its own row. The table always includes a special column that holds the geometry (often called Shape or Geometry) and a unique identifier (like FeatureID). The other columns hold whatever you need: a city’s population, a parcel’s owner, a river’s length, a street’s address range.

A simple attribute table for a roads layer might look like this:

When you click on Main Street in a GIS viewer, the software looks up row 1 and can display “Name: Main Street, Speed Limit: 55 mph.” When you run a query like “show all unpaved roads,” the system scans the Paved column and selects only Elm Lane, highlighting it on the map.

Attributes can be numbers, text strings, dates, or even true/false flags. They are the bridge between pure geometry and real‑world information. Without them, a vector map is a beautiful but mute drawing; with them, it becomes a question‑answering machine.

Attribute tables aren’t bolted on as an afterthought—they are part of the vector data model. Each feature carries its attributes alongside its coordinates and topological references, giving you a complete digital twin of the landscape.

📝 Section Recap: An attribute table links one row of descriptive data to every spatial feature, turning coordinates and topology into an interactive, queryable database. It is the “what” behind the “where.”

Summary#

We’ve traveled from simple dots to a full map brain. Vector GIS starts with three basic shapes—points, lines, and polygons—built from vertices and held together at nodes. Topology adds the rules of connectivity, adjacency, and containment, so the computer knows how features relate, not just where they sit. The TIGER data structure shows how those ideas can be wired together neatly with 0‑cells, 1‑cells, and 2‑cells. Finally, attribute tables fill all that geometry with the names, numbers, and categories that give a map its real‑world meaning. Master these basics, and you’ll see every digital map as a carefully organized conversation between shapes, relationships, and data.