If I select a person type such as "cyclist", but not a injury type such as "injury" or "fatality", it becomes much more difficult to filter, and more confusing to the user. In the case of cyclists we can use the vehicle type code to see all collisions where a cyclist was involved but not necessarily injured or killed. However there is no such code to filter for pedestrians who may have been involved in a crash but not injured or killed. Likewise selecting "motorist" without selecting "injury" or "fatality" or "no injury / fatality" would really just mean selecting every single crash, as all crashes typically involve motorists. We could theoretically select crashes that involved 2 or more cyclists, but there is no way to select a crash that only involved cyclists and pedestrians.
Thus, it would make more sense to refactor the UI as follows:
label
button
button
button
Cyclist :
fatality
injury
Pedestrian :
fatality
injury
Motorist :
fatality
injury
other
"other" would select all crashes with no injuries or fatalities
users could select multiple buttons, eg: fatalities for cyclists & pedestrians
Display a landing / greeting page for users visiting on mobile asking them to view on Desktop. Mobile layout will be integrated in a later of phase of work.
Currently the crash dot sizes are hard coded. It may make sense to compute equal interval or quantile breaks when the range of the crash count changes after a filter is applied.
For example, currently when all years of the dataset are selected the max crash count for one location is 415, but when a single year or single month is selected the max would be substantially lower.
The CartoLayer tiles can take a few seconds or longer to load at times, so the app should give the user some indication that they are loading after a filter is applied. This stackexchange post seems like a good solution.
Dynamically create SQL queries using string concatenation & template literals, determined by applied data filters. Use Akil's queries in ./sql/ as a starting point.
In the sample final data extract Dejan sent that covers the time period of July 1, 2016 to December 31, 2016 values from the unique_key field don't match those in the NYC Open Data portal.
Final data is almost ready to be imported to CARTO and loaded into the app. Will need to update each of the SQL queries to reflect the changed schema for the crashes table.
do sum(crash_count) for total crashes instead of doing count(cartodb_id) as total_crashes
will have to do something like count(unnest(contributing_factor)) now that there is a single field for contributing factors that is of the type text array.
For filtering by date range will have to select by year and month columns instead of using date_val column (relates to #36)
An ETL script will run daily on a Heroku Scheduler to retrieve the most recent data from the NYC Open Data portal, format it, and load it into the Carto table.
Things get squashed in the Stats Legend UI right now when width is < 1000px. Removing contributing factors & legend between 768px & 1000px will fix this.
When Citywide boundary filter is enabled, display a disclaimer message to the right of the cartodb attribution stating that stats may differ than points on map due to lack of location information provided by the NYPD.
Some rows have higher values for the type of person injured or killed than "number_of_persons_killed" or "number_of_persons_injured". For example, a row may have a value of 3 for "number_of_pedestrians_killed" but then have a value of 2 or 1 or 0 for "number_of_persons_killed". Typically in the data it seems that "number_of_persons_killed" reflects a total for all three categories of person killed: cyclist, motorist, and pedestrian. Same for "number_of_persons_injured".
As such the columns "number_of_persons_injured" and "number_of_persons_killed" should be treated with suspect.
Here is a screenshot of selecting such rows in CARTO:
For example prevent user from selecting a month earlier than August when year is 2011 and later than January when year is 2017. Being able to change the month to one that has no data won't update the data in the app and may confuse or mislead the user.
In order to use the data compiled by John Krauss for 2009 - 2011 the date range filter should be limited to month and year. That data is summary data and fills in the gap for some years between the TA data and NYC Open Data.
App currently says: "Map data last updated 12/31/2016", either remove or add a feature that alters this date when the ETL script runs and successfully updates the data on Carto.
Causes the SQL query to be fired prematurely. Should either remove store.filterByArea.geo before firing SQL or prevent interaction with Filter by Type buttons when the Filter by Boundary polygons are loaded / loading onto the map.
If hosting on github pages and redirecting URL, will need to make sure all links are changed from https to http. Also site name should be updated in social media meta tags as it is currently pointing to https://clhenrick.github.io/nyc-crash-mapper/.
turn off https option in initCartoLayer
use http version of carto basemap tiles url in app_config