{"$schema":"https://ejfox.com/schema/page-twin@1.json","kind":"blog_post","url":"https://ejfox.com/blog/2021/nypd-ccrb-complaint-clusters","json_url":"https://ejfox.com/blog/2021/nypd-ccrb-complaint-clusters.json","generator":"ejfox.com/json-twin@1","data":{"cacheVersion":"2026-05-13-gear-cards","html":"

Finding Clusters of NYPD Officers In CCRB Complaint Data

\n\n

Why?

\n

Complaints filed against police officers by the public are often the first and only warning sign that a cop might be on a course of escalating violence.

\n

In the deaths of George Floyd and Eric Garner their killers had a documented history of complaints filed against them. Unfortunately nothing was done to disrupt their pattern of abuse, and both cases ended in those officers killing members of the public they had sworn to protect.

\n

George Floyd

\n
\n

Chauvin, who was fired, has said through his attorney that his handling of Floyd’s arrest was a reasonable use of authorized force. But he was the subject of at least 22 complaints or internal investigations during his more than 19 years at the department, only one of which resulted in discipline. These new interviews show not only that he may have used excessive force in the past, but that he had used startlingly similar techniques.\n'That could have been me': The people Derek Chauvin choked before George Floyd

\n
\n

The officer convicted of murdering George Floyd had at least 22 complaints against him. The officer who put Eric Garner in a chokehold and killed him had 7 complaints filed against him.

\n

Eric Garner

\n
\n

Before he put Garner in the chokehold, the records show, he had seven disciplinary complaints and 14 individual allegations lodged against him. Four of those allegations were substantiated by an independent review board.\nThe disturbing secret history of the NYPD officer who killed Eric Garner

\n
\n

Of the 14 individual allegations against Garner's killer, 5 are for force: \"hit against inanimate object\", \"physical force\", and a single complaint in 2014 that would foreshadow the behavior that would eventually end the Officer's career: \"Force - Chokehold\".

\n

I am documenting my analysis in detail for a few reasons:

\n\n

Network visualization prior work / inspiration

\n

You may have seen network analysis like this before.

\n

Jacob Silver used it to look at the spread of anti-vax material.

\n

Adi Cohen has pioneered a method of combining Gephi with CrowdTangle to analyze the network of groups and pages sharing links.

\n

Provenance

\n

WNYC/Gothamist received the data in response to a Freedom of Information Law request and provided me an excel file for analysis.

\n

The Dataset

\n

Differences from data previously released by ProPublica

\n

ProPublica released and covered similar data in July of 2020.

\n

They chose to only publish data for \"active-duty officers who’ve had at least one allegation against them substantiated by the CCRB\".

\n

The dataset we are working with today contains every complaint and officer, even those with no substantiated allegations.

\n

It also contains officers who were listed as witnesses on complaints, including complaints found as \"unsubstantiated\" or \"unfounded\" by the CCRB.

\n

This makes it a \"noisier\" dataset. In our case this can be an advantage since we are looking to visualize the network of officers.

\n

Being named with another officer on a complaint, even if that complaint is unfounded, is a signal that those officers interacted in a way that was noticed by the public. Being the subject of an unfounded complaint together might even cause officers to form a tighter relationship. Because of that, I will incorporate witness data into our analysis.

\n

NYPD internal structure as it relates to our data

\n

The NYPD is divided into coverage areas within the 5 boroughs known as precincts. When I lived in Brooklyn, I lived in the 81st Precinct which covers Bed-Stuy.

\n

The NYPD also has a number of units, like the Warrant Squad or Narcotics that span different precincts. An officer might report to a numbered precinct, but their command is Brooklyn Narcotics, and they are interacting with other officers in their unit more than the precinct they work out of. Our data reflects this.

\n

Analysis

\n

Overview exploration / metadata

\n

The source dataset is an 81.2MB excel file that I received as FOIL2021-00167_Dataset.xlsx. It has 3 tabs. The first has some general notes1 about the dataset.

\n

The first tab has the title of OfficerAllegationHistory and has 181,627 entries and 472 columns.

\n

The second tab has the title of OfficersInvolvedInComplaints and has 239,608 entries and 183 columns.

\n

Analyzing our data with Datasette / SQLite

\n

Once we convert our CSV files into SQLite .db files we can use Datasette to get a sense of the data and slice off pieces for further analysis.

\n

The first thing we might want to look at is the top commands that received complaints since 2010.

\n
select [Officer Command At Incident], count([Officer Command At Incident]) from OfficerAllegationHistory\nwhere [Incident Date] BETWEEN '2010-01-01' AND '2010-12-31'\ngroup by [Officer Command At Incident] order by count([Officer Command At Incident]) DESC LIMIT 5
\n\n

Or the top 10 commands whose complaints ended in penalties.

\n
select [Officer Command At Incident], count([Officer Command At Incident]) from OfficerAllegationHistory\nwhere [Incident Date] BETWEEN '2010-01-01' AND '2021-12-31'AND [CCRB Allegation Disposition] = 'Substantiated (Charges)'\ngroup by [Officer Command At Incident] order by count([Officer Command At Incident]) DESC LIMIT 5
\n\n

After using Datasette to get a sense for the shape of our dataset, we can use it to filter out a slice of the data to use to feed into our next tool and begin doing our network analysis.

\n

Ian Johnson helped me explore the data a bit in Observable as well.

\n

We looked at when officers received complaints. Here each year is split into a bar. We are showing the officers who received the most complaints in the entire dataset.

\n\n

Or stacking the bars- the darker they are, the more recent the complaints occurred.

\n\n

You can also look at the CCRB outcomes and see how rarely cases are substantiated or end in discipline.

\n\n

We also looked at which commands received the most complaints across the entire dataset.

\n\n

Filtering out \"Exonerated\" and \"Unfounded\" complaints for our network

\n

To get our network closer to a representation of officers who are receiving complaints for misconduct we want to filter out any of the cases in which the officer was Exonerated or the CCRB's disposition was that it was Unfounded.

\n

So to get every complaint filed since 2010 that wasn't marked as exonerated or unfounded we'll write a query like

\n
select * from OfficerAllegationHistory\nwhere ([Incident Date] BETWEEN '2010-01-01' AND '2021-12-31') AND ([CCRB Allegation Disposition] IS NOT 'Exonerated'\nAND [CCRB Allegation Disposition] IS NOT 'Unfounded')
\n

Which gives us a slightly more manageable 65,401 rows. We'll save these results off as a .csv for further analysis.

\n

I had to do some funky stuff3 to fix the dates in SQLite, but once I did that, it was easy to filter by the date column.

\n

We can also export new CSVs for all of the incidents since 2010 for a particular precinct:

\n
select * from OfficerAllegationHistory\nwhere [Incident Date] BETWEEN '2010-01-01' AND '2021-12-31' AND [Officer Command At Incident] = '075 PCT'
\n

These precinct-specific slices are a bit smaller and more manageable for analysis in Observable.

\n

We'll also want to export another CSV with ONLY complaints that were substantiated

\n
select * from OfficerAllegationHistory\nwhere ([Incident Date] BETWEEN '2010-01-01' AND '2021-12-31') AND ([CCRB Allegation Disposition] IS 'Substantiated (Charges)' OR [CCRB Allegation Disposition] IS 'Substantiated (Command Discipline A)'\nOR [CCRB Allegation Disposition] IS 'Substantiated (Command Discipline B)'
\n

Analyzing our data with Neo4J

\n

I first encountered Neo4J when I was working with Ben Popken on an NBC News analysis of tweets tied to Senate Intelligence-identified Russian Twitter Bots where Neo4J provided analysts who were crucial to understanding the shape of our data.

\n

It is an incredibly useful tool for generating and analyzing networks, and I was excited to have another dataset that would let me use its considerable power.

\n\n

Importing our CSV with Cypher

\n

To import our .csv into a network of node and relationships in Neo4J, we will use the Cypher query language, which makes this process really easy and the code is relatively readable and easy to follow.

\n

Special thanks to David Allen at Neo4J for his guidance in writing queries and designing these relationships.

\n

Basically we take the CSV files we exported from Datasette (when we filtered our Exonerated, Unfounded, and everything before 2010) and go through every row and push it into our network.

\n
Creating officer nodes
\n

First we tell Neo4J to use officer.id as a unique constraint (this makes things faster, I think?) and create a node for each officer from one CSV.

\n
CREATE CONSTRAINT officerIdConstraint ON (officer:Officer) ASSERT officer.id IS UNIQUE
\n

Then I loop through every line of the .csv and create a new Officer node for every new officer I see. I use MERGE instead of CREATE to make sure I don't duplicate officer nodes.

\n
LOAD CSV WITH HEADERS FROM \"http://localhost:11001/project-185bb75c-b944-451a-9c0f-aeba860ae68a/OfficersInvolvedInComplaints_FILTERED-SINCE2010-NOT-UNFOUNDED-EXONERATED.csv\" AS csvLine\nMERGE (officer:Officer {id: csvLine.`Unique Officer Id`, lastName: csvLine.`Officer Last Name`, firstName: csvLine.`Officer First Name`, OfficersInvolvedInComplaints: true})\nRETURN officer
\n

This creates 29,915 unique officer nodes.

\n

Then we bind more data into it from our other CSV

\n
LOAD CSV WITH HEADERS FROM \"http://localhost:11001/project-185bb75c-b944-451a-9c0f-aeba860ae68a/OfficerAllegationHistory.csv\" AS csvLine\nMERGE (officer:Officer {id: csvLine.`Unique Officer Id`, lastName: csvLine.`Officer Last Name`, firstName: csvLine.`Officer First Name`, shieldNo: csvLine.`Shield No`, currentRank: csvLine.`Current Rank`, currentCommand: csvLine.`Current Command`, OfficerAllegationHistory: true})\nRETURN officer
\n

Now we have 113,265 unique officer nodes.

\n

An officer node looks like this:

\n
{\n  \"identity\": 00001,\n  \"properties\": {\n    \"currentRank\": \"Police Officer\",\n    \"currentCommand\": \"81\",\n    \"lastName\": \"Smith\",\n    \"firstName\": \"John\",\n    \"shieldNo\": \"00001\",\n    \"id\": \"000001\",\n    \"OfficerAllegationHistory\": true\n  }\n}
\n

Finally, we need to add a boolean to denote if an officer has ever had a charge substantiated. We'll use this later to please some lawyers. You'll see.

\n
LOAD CSV WITH HEADERS FROM \"http://localhost:11001/project-185bb75c-b944-451a-9c0f-aeba860ae68a/OfficerAllegationHistory_FILTERED-SINCE2010-SUBSTANTIATED.csv\" AS csvLine\nMERGE (officer:Officer {id: csvLine.`Unique Officer Id`})\nSET officer.ccrbSubstantiatedBool = \"true\"\nRETURN officer
\n

Now we've marked 4,768 of New York's ~36,000 (13%) finest as having a substantiated complaint in the last 10 years.

\n

Let's NOT do the same thing for OfficersInvolved - because that file contains officers who were merely witnesses to substantiated complaints, and we don't want to accidentally label a witness to a substantiated case.

\n

Creating officer labels

\n

Now we need to set labels for our nodes depending on whether they have ever had a complaint substantiated. We don't want to label nodes with names for any officers who may have complaints but have never had any substantiated. I have been told that lawyers think this is a good idea.

\n

First we set every officer label to their unique ID

\n
MATCH (o:Officer)\nSET o.label = o.id
\n

Then we look for officers with substantiated complaints and set their label to their full name.

\n
MATCH (o:Officer {ccrbSubstantiatedBool: \"true\"})\nSET o.label = COALESCE(o.firstName ,\"\") + ' ' + COALESCE(o.lastName ,\"\")
\n

Now we have our officers created, we need to create our incidents.

\n
Creating incident nodes
\n

We are going to continue to use our CSV which filtered out incidents before 2010 or that were unfounded or exonerated.

\n

First we tell Neo4J that we have unique incident IDs

\n
CREATE CONSTRAINT incidentIdConstraint ON (incident:Incident) ASSERT incident.id IS UNIQUE
\n

Then we create an incident for every row we see in OfficerAllegationHistory. We'll make note of the precinct the incident occurred in, what the specific allegation was, and what date the incident occurred.

\n
LOAD CSV WITH HEADERS FROM \"http://localhost:11001/project-185bb75c-b944-451a-9c0f-aeba860ae68a/OfficerAllegationHistory_FILTERED-SINCE2010-NOT-UNFOUNDED-EXONERATED.csv\" AS csvLine\nMERGE (incident:Incident {id: csvLine.`Complaint Id`})\nSET incident.incidentPct = COALESCE(csvLine.`Precinct Of Incident Occurrence`,\"N/A\")\nSET incident.ccrbDisposition = csvLine.`CCRB Allegation Disposition`\nSET incident.allegation = csvLine.`Allegation`\nset incident.date = csvLine.`Incident Date`\nRETURN incident
\n

Now let's do the same for OfficersInvolvedInComplaints.

\n
LOAD CSV WITH HEADERS FROM \"http://localhost:11001/project-185bb75c-b944-451a-9c0f-aeba860ae68a/OfficersInvolvedInComplaints_FILTERED-SINCE2010-NOT-UNFOUNDED-EXONERATED.csv\" AS csvLine\nMERGE (incident:Incident {id: csvLine.`Complaint Id`})\nSET incident.ccrbDisposition = csvLine.`Complaint Disposition`\nRETURN incident
\n

Now let's create labels for our incidents, which is going to be the allegation.

\n
MATCH (i:Incident)\nSET i.label = i.allegation
\n

Now that we have our Incidents and our Officers we need to create our relationships between them.

\n

Creating relationships between incidents and officers

\n

Now for the fun part.

\n

We are going to create a new relationship called INVOLVED_IN, and officers can be INVOLVED_IN one or many incidents. Incidents may have one or many officers that were INVOLVED_IN it, either as witness or subject officers.

\n

First we create our relationships from OfficersInvolved:

\n
LOAD CSV WITH HEADERS FROM \"http://localhost:11001/project-185bb75c-b944-451a-9c0f-aeba860ae68a/OfficersInvolvedInComplaints_FILTERED-SINCE2010-NOT-UNFOUNDED-EXONERATED.csv\" AS csvLine\nMATCH (officer:Officer {id: csvLine.`Unique Officer Id`}) with csvLine, officer\nMATCH (incident:Incident {id: csvLine.`Complaint Id`}) with csvLine, officer, incident\nCREATE (officer)-[:INVOLVED_IN {status: csvLine.`Officer Status`}]->(incident)
\n

Which creates 94,323 relationships.

\n

Then from OfficerAllegationHistory:

\n
LOAD CSV WITH HEADERS FROM \"http://localhost:11001/project-185bb75c-b944-451a-9c0f-aeba860ae68a/OfficerAllegationHistory_FILTERED-SINCE2010-NOT-UNFOUNDED-EXONERATED.csv\" AS csvLine\nMATCH (officer:Officer {id: csvLine.`Unique Officer Id`}) with csvLine, officer\nMATCH (incident:Incident {id: csvLine.`Complaint Id`}) with csvLine, officer, incident\nCREATE (officer)-[:INVOLVED_IN {allegation: csvLine.`Allegation`, type: csvLine.`FADO Type`}]->(incident)
\n

Now we have 159,671 relationships. Sick.

\n\n

Next we can flatten out our graph a little bit and remove incidents if we want.

\n

We will create a new type of relationship that only occurs between two officers called CO_OCCURANCE - we will only make one of these between each officer, but the weight of that link will be decided by how many complaints those officers appear together on.

\n\n

So officers who appear on 3 complaints together have a CO_OCCURANCE relationship with a weight of 3. This allows us to do some weighted degree analysis when we are making our layout, deciding how large to make nodes, and when we are detecting communities.

\n
MATCH (o1:Officer)-[:INVOLVED_IN]->(i:Incident)<-[:INVOLVED_IN]-(o2:Officer) WHERE id(o1)<id(o2) with o1, o2, count(i) as weightCount CREATE (o1)-[:CO_OCCURANCE { weight: weightCount }]->(o2)
\n

Officers without connections

\n
MATCH (o:Officer) WHERE NOT (o)-[:CO_OCCURANCE]-() RETURN count(o)
\n\n

Eigenvector analysis on our network

\n

Let's run a standard centrality analysis algorithm called \"Eigenvector Centrality\"

\n
CALL gds.alpha.eigenvector.write({\n  nodeProjection: 'Officer',\n  relationshipProjection: 'CO_OCCURANCE',\n  relationshipProperties: 'weight',\n  relationshipWeightProperty: 'weight',\n  writeProperty: 'eigenvector'\n})\nYIELD nodes, iterations, dampingFactor, writeProperty\n
\n

Now every Officer node has an eigenvector value that represents its centrality across our entire NYPD-wide network. The larger the value, the more central that node is.

\n

Analyzing our data with Gephi

\n

Neo4J is cool for processing and analyzing tons of data, but I want to draw thousands of circles and lines now and start untangling the hairball of our network.

\n

I am going to use Gephi, which I have a love-hate relationship with, but is unrivaled when it comes to network visualization. Plus, I already know how to use it.

\n

We are going to stream our data from Neo4J to Gephi in order to leverage Neo4J's power to handle huge amounts of data (way more than Gephi) but still get to use Gephi's layout algorithms and analysis techniques.

\n

Flattened co-occurance network

\n

To get our flattened network, which removed incident nodes:

\n
MATCH path=(o1:Officer)-[r:CO_OCCURANCE]->(o2:Officer) WITH o1, path limit 125000  with o1, collect(path) as paths call apoc.gephi.add(null,'workspace1', paths, 'weight', ['weight', 'id', 'eigenvector', 'firstName', 'lastName', 'label', 'date', 'currentCommand']) yield nodes, relationships, time return nodes, relationships, time ORDER  BY o1.eigenvector DESC
\n

This streams 100,000 edges and 25,064 nodes into Gephi.

\n\n

We'll run the Force Atlas 2 layout algorithm in Gephi to have the nodes arrange themselves into some sort of sense.

\n\n

We can use Gephi's modularity algorithm to color by \"community\" within our network, and we'll tweak our layout algorithm to separate things out a bit.

\n

The communities that Gephi detects often mirror real-world precincts. As one might expect, officers appear on complaints with other officers in their precinct because they are working together most often.

\n

I like that the algorithm detects communities that resemble precincts, and it actually gives me confidence that the community detection is working.

\n\n

Then we can add some labels and we've made a map of the network of officers who appeared on CCRB complaints together, and there appear to be a number of closely-knit clusters and different communities within our network.

\n\n

Precinct-specific networks including incidents (un-flattened network)

\n

Let's put it all together and stream all the officers from a single precinct using only incidents since 2010.

\n
MATCH path=(o1:Officer)-[:INVOLVED_IN]->(i:Incident {incidentPct: \"75\"})<-[:INVOLVED_IN]-(o2:Officer)\nwhere i.date IS NOT NULL and apoc.date.parse(i.date, \"ms\", 'YYYY-mm-dd') > 1262304000000\n WITH o1, path, i limit 100000  with o1, i, collect(path) as paths call apoc.gephi.add(null,'workspace1', paths, 'weight', ['weight', 'id', 'eigenvector', 'firstName', 'lastName', 'date']) yield nodes, relationships, time return nodes, relationships, time ORDER  BY o1.eigenvector DESC
\n

We can also make a network that is un-flattened, that is, we can see nodes for both officers as well as incidents. This way, we can see the patterns in the way incidents tie officers together.

\n\n

Every blue circle here is an incident, and every red circle is an officer (both filtered by the 75th precinct, since 2010).

\n

Now let's size the circles by their degree (the number of connections they have) and run a layout algorithm.

\n\n

Some big nodes start to pop up, like Martinez, Radoncic, and Grieco. What is causing these officers to co-appear on so many different complaints with so many different officers?

\n

When exploring this network, large nodes pop up, and I became naturally curious what the careers of those officers looked like. One of the first ones that jumped out to me was a big node that represented an officer named Nicholas Rios.

\n\n

I googled his name, and one of the first results was a harrowing story of a federal civil rights case that named him.

\n\n

In the reporting that George Joseph did for Gothamist/WNYC, he found that a number of large influencers that appear in this network analysis also acted as influencers on the ground.

\n

He looked at another large node in the network, Adnan Radoncic:

\n
\n

Atunbi asserted that Radoncic was a catalyst for a group assault on the street that day.\n“As soon as he grabbed me, all the officers was hands on,” he said. “It’s like they just followed his lead.”

\n
\n

Potential Next Steps

\n

There are a few different directions for further analysis that I didn't have time for, but may result in interesting findings.

\n\n

Flotsam & Jetsam

\n\n\n\n\n\n\n

Hire me to do work like this

\n

I do freelance data exploration and visualization for clients who aren't evil. If you'd like to hire me to take a look at a dataset for you, just get in touch at ejfox@ejfox.com

\n

Footnotes

\n
    \n
  1. \n

    The notes say, basically: these are complaints received in or after the year 2000. Cases that are mediated or were attempted to be mediated are excluded. ↩

    \n
    2. \n
  2. \n

    OfficerAllegationHistory columns: 

    \n
    1: As Of Date
    \n
    2: Allegation Record Identity
    \n
    3: Unique Officer Id
    \n
    4: Active Per Last Reported Status
    \n
    5: Last Reported Active Date
    \n
    6: Officer First Name
    \n
    7: Officer Last Name
    \n
    8: Officer Race
    \n
    9: Officer Gender
    \n
    10: Current Rank Abbreviation
    \n
    11: Current Rank
    \n
    12: Current Command
    \n
    13: Shield No
    \n
    14: Complaint Id
    \n
    15: Incident Date
    \n
    16: CCRB Received Date
    \n
    17: Close Date
    \n
    18: Officer Rank Abbreviation At Incident
    \n
    19: Officer Rank At Incident
    \n
    20: Officer Command At Incident
    \n
    21: Officer Days On Force At Incident
    \n
    22: Borough Of Incident Occurrence
    \n
    23: Precinct Of Incident Occurrence
    \n
    24: Location Type Of Incident
    \n
    25: Reason for Police Contact
    \n
    26: Outcome Of Police Encounter
    \n
    27: Victim Age At Incident
    \n
    28: Victim Race
    \n
    29: Victim Gender
    \n
    30: FADO Type
    \n
    31: Allegation
    \n
    32: CCRB Allegation Disposition
    \n
    33: Board Discipline Recommendation
    \n
    34: Non-APU Penalty Report Date
    \n
    35: Officer Is APU
    \n
    36: APU CCRB Trial Recommended Penalty
    \n
    37: APU Trial Commissioner Recommended Penalty
    \n
    38: APU Plea Agreed Penalty
    \n
    39: APU Case Status
    \n
    40: APU Closing Date
    \n
    41: NYPD Allegation Disposition
    \n
    42: NYPD Officer Penalty
    \n
    43: Reconsideration Requested
    \n
    44: Reconsideration Request Withdrawn
    \n
    45: Reconsideration Request Rejected
    \n
    46: Reconsideration Occurred
    \n
    47: Reconsideration Decision Pending
    \n
    \n

    :3 OfficersInvolvedInComplaints columns: 

    \n
    1: As Of Date
    \n
    2: Officer Status
    \n
    3: Unique Officer Id
    \n
    4: Active Per Last Reported Status
    \n
    5: Last Reported Active Date
    \n
    6: Officer First Name
    \n
    7: Officer Last Name
    \n
    8: Officer Race
    \n
    9: Officer Gender
    \n
    10: Current Rank Abbreviation
    \n
    11: Current Rank
    \n
    12: Current Command
    \n
    13: Shield No
    \n
    14: Complaint Id
    \n
    15: Complaint Disposition
    \n
    16: Incident Date
    \n
    17: CCRB Recieved Date
    \n
    18: Close Date
    \n
    \n↩\n
    3. \n
  3. \n

    I ran this in the CLI SQLite client to chop up the date string and re-write it in the way SQLite wants it:

    \n
    update OfficerAllegationHistory\nset [Incident Date] = substr([Incident Date], -4) || '-' ||\nsubstr('00' || ([Incident Date] + 0), -2, 2) || '-' ||\nsubstr('00' || (substr([Incident Date], instr([Incident Date], '/') + 1) + 0), -2, 2);
    \n↩\n \n↩2\n \n↩3\n
    4. \n
\n
","title":"Finding Clusters of NYPD Officers In CCRB Complaint Data","metadata":{"date":"2021-06-11T08:00:17.000Z","type":"words","hidden":false,"inprogress":false,"dek":"In which various tools and methods are explored for analyzing data that describes a network of complaints against NYPD officers (or any other PD with similar public data)","modified":"2024-09-23T16:13:24.000Z","tags":["data","nypd","visualization","network"],"words":3595,"images":0,"imageDetails":{"total":0,"cloudinary":0,"withDimensions":0},"links":16,"codeBlocks":24,"headers":{"h2":1},"toc":[{"text":"Finding Clusters of NYPD Officers In CCRB Complaint Data","slug":"finding-clusters-of-nypd-officers-in-ccrb-complaint-data","level":"h2","children":[{"text":"Why?","slug":"why","level":"h3","children":[]},{"text":"The Dataset","slug":"the-dataset","level":"h3","children":[]},{"text":"Analysis","slug":"analysis","level":"h3","children":[]},{"text":"Analyzing our data with Datasette / SQLite","slug":"analyzing-our-data-with-datasette--sqlite","level":"h3","children":[]},{"text":"Analyzing our data with Neo4J","slug":"analyzing-our-data-with-neo4j","level":"h3","children":[]},{"text":"Analyzing our data with Gephi","slug":"analyzing-our-data-with-gephi","level":"h3","children":[]},{"text":"Potential Next Steps","slug":"potential-next-steps","level":"h3","children":[]},{"text":"Flotsam & Jetsam","slug":"flotsam--jetsam","level":"h3","children":[]},{"text":"Hire me to do work like this","slug":"hire-me-to-do-work-like-this","level":"h3","children":[]}]}]}},"_links":{"self":"https://ejfox.com/blog/2021/nypd-ccrb-complaint-clusters.json","html":"https://ejfox.com/blog/2021/nypd-ccrb-complaint-clusters","index":"/blog.json"}}