Working With Public 911 Call Logs From Sioux Falls
Southeastern Regional Communications Center (SENRAC) handles 911 dispatch for Sioux Falls and some surrounding area. They publish call logs, but getting usable data out of them requires knowing where to look and what questions to ask. The log files are not going to hand you anything clean. You pull them, then you do the work. Sioux Falls publishes annual and sometimes quarterly call data through their open data portal and through public records requests to SENRAC. The raw format is typically a CSV or spreadsheet extracted from their CAD system, usually handled by Motorola Solutions or a similar provider. The fields you will see include timestamp, call type, location, dispatch time, arrival time, and disposition. That last field is where most of your analysis actually happens. The first thing I learned the hard way is that call type codes change over time. Around 2019-2020 there was a transition period where several NEMSIX code categories got remapped. If you are comparing 2018 data against 2021 data without checking what changed, your numbers are going to look wrong. I caught this once when I thought domestic violence calls had dropped 40% year over year. They had not dropped. They had just been recategorized under a different code in the new system. I spent three days cross-referencing the old and new code lists before I could trust any trend line.
For the actual download process, start at the City of Sioux Falls open data portal at data.siouxfalls.org. Search for "911" or "emergency calls." You will find datasets that go back to roughly 2016. Some are updated monthly, some annually. The file sizes range from about 5 megabytes for a single month to over 80 megabytes for an annual dump covering all call types. Export as CSV. Do not use the spreadsheet viewer built into the portal if you can avoid it. It strips leading zeros from addresses and sometimes truncates notes fields. I have lost more records to that than I care to admit. Once you have the file, the real work begins. The timestamps are in local time, which matters because South Dakota observes daylight saving time. Every spring and fall you will see a gap or a duplicate hour in the data. If you are doing hourly trend analysis, you have to account for that manually. There is no automatic fix built into most CSV exports. The disposition codes are the most important and the most confusing part. Standard codes include things like "Dispatched," "Assigned," "Cancelled," and "No Emergency." But each agency adds its own modifiers. A call marked "Dispatched" could mean the unit showed up and did nothing, or it could mean the unit responded and made an arrest. The CAD system captures both, but the published log often flattens them into the same line item. I recommend pulling the full raw log from a public records request if the open data portal version is too compressed for your needs. The request goes to SENRAC, and under South Dakota Codified Laws Chapter 1-26-1 through 1-26-6, they are generally required to provide public safety records, though they do withhold certain details like officer names and active investigation info.
I ran into a specific edge case recently where the geocoding on address fields was inconsistent across quarters. Some records had full street addresses, others had just intersection names, and a small percentage had nothing but a GPS coordinate in a notes field. I wrote a simple Python script using the geopy library with the Nominatim reverse geocoder to match the coordinates back to addresses. It recovered about 94% of the nulls. The remaining 6% were in rural areas outside standard geocoding coverage, and those had to be handled manually by looking up parcel records through Minnehaha County's GIS system. For analysis, I usually start by filtering on a few key columns. Call type is the obvious one. I also filter on response time buckets — under 5 minutes, 5 to 10, over 10 — because that tells you where the system is working and where it is not. Geographic clustering on address or GPS data reveals hotspot patterns that are useful for understanding resource allocation. I use Python with pandas for cleaning and grouping, then export to a visualization tool. Gaps in the data tend to cluster around system migrations and holidays, which is worth noting before you present anything to an audience. There are limitations you need to be honest about. The data does not include caller identity. It does not include unit assignment beyond the general type, like "rescue" or "patrol." It does not include the outcome of interventions. It is a dispatch log, not a case file. If you are making claims about clearance rates or conviction outcomes from this data, you are making claims the data cannot support. Pair it with arrest or incident reports if you need that level of detail, and those come from a completely different release schedule and request process.
Get the Full Details
Another issue is the delay. Annual reports sometimes lag 6 to 12 months behind the actual calendar year. Real-time dashboards exist but they are rough summaries, not detailed logs. If you need current data for operational purposes, the open portal will not get you there fast enough. You file a separate records request and expect a turnaround measured in weeks, not days. For most people digging into this data, the takeaway is straightforward. Pull the CSV. Check the code mapping for your time range. Clean the timestamps around DST transitions. Reconcile the address fields. Filter by response time and call type. Don't claim more than the fields can support. The Sioux Falls system is well-maintained and relatively transparent compared to many jurisdictions, but transparency does not equal usability. You still have to do the legwork.
