Charts and Visualization

matplotlib is the original and most widely used plotting library in Python, and nearly everything else builds on it. You install it once (pip install matplotlib) and import its main module under a standard nickname:

import matplotlib.pyplot as plt

Every chart you make has the same two-part anatomy, and understanding it early saves confusion. The figure is the whole image - the canvas, the thing you save to a file. The axes are a single plot inside that figure - the area with the x and y scales where the data is actually drawn. A figure can hold one axes or several side by side. The clearest way to make a chart is to create both explicitly, draw on the axes, and then show or save the figure:

rooms = ["living", "kitchen", "bedroom", "study"]
areas = [24, 12, 15, 9]

fig, ax = plt.subplots()      # a figure with one axes
ax.bar(rooms, areas)          # draw the data on the axes
ax.set_ylabel("area (sqm)")
plt.show()                    # open a window to view it

plt.subplots() hands you the figure and the axes together, which is the modern, recommended way to start. You then call methods on ax to draw and label, and finish with plt.show() to view or savefig to write a file. Keep the figure-and-axes picture in mind and matplotlib's large menu of functions stops feeling random - almost all of them are just ways of drawing on, or labelling, an axes.

You will meet matplotlib written two ways online, and it helps to know why. The older style calls functions straight on plt - plt.bar(...), plt.title(...) - which quietly draws on whatever the current axes happens to be. It is fine for a quick one-off, but it gets confusing the moment you have more than one plot, because it is never quite clear which axes you are drawing on. The style this lesson uses - make fig, ax explicitly, then call ax.bar, ax.set_title - is a little more typing but far clearer, because every command names the axes it acts on. When you copy an example from the web that uses the plt.something style, you can almost always translate it by making a fig, ax and moving the drawing calls onto ax; the arguments stay the same.

You do not need matplotlib's full gallery; three chart types cover the overwhelming majority of design data. A bar chart compares a value across categories - areas by room, cost by trade, count by supplier - and is the one you will reach for most:

fig, ax = plt.subplots()
ax.bar(rooms, areas, color="#7C3AED")
ax.set_title("Room areas")
ax.set_ylabel("area (sqm)")

A line chart shows change over a continuous axis, almost always time - monthly energy use, cost tracked across revisions, temperature over a day:

months = ["Jan", "Feb", "Mar", "Apr", "May", "Jun"]
kwh = [820, 760, 910, 1180, 1520, 1680]

fig, ax = plt.subplots()
ax.plot(months, kwh, marker="o")
ax.set_title("Monthly electricity use")
ax.set_ylabel("kWh")

A pie chart shows parts of a whole - a budget split, an area breakdown by use - and works only when the slices genuinely sum to a meaningful total and there are few of them:

fig, ax = plt.subplots()
ax.pie([214000, 30000, 56000], labels=["rcc", "plaster", "finishes"], autopct="%1.0f%%")
ax.set_title("Cost by trade")

Match the chart to the question: comparing categories is a bar, change over time is a line, share of a total is a pie. Choosing the wrong type is the most common way a technically correct chart still misleads - a pie of twelve near-equal slices tells you nothing a bar would not have told you clearly.

A quick way to decide is to name the question in words first. If the sentence is how does X compare across these groups, it is a bar. If it is how does X change over time, it is a line. If it is what share of the total does each part take, and there are only a few parts, it is a pie - and even then a bar often reads more precisely, because people judge lengths far better than they judge the angles of pie slices. There are more specialised charts for other questions - a scatter plot for the relationship between two numbers, a histogram for the distribution of a single one - but for the everyday design data of areas, costs and quantities, the bar-line-pie trio does almost all the work. Master those three and label them well before reaching for anything fancier.

An unlabelled chart is not evidence, it is decoration - and a subtly mislabelled one is worse, because it persuades while being wrong. A few habits keep your charts honest and readable. Always give the axes and the chart a title and units, so a reader knows what they are looking at without asking:

fig, ax = plt.subplots()
ax.bar(rooms, areas, color="#0D9488")
ax.set_title("Room areas - Ground floor")
ax.set_xlabel("room")
ax.set_ylabel("area (square metres)")

The most important honesty rule for bar charts is to start the y-axis at zero. matplotlib usually does this for you, but if you override it, a bar chart that begins at 20 instead of 0 exaggerates small differences into dramatic ones - a classic way statistics mislead, and one you should never do to a client. Beyond that: rotate crowded x-labels so they stay readable (plt.xticks(rotation=45)), sort the bars so the ranking is obvious, and resist the urge to decorate - a clean chart with clear labels persuades more than a cluttered, colourful one. Because pandas is built to hand data to matplotlib, you can often skip straight from a DataFrame to a chart - by_trade.plot(kind="bar") plots a grouped Series directly - but whichever route you take, the labelling discipline is the same. The chart is making an argument on your behalf; label it so the argument is true.

Colour deserves the same restraint as scale. A single accent colour, used to pick out the one bar your point is about while the rest stay a neutral grey, communicates far more sharply than a rainbow where every bar shouts equally. If your charts sit in a report or a deck, reusing a small, consistent palette across all of them makes the whole document feel considered and lets a reader learn what a colour means once. And spare a thought for colour-blind readers, who are a meaningful share of any audience: never rely on colour alone to carry meaning - back it up with a label, a value printed on the bar, or ordering - so the chart still reads if the colours were stripped away. Honesty in a chart is not only about the numbers; it is about making sure the picture is legible to everyone who has to act on it.

A chart that only appears in a pop-up window is not much use; the payoff is a clean image file you drop into a report, a drawing sheet or a presentation. savefig writes the figure to disk, and a couple of arguments make the difference between a usable image and a fuzzy, badly-cropped one:

fig, ax = plt.subplots(figsize=(8, 4.5))
ax.bar(rooms, areas, color="#7C3AED")
ax.set_title("Room areas")
ax.set_ylabel("area (sqm)")

fig.savefig("room_areas.png", dpi=200, bbox_inches="tight")

figsize sets the size in inches, so you control the proportions before anything is drawn. dpi=200 makes it sharp enough to print or project - the default is often too low for a report. bbox_inches="tight" trims the wasteful whitespace matplotlib leaves around the plot, so labels are not clipped and the image sits neatly on a page. Save as .png for slides and screens; save as .pdf or .svg if you need a crisp vector that scales without pixelation on a large printed sheet.

One practical note when you generate many charts in a loop: call plt.close(fig) after saving each one, so matplotlib does not hold every figure in memory. With that, you can script a whole set of charts - one per floor, one per project - and write them all to a folder in a single run. That is the module's final leverage: not one chart made by hand, but a reporting pack regenerated on command every time the underlying schedule changes.

It is worth stepping back at the close of this module to see what you have assembled. You can read a table from a CSV or an Excel workbook, look at it critically with head() and info(), clean its gaps and types and inconsistent labels on purpose, compute the areas, quantities and costs your work actually reports, collapse hundreds of line items into subtotals with groupby, write the result back to a file colleagues can open, and turn any of those numbers into an honest chart saved for a report. That is a complete data workflow - the same one used, in richer forms, across data science and the analysis-heavy corners of computational design. You do not need every function pandas and matplotlib offer; you need this arc, run confidently on your own real files. Everything from here is variation and depth on the moves you now have.