Keep Python Side Effects Easy to Trace While Utility Helpers Multiply

Suggested cover: a dashboard mid-section with KPI cards, a trend panel and a forecast handoff that all feel busy but still structured.

The middle of the dashboard is where the file starts speaking to humans

Once the bootstrap is complete and the filtered slice exists, the script can finally begin saying something useful to an operator. This is where many dashboards either become persuasive or start drifting into decorative noise. Metrics, trend charts and forecast cues may all look familiar, yet the interesting question is whether they are fed by a coherent slice of data and whether the visual rhythm helps a person reason about current conditions instead of merely admiring layout.

That is why these blocks matter so much. They are the portion of the file where database results, lightweight heuristics and visual composition all get translated into managerial language. Words like KPI row, trend panel and forecast handoff become useful here because the dashboard is no longer just computing values. It is constructing a story about the current road situation, the daily rhythm and the point where descriptive analytics begins leaning toward prediction.

This is also the part people screenshot, reference in meetings and remember during incidents. It deserves more than a thin caption and one lonely code block.

Interface term	Meaning	Why it matters here
KPI row	A compact set of headline values derived from the latest filtered record.	It gives the dashboard an immediate operational voice before deeper visuals appear.
Trend panel	The hourly line view and peak-hour note built from the same filtered slice.	It shows how traffic intensity changes across the day without leaving the current context.
Forecast handoff	The point where descriptive charts end and model evaluation begins.	It prepares the reader for the validation logic that follows in the next article.

The KPI row turns one filtered record into a quick planning view

            st.subheader("Current Status and Forecast")
            c1, c2, c3, c4, c5 = st.columns(5)
            c1.metric("Intensity", f"{int(last['intensity'])} veh/h")
            c2.metric("Avg. Speed", f"{last['avg_speed']:.0f} km/h")
            c3.metric("30 min Forecast", f"{int(last['intensity'] * 1.15)} veh")
            c4.metric("60 min Forecast", f"{int(last['intensity'] * 1.25)} veh")
            c5.metric("120 min Forecast", f"{int(last['intensity'] * 1.35)} veh")

This slice takes one recent row and stretches it into a quick planning view, which is exactly how many real dashboards earn attention from non-technical readers.

There is practical psychology in that row. People like seeing one current figure, one speed figure and then a few forward-looking estimates beside them. Even a lightweight forecast heuristic can help the page feel more decision-oriented, provided it stays visibly tied to the latest filtered observation.

The trend chart starts by grouping intensity into an hourly rhythm

            st.subheader("Traffic Analysis and Composition")
            col1, col2 = st.columns(2)
            hourly = df_filtered.groupby(df_filtered['report_hour'].dt.hour)['intensity'].mean().reset_index()
            hourly.columns = ['hour', 'Intensity']
            col1.plotly_chart(px.line(hourly, x='hour', y='Intensity', title="Traffic Load by Hour"),
                              use_container_width=True)

The line chart keeps the visual story attached to the same filtered dataframe, which helps the page feel explanatory rather than ornamental.

That matters because hourly grouping is where the dashboard starts showing shape instead of just totals. The operator can begin to see cadence, not merely volume.

Peak-hour notes and vehicle mix keep the visual layer grounded

            peak_hours = hourly.nlargest(3, 'Intensity')['hour'].tolist() 
            col1.info(f"Peak hours: {', '.join([f'{h}:00' for h in peak_hours])}")
            structure = df_filtered.groupby('vehicle_type')['intensity'].sum().reset_index()
            col2.plotly_chart(
                px.pie(structure, values='intensity', names='vehicle_type', title="Vehicle Mix", hole=0.4),
                use_container_width=True)

This slice adds just enough annotation and composition detail to keep the chart section from becoming anonymous.

The pairing is effective because it answers two different questions with one glance. The peak-hour note explains where the busiest moments cluster, while the pie chart explains what the traffic mix is made of.

The page opens a forecast section once the descriptive view is in place

            st.subheader("Forecast Model Evaluation")
           
            full_df = load_data()  
            if len(full_df) > 10:
                full_df['hour'] = pd.to_datetime(full_df['report_hour']).dt.hour
                train = full_df.iloc[:int(len(full_df) * 0.8)]
                test = full_df.iloc[int(len(full_df) * 0.8):]

The post closes right where the dashboard stops being purely descriptive and begins preparing a small validation run.

That is a satisfying handoff because it shows the code changing posture without changing data sources. The same history table that fed the charts is now about to feed the model check.

• This section ties together the KPI cards, chart preparation and the first validation-ready dataset.
• The code blocks keep one visual step at a time, so each dashboard layer stays legible.
• The article closes at the moment the page is ready to move from display into evaluation.

A dashboard starts sounding intelligent when its numbers, charts and validation cues all describe the same slice of reality.