How We Built an Interactive Dashboard from 369K City of LA Service Requests

Every major city in the United States publishes open data. Service requests, permit applications, crime reports, traffic counts, budget allocations. It is all sitting there, free to access, updated regularly, and almost entirely ignored by the private sector.

Most businesses treat open data the way they treat a library card: they know it exists, they vaguely appreciate it, and they never actually use it. That is a missed opportunity. Public datasets are some of the richest, most consistent sources of operational data available, and they can inform everything from site selection to competitive analysis to resource planning.

We built the LA 311 Dashboard to demonstrate what is possible when you treat public data like a real analytics project. Not a toy demo, not a proof of concept, but a fully interactive dashboard with charts, maps, and findings that tell a meaningful story. Here is how we did it.

The Data Source

The City of Los Angeles operates one of the better open data portals in the country, powered by Socrata (SODA). Among its many datasets is MyLA311, the city's centralized system for non-emergency service requests. When a resident calls 311 to report a pothole, request a bulky item pickup, or flag illegal dumping, that request enters the MyLA311 system and eventually lands in the open data portal.

The dataset we worked with contains roughly 369,000 records. Each record includes the request type (bulky items, graffiti removal, electronic waste, and dozens more), the creation date and close date, the status of the request, geographic coordinates, the council district, and the neighborhood council. That is a surprisingly rich set of dimensions for a free public dataset.

What makes the SODA API particularly useful for analytics work is its support for server-side aggregation. You do not have to download all 369K rows and process them locally. The API supports SQL-like query parameters including $select, $group, $where, and functions like date_trunc_y() for date grouping. This means you can ask the API to do the heavy lifting and return only the summarized results you need.

The Problem with Raw Open Data

It would be nice if you could just point a charting library at the API and get a dashboard. In practice, that never works. Even "clean" government data has issues that surface the moment you try to build something production-grade on top of it.

The raw API returns 369,000 rows of JSON. Sending that payload to a browser is not viable. Even if you could transfer it quickly, no front-end charting library handles that volume gracefully. You would be looking at multi-second render times, frozen UIs, and a terrible user experience.

Beyond the volume problem, the data itself needs work. Some records have null or zero-value coordinates, which means they cannot be placed on a map. Categories are inconsistent: the same type of request might appear under slightly different labels depending on when it was entered or which department processed it. Duplicate entries exist where the same request was logged more than once. Date fields sometimes contain unexpected values that break standard parsing.

None of these issues are unique to LA or to 311 data. They show up in virtually every real-world dataset, public or private. This is exactly why data engineering matters even when the source data appears clean at first glance. The gap between "data exists" and "data is dashboard-ready" is where most projects stall.

Our Approach: Pre-Computed Aggregations

Instead of fetching raw data at runtime, we wrote a build-time script that makes roughly 15 targeted API calls using SODA's aggregation features. Each call answers a specific question: how many requests per type? What is the monthly trend? Which council districts have the highest volume? What is the average resolution time by category?

Each API call uses $select and $group to let the server compute the aggregation. The response is a small JSON payload, typically under 5KB. We process these results in the build script, clean up any formatting inconsistencies, handle edge cases like null values, and write the final data to static JSON files that get committed alongside the rest of the codebase.

The result is a dashboard that loads instantly. There are no runtime API calls, no loading spinners, no risk of the upstream data source being slow or unavailable. The static JSON files are served from the same CDN as the rest of the site. First meaningful paint happens in milliseconds, and every chart renders immediately because the data is already in the bundle.

This approach also solves the reliability problem. Open data portals go down for maintenance. API rate limits can throttle requests during peak usage. By pre-computing everything at build time, we decouple the dashboard's availability from the upstream data source. The dashboard works even if the City of LA portal is offline. You can explore the live result on our LA 311 Dashboard.

What the Data Told Us

Once the dashboard was built, the data started telling a clear story. This is the part that matters most to us as consultants. Raw numbers and charts are useful, but the real value is in the narrative they support and the decisions they can drive.

Bulky Items dominate everything. Bulky item pickup requests account for approximately 45% of all 311 service requests in the dataset. That is not a plurality; it is near majority. If you are a city planner or waste management operator looking at this data, your number one priority should be optimizing the bulky item collection workflow. No other category comes close.

