What the St Petersburg crime transparency project actually covers
The initiative published by the city's traffic and public safety department tracks reported incidents across seven categories: theft from vehicles, residential break-ins, assault, vandalism, fraud involving public transport, unauthorized sales, and disputes between individuals. The data refreshes once every twenty-four hours. You can filter by district, date range, and category. There are about eighty-five thousand active pins on the current public dashboard, and the map renders them in clusters that tighten as you zoom in. The project exists because the old system of printed monthly reports made it impossible to see trends in real time. Before the digital map launched in 2022, citizens and researchers had to request documents through the federal and wait forty-five days on average. The new portal gives you the same raw counts, just faster. That speed changed how local news outlets cover crime and how community groups allocate resources for neighborhood watches. It also introduced some problems the planners did not anticipate. I spent three weeks last winter trying to cross-reference these map entries with police dispatch logs from the Vasileostrovsky district. The timestamps on the map are rounded to the nearest hour, but the internal log entries use exact minutes. When I pulled a random sample of one hundred incidents, the map and the dispatch records disagreed on the time of occurrence for twenty-three of them. Most of those were cases where the initial call came in after midnight and was logged the next morning as part of a batch submission. The workaround was simple: I downloaded the CSV export, matched records by incident ID and location coordinates, and then used the district fire station's public call logs as a third data source to triangulate the correct timestamps. It took about twelve hours to clean the whole sample, but once the script ran, duplicates dropped to under four percent.
The download link is straightforward. On the main dashboard page, there is a button labeled "Export Data" in the upper right corner below the filter panel. Click it and the browser downloads a zip file containing a GeoJSON layer for spatial queries, a CSV with incident attributes, and a README that lists the field definitions in both Russian and English. The file is roughly 340 megabytes. If you try to open it in QGIS without first projecting it to EPSG:4326, the labels will be misaligned by about two hundred meters because the source layer uses a local St Petersburg grid that differs from WGS84 by a small but consistent offset. The fix is to reproject immediately after import, or to use the pre-projected version that the municipal team sometimes posts on their public GitHub mirror under the repo name spb-safety-data. Most people who look at this map assume it shows every crime that happened in the city. It does not. The portal only ingests incidents that respond to a citizen call or are recorded by a patrol officer during a scheduled shift. Events detected solely by closed-circuit cameras and processed through the municipal video analytics system are excluded unless a human operator manually flags them. That means certain types of property crime, particularly package thefts from apartment building entrances and bicycle thefts in courtyards, are systematically underrepresented. I noticed this gap when I compared the map's theft numbers against insurance claim data from Ingosstrakh for the same month. The insurance figures were roughly thirty percent higher for residential theft in the Krylovsky district. Another thing that trips people up is the aggregation level. The map displays incidents at the neighborhood level by default, but you can drill down to the block group. When you drill down past the block group, some cells show a single dot because the city applies a disclosure filter to protect sensitive locations. This is standard practice and it makes sense, but it also means you cannot use the raw map counts to estimate precise incidence rates for small areas without applying an adjustment factor. I built a quick R script that applies a simple Bayesian shrinkage estimator to the block-level counts, borrowing strength from neighboring blocks. The result smooths out the noise without erasing real hot spots. If you are doing academic work with this data, you should probably do the same rather than taking the raw counts at face value.
The dashboard also has a quarterly comparison view that lets you overlay the current period against the same quarter from the previous year. This feature caught a lot of attention when the 2024 summer quarter showed a noticeable drop in vehicle thefts compared to 2023. The official explanation pointed to increased camera coverage in parking garages and a new anti-theft registration requirement for electric scooters. The data supports that explanation, but the effect was not uniform. The decrease concentrated in the central districts near the Neva embankments and did not show up in the farther suburbs like Pulkovo. That spatial mismatch suggests the policy impacted opportunistic theft more than organized vehicle theft rings, which operate in different parts of the city and use different methods. If you want to build something on top of this dataset, start with the CSV. The GeoJSON is useful for visualization, but the CSV has cleaner text encoding and consistent date formats. I have seen a lot of people complain about encoding issues when they open the JSON directly in Excel. The CSV uses UTF-8 with no BOM, so you should import it with explicit encoding set. The fields you will use most often are incident_type, district_code, date_occurred, latitude, and longitude. The category_code field maps to a separate legend file that the municipal team maintains on the same export page. Keep that legend updated because they added a new code for cyber fraud in the spring of 2025 and the export file was not corrected for nearly six weeks. There is also a public API endpoint if you need to pull data programmatically instead of downloading bulk files. The endpoint is REST-based and returns JSON. Rate limiting is set at fifty requests per minute per IP address, which is generous enough for most research projects but tight if you are running a dashboard that updates every few minutes. I encountered that problem when I built a simple monitoring page for a community group in the Moskovsky district. The page refreshed every five minutes and hit the rate limit by midday. The solution was to cache the last thirty minutes of data on a local server and poll the API every two minutes instead. That dropped the request count by about eighty percent and kept the page responsive.
Get the Full Details
The biggest limitation of this transparency effort is also the one that matters most for policy decisions. The data is comprehensive within its own frame, but the frame itself has blind spots. Crimes that are resolved through informal mediation, incidents that victims choose not to report because they do not trust the process, and situations where officers classify an event as a dispute rather than a crime all disappear from the map. I spent two months tracking domestic violence restraining orders filed in the Petrogradsky district and cross-referencing them with the map's assault category. The overlap was less than sixty percent. Many of the non-overlapping cases were either mediated at the precinct level or reclassified by the responding officer. This does not mean the map is unreliable. It means the map measures what the system records, not what actually happens. Any analysis that treats the two as identical will produce misleading conclusions. For practical use, the map is still one of the better open public safety datasets in Russia. The file formats are standard, the export is free, and the documentation is adequate if you read the Russian version rather than relying on the English translation. The English version has a few outdated field descriptions and misspells the district names. I always check the original Russian README when I need precise terminology. The download link stays on the same page as the interactive map. Look for the export button near the top right, select your filters first, and then click. The file usually generates within thirty seconds. If it takes longer, the server is likely busy and you should wait a minute and retry. I recommend starting with a small geographic area and a single category before you attempt city-wide analysis. The processing time and memory requirements scale linearly with the number of incidents, and the patterns become much clearer when you focus on one district at a time. I learned that the hard way during my first attempt, where I loaded the entire dataset into a spreadsheet and then lost two hours watching it crash while trying to filter by date range. A proper database or a dedicated GIS tool handles the full dataset fine, but a spreadsheet does not. The lesson was immediate and expensive in terms of time.
There is no subscription fee, no registration wall, and no paid tier for the data. The municipal government hosts the platform, and the funding comes from the city budget line for public safety modernization. If you are planning a long-term project that requires continuous access, I suggest setting up a local backup schedule. The export files are large enough that downloading them weekly is manageable, and it protects you against any temporary outage or schema change that the city announces without much notice. They updated the field structure once in 2024 and the old API endpoint broke for about eight hours before the new one went live. A local backup meant I could keep working while the city fixed the issue. The portal also publishes an annual summary report in PDF format, which gives aggregate numbers and compares the year against the previous five years. The report is useful for context but slow to appear. The 2024 report came out in March 2025, roughly fourteen months after the data ended. If you need recent year-over-year comparisons, use the dashboard's quarterly feature instead of waiting for the PDF. Data transparency in this space is valuable even with its gaps. The St Petersburg Crime Map gives residents, researchers, and journalists a level of detail that was unavailable a decade ago. The trade-off is that raw visibility without careful methodological awareness can create a false sense of completeness. The map shows you where the system knows something happened. It does not show you where the system does not know. Recognizing that difference is what separates useful analysis from confident but wrong conclusions. Use the tools available, check the metadata, and verify small samples against local sources before you generalize. The data is good enough for most purposes if you treat it as a record of documented incidents rather than a complete picture of urban safety.
