Checkpoint: From Raw Values to Visual Meaning

D3's first two boundaries now fit together: data preparation decides which values and relationships are available, while a selection and join decide which document elements represent them over time. This checkpoint connects those mechanisms to the rest of the pipeline so a reader can diagnose a graphic as a system. When a visualization misleads or fails, the useful question is not simply “which D3 function is wrong?” but “at which boundary did the data, identity, encoding, geometry, or rendering decision stop agreeing with the intended meaning?”

The value of this model is that it turns a sequence of familiar operations into a way of thinking. D3's modules can be composed in many orders, but they do not all perform the same kind of work. A transformation changes the values or structure available to the graphic. A join changes the correspondence between values and elements. An encoding changes how a value is represented. A renderer changes how that representation is produced for the browser. Confusing those categories makes a visual error hard to locate.

One pipeline, different kinds of change

Imagine a small display of transit delays by route and day. The raw records may contain one observation per vehicle or trip. Before any mark exists, the application might group the records by route and day, compute a summary, or place delays into intervals. That transformation changes the question the graphic can answer. A summary can make route-level comparison possible, while hiding the variation among individual trips. A binning operation can reveal distribution, while hiding the exact sequence of observations. Neither choice is a neutral prelude to drawing.

After preparation, the application must decide what each visual element represents. If a mark stands for a route, its identity should remain tied to that route when the data is resorted by delay. If a mark stands for one trip, the key must distinguish trips even when two trips share the same route. The join is where that decision becomes operational. Index matching follows position; key matching follows an identifier. The choice determines whether a later update is seen as a continuing mark or as a different entity occupying the same position.

Only then can a scale and shape give the selected values a visual form. A scale might map delay duration to vertical position, color, or size. A shape generator might turn those coordinates into a bar, a line, or another path. The renderer then places the result in SVG or Canvas. These stages are connected, but they are not interchangeable. Changing the aggregation is not the same as changing a color scheme. Changing a key is not the same as changing an axis. Changing SVG for Canvas is not the same as changing the data.

flowchart LR Q["Visual question"] --> T["Prepare values"] T --> I["Define identity and join"] I --> E["Choose visual encoding"] E --> G["Generate geometry"] G --> R["Render in SVG or Canvas"] R --> M["Inspect reader-facing meaning"] M -.->|"revise a boundary when meaning fails"| T

The feedback edge matters. A rendered mark can reveal that an aggregation has erased an important distinction, that two entities have been treated as one, or that a chosen encoding makes small differences appear larger than they are. D3's compositional design makes it possible to return to the relevant stage rather than applying a visual patch to the final output.