Council District 13 leads in request volume. This district, which covers parts of Hollywood, Silver Lake, and Echo Park, consistently generates more 311 requests than any other district. The reasons are likely a combination of population density, housing type mix, and active community reporting. For businesses evaluating service areas or real estate opportunities, this kind of district-level analysis provides concrete, data-backed context.

Resolution times vary wildly by request type. The overall average resolution time sits around 14 days, but that number hides enormous variation. Some request types get resolved within a day or two. Others take weeks. Understanding these differences matters for anyone managing similar operational workflows. If your average resolution time looks fine but certain categories are quietly taking three or four times longer, you have a problem hiding in the aggregate.

Geographic hotspots cluster in specific neighborhoods. The interactive map on the dashboard makes it immediately obvious that service requests are not evenly distributed. Certain neighborhoods generate far more activity than others, and the patterns are persistent over time. This kind of spatial analysis is what turns a good dashboard into a strategic planning tool.

These findings are not buried in a spreadsheet somewhere. They are visible the moment you open the dashboard, which is the entire point. Data storytelling is the consulting value-add. Anyone can pull numbers from an API. The question is whether those numbers change how someone thinks or acts.

The Visualization Stack

We chose our tools based on three criteria: performance, developer experience, and bundle size. A dashboard that takes five seconds to load has already lost most of its audience.

Recharts handles all of the chart components: bar charts, line charts, and pie charts. Recharts is a React-native charting library built on top of D3, which means it composes naturally with the rest of our component architecture. It is lightweight compared to alternatives like Chart.js or Highcharts, and it supports responsive containers out of the box. The trade-off is that it is less flexible than raw D3 for highly custom visualizations, but for standard chart types it is excellent.

Mapbox GL JS powers the interactive map. We lazy load the map component to keep the initial page bundle small. The map only initializes when the user scrolls to that section of the dashboard. Mapbox uses WebGL for rendering, so it handles the density of our geographic data smoothly even on mid-range devices. We chose Mapbox over alternatives for the same reasons we outlined in our Esri vs Custom Mapping comparison: full design control, modern developer experience, and no vendor lock-in.

Next.js ties everything together with static generation. Because all of our data is pre-computed at build time, the entire dashboard is a static page. No server-side rendering, no API routes, no database connections. The page is generated once during the build process and served as static HTML with hydrated React components. This gives us the best possible performance profile and the simplest possible deployment story.

Lessons for Your Business

You do not need to work with government data to apply the patterns behind this dashboard. The architecture and approach translate directly to any business with operational data.

If your company handles support tickets, you have data that looks a lot like 311 requests: categories, timestamps, resolution status, assignees, and maybe geographic information. The same pre-computation approach works. Instead of querying your ticketing system in real time every time someone opens a dashboard, aggregate the key metrics on a schedule, store the results as lightweight data files or cached database views, and serve them instantly.

The same pattern applies to order data, service calls, field operations, fleet management, or any workflow that generates timestamped, categorized records. The specifics change but the principles stay the same: pre-compute what you can, visualize what matters, and tell the story that drives action.

We wrote about this approach in more detail in our 6-step system for building dashboards that actually get used. The LA 311 Dashboard follows that exact framework: start with the decisions the dashboard needs to support, work backward to the data requirements, and only then pick the tools. Too many dashboard projects start with the tool and hope the insight follows.

If you are exploring whether your business data could support this kind of analysis, our data engineering services cover exactly this: ingesting messy operational data, building reliable pipelines, and delivering clean, aggregated outputs that power dashboards and reports.

See It in Action

The best way to understand what this dashboard does is to use it. Explore the live LA 311 Dashboard and click through the charts, filter by request type, and explore the map. Every data point comes from a real service request filed by a real LA resident.

If you look at that dashboard and start thinking about what a similar view of your own business data would look like, that is exactly the reaction we are going for. We offer a free 30-minute consultation where we can talk through your data, your goals, and whether a project like this makes sense for your situation. No pitch decks, no pressure. Just a conversation about what is possible. Book a free consultation and let us take a look.