Reading the Sioux Falls Police Log Like a Person Who Actually Does It
Sioux Falls makes its police log available through the city's public records portal, and if you're just scrolling through it on a Sunday morning, you're probably walking away with a wildly skewed impression of what's happening in the city. The raw log is a feed of incident reports—arrests, warrants, traffic stops, disorder calls—and it looks like chaos until you realize you're supposed to be treating it like a dataset rather than a horror story. I've spent enough weekends parsing these logs to know where people trip up, and the biggest one is reading individual entries as representative when they're actually noise. The actual workflow starts with getting the data out of whatever format the city uses. Sioux Falls posts these logs as HTML tables on their website, which means if you want to do anything beyond eyeballing, you're either copying and pasting into a spreadsheet or writing a quick script to scrape the pages. I use a simple Python script with BeautifulSoup and pandas—takes about ten minutes to set up and then you can pull months of data in under a minute. The city updates the log daily, usually within a few hours of midnight, so if you're tracking something time-sensitive, don't check before 3 AM or you'll be staring at yesterday's data. Once you have the raw export, the columns that matter are date, time, location, charge or offense type, and whether the person was booked or cited. Everything else is flavor text. The first thing I always do is normalize the offense descriptions because the city doesn't use consistent terminology across entries. One day it's "Larceny," the next it's "Theft," and sometimes it's just a statute number with no human-readable label. I keep a mapping spreadsheet that I update whenever I notice a new variation, and it's saved me from accidentally counting the same offense type three different ways.
When I actually look for trends, I break things down by month and by category. The patterns that show up consistently are pretty unremarkable: more property crime in the winter when people are inside and things are easier to break into, a spike in disorder and DUI calls around holiday weekends, and a chronic background level of theft from vehicles that never seems to budge regardless of what the city does. What doesn't show up clearly in the log is the actual severity distribution because the log doesn't rate offenses. A shoplifting and a aggravated assault might sit next to each other with equal visual weight, which distorts how you read the data if you're not filtering first. Here's something most people miss: the police log only captures incidents where law enforcement responded and generated a report. It does not capture solved crimes, closed cases, or anything that was reported and then dropped. That means if you're trying to calculate crime rates, you're actually looking at reporting rates, which is a different metric entirely. A drop in logged incidents could mean fewer crimes happened, or it could mean people stopped bothering to report them. I ran into this when I was tracking a supposed decline in burglary around 2023 and double-checked against the Minnehaha County Sheriff's incident data, and the numbers didn't move nearly as much as the police log suggested. The gap was almost entirely in unreported residential break-ins. Another thing worth noting is the booking versus citation distinction. A lot of entries in the Sioux Falls log are citations that never led to arrest, and those skew the perception of serious crime if you don't separate them. I always filter for booked entries when I want to understand what's actually resulting in jail time, and I keep the citation data in a separate sheet for disposition tracking. The citation volume is actually useful for spotting trends in low-level enforcement priorities, but it's the wrong number to cite if someone asks you whether crime is up or down.
There are real bottlenecks with this approach that the city doesn't really advertise. The log has a date range limit on its search interface—you can only pull so many days at a time before the page times out or refuses to process the request. If you need a full year, you're looking at multiple queries. The export function, when it works, gives you CSV data but it's inconsistently formatted depending on which month you're pulling. Some months include supplemental columns for officer name or unit number, others don't, and that breaks any automated parsing you've built. I learned that the hard way when my script suddenly started throwing column count errors after I pulled October data following a stretch of perfectly clean monthly exports. The workaround I ended up using was to build the script to handle variable columns by mapping field positions rather than field names, then falling back to manual column assignment when the schema shifted. It adds about five minutes of setup each time the city changes something, but it keeps the pipeline running without me having to rewrite the whole thing. I also keep a local copy of every monthly export in a dated folder so if the online portal glitches—which happens more often than you'd think—you're not starting from zero. If you're looking for more complete statistics than the log provides, the South Dakota Uniform Crime Reporting program publishes annual data that includes clearer category definitions and comparison to prior years. It's not as granular as the daily log, but it corrects for the reporting bias that the police log inherently carries. I cross-reference both sources whenever I'm trying to make a claim about trends, and the discrepancies between them are usually where the actual story lives.
Get the Full Details
The log is also useless for understanding recidivism, case outcomes, or anything that happens after the initial arrest. I once spent two weeks trying to trace whether a handful of repeat offenders showing up in the log were actually the same people across different incidents, and the only way to do that reliably was to match names, dates of birth, and charge dates manually. The log doesn't include ID numbers or fingerprints, and name matching alone is unreliable in a city the size of Sioux Falls. There's no shortcut around that work if you need accuracy. One final practical note: if you're using this data for anything beyond personal interest—like a news article, a community presentation, or academic work—verify everything against the official annual report published by the Sioux Falls Police Department. The daily log is a snapshot tool, not a statistical one, and treating it like something it isn't will get your numbers wrong in ways that are hard to catch after the fact.
