Open Data Policing NC aggregates, visualizes, and publishes public records related to all known traffic stops to have occurred in North Carolina since January 1, 2002.
To let users view searches grouped by "type", this adds a new graph-table pair on the model of "Departmental Stop Count" and the API endpoint to support it.
The new API endpoint is a simple addition that slices the year-by-year search counts by type and adds the type to each object as search__type. This new endpoint is added to the cache-priming system.
The changes on the front-end are a little hairy because we want to reuse as much as possible from StopByReasonAndRace while respecting the differences between the data they consume. It wouldn't be cool to force the "search count" API endpoint to generate data with weird labels (stops, purpose, etc) for the historical reason that this graph was based on another one that consumed an API where those labels made sense. Hence we need to create generalized versions of the StopByReasonAndRace machinery that lets us define what part of the API's return value we're interested in, the name of the group-by key, the human-readable name of the values under discussion, etc.
The former StopByReasonAndRace module has been renamed IncidentByReasonAndRace, and the changes in that module all relate to changing hard-coded values to references to abstract properties specified on the subclasses. For example, the use of this.data.raw.stops is systematically replaced by this._raw_data().
The new API handler, graph, and table are all defined as subclasses from the contents of IncidentByReasonAndRace and linked in by the usual means.
To let users view searches grouped by "type", this adds a new graph-table pair on the model of "Departmental Stop Count" and the API endpoint to support it.
The new API endpoint is a simple addition that slices the year-by-year search counts by type and adds the type to each object as
search__type. This new endpoint is added to the cache-priming system.The changes on the front-end are a little hairy because we want to reuse as much as possible from
StopByReasonAndRacewhile respecting the differences between the data they consume. It wouldn't be cool to force the "search count" API endpoint to generate data with weird labels (stops,purpose, etc) for the historical reason that this graph was based on another one that consumed an API where those labels made sense. Hence we need to create generalized versions of theStopByReasonAndRacemachinery that lets us define what part of the API's return value we're interested in, the name of the group-by key, the human-readable name of the values under discussion, etc.The former
StopByReasonAndRacemodule has been renamedIncidentByReasonAndRace, and the changes in that module all relate to changing hard-coded values to references to abstract properties specified on the subclasses. For example, the use ofthis.data.raw.stopsis systematically replaced bythis._raw_data().The new API handler, graph, and table are all defined as subclasses from the contents of
IncidentByReasonAndRaceand linked in by the usual means.