Water Table Cards

Every card is generated by code from public map data and public records. No image generator drew a shoreline and no model wrote a number. Run the same inputs again and you get the same cards, line for line, and any change (a colour, a size, a different fact) is an edit to a file followed by a rebuild.

1. A list, pinned once

   The waters live in one plain list. Each is matched once to a permanent ID: a USGS National Hydrography Dataset feature, a Minnesota DNR lake number, or an OpenStreetMap ID outside the US. From then on nothing is looked up by name, so a second "Cedar Lake" can never sneak in.

2. Real shorelines

   Lakes are the surveyed polygons from the USGS National Hydrography Dataset. Rivers are the dataset's flowlines, merged and framed to a stretch worth drawing: a city reach clipped to its municipal boundary, or a confluence. Every response is cached, so rebuilding is offline and identical.

3. From map to paper

   Each shape is projected onto an equal-area map centred on that water, so it keeps its true proportions. Stray parts that share the name but sit miles away are dropped. The outline is then simplified with a tolerance tied to how much ground one printed point covers, keeping the islands that are still visible at that scale. Two passes of corner-cutting smoothing turn the leftover facets into a shoreline, and the result is fitted to the card as a vector path.

4. Neighbours and rivers

   Lakes in a chain, like the Minneapolis lakes, are drawn with their neighbours in a pale tint at one shared scale, so the set reads as a single map spread across the room. Rivers are drawn as a line, with tributaries thinner, the way a printed map thins streams by size.

5. Facts with receipts

   The back of each card is filled from source data: depth, clarity and fish surveys from the Minnesota DNR, the watershed and where its water ends up from the USGS Watershed Boundary Dataset, river flow from USGS stream gages, and shoreline length and island counts measured from the shape itself. Every value is stored with its unit, source, link and retrieval date. A few facts, like name origins and drinking water, were looked up by hand and are cited the same way. A missing value stops the build; nothing is filled in with a guess.

6. Design as data

   The palette was sampled from our printed invitation, and the typeface, letterspacing and layout are written as ratios of the card size in one theme file. Long names step down in size to fit. Changing a colour there changes every card, and the other wedding paper follows.

7. Out to print

   Cards are drawn as SVG and turned into a 5 × 7 inch duplex PDF, front and back, with margins that allow for printer drift. This page uses the same renderer, so what you see here is what printed.

Claude (an AI model) helped write and run the code, but it doesn't draw the cards or supply their facts: the map data and the public records do.