alpha-beta-soup / national-crash-statistics Goto Github PK

I think it'd be useful for there to be a counter at the base of the legend showing a number of how many accidents meet the criteria of the chosen filters. I've seen a lot of people saying "more accidents are due to X than to Y". We could easily put a number to that to allow people to actually make factual claims rather than having them just making shit up.

date field is incorporated.

Police holiday periods?
Time slider?

At present, the accident pop-ups get populated once, by a Python script that reads the coded values from the CSV into the GeoJSON. This means that the GeoJSON file becomes very big, and people unknowingly download all of the popups each time they look at the map.

A better solution is to populate the GeoJSON with the coded values, and decode these into a popup when the popup is requested. This should happen in the Javascript. The only reason it isn't is because my Python is much better than my Javascript, and I initially set out just to write a Python parser of the CSV data. It's an irritating hangover.

Any slowdown caused by performing the conversion on-the-fly will probably be more than compensated by the ability to show more data, and/or a smaller GeoJSON considerably improving initial load time.

There are a few issues with the raw data. In the 2014 data, two points seem to have an invalid latitude, so appear near the south pole. These will need to be manually adjusted, and there are possibly others in the as yet untouched datasets.

Crashes occurring in the Chatham Islands have been placed in the Pacific Ocean to the west of where they actually occurred, presumably to avoid having points in the western hemisphere. The offset can probably be determined and then added to any points listed as occurring in the Chathams county (in the Python). How this plays with Leaflet is another matter...

Spot the difference:

Ironically, the ability to hide the sidebar is more useful when the browser is not maximised.

rather than everything by default

A little side track here. I just added a sample file from NZTA's spreadsheets on road safety, broken down by TA for each RC.

These would make a good series of interactive charts. They allow robust statistical analysis because they can be normalised: each TA and RC's length of local and regional roads are included: so the most dangerous TAs can be identified.

I'd be keen to give this a go with D3 after I finish my thesis. But if anyone else would like to try, be my guest. Ideally (IMO) they'd be presented on a second webpage (or series of pages), with a link provided from the map sidebar.

This can progress completely separately from any improvements to the map architecture.

https://github.com/turbo87/leaflet-sidebar/

Self-explanatory

At present, when a popup is expanded for the first time, and the text within it does not meet or exceed the width of the Streetview preview, the popup is too narrow to hold the Streetview preview once it has loaded (after a small lag). The second time, there is no issue. An example is attached.

At the moment the page tab is looking a little ugly. A .ico file would be cool. Not sure what it should look like though.

At present terms like "Smith St" become "Smith Street" in the popup text. However it's careful enough, and would turn "St John St" into "Street John Street", as in the attached image. Either expansion should be abandoned, "St" ignored in particular, or a special check made for this exception.

Hi guys

New filtering system is awesome - though I have potentially spotted a 'bug' in that it doesn't appear you can have more than one consequence filter on (even though some accidents have a mix of injuries)? Is this intended or something to be re-worked?

There's probably a few causes that need revision for not sounding weird once stitched together. Could be good to go over with a fine-tooth comb, or maybe also add a "Feedback" link that goes to a Twitter profile, or this issue, so people can report them as they notice them... if they're so inclined (unlikely).

The above should be The driver of the car had their vehicle catch fire.

...snigger

There's potentially 14 years of data to include. 2013 + 2014 came to a ~50MB dataset (wiggle room because it also depends on number of properties, etc.), which is much too big as things currently stand.

Food for thought: https://github.com/mapbox/geojson-vt

The real benefit of this web map is to enable a user to stack the different filters. An example use case would be someone who is interested in accidents that have involved a pedestrian, and where someone was drunk, and where someone was severely injured or killed. At present, we can show any of these things in isolation, but cannot answer the combined question.

Food for thought: http://ipasic.com/article/query-and-filter-leaflet-map-layers/

This is probably a major change requiring entirely different tools (that example needs Django and PostGIS)... but the result is damn useful.

Just used these sweet ant react components and thought it could be a good fit (the cause codes for accidents are hierarchical). The one implementing search is great. https://ant.design/components/cascader/#components-cascader-demo-search

Just a grey circle. You'd think a broken link to the PNG would still show that "missing image" image, so perhaps it's something else. Review the PR that changed to it from the I symbol we had before.

https://antv.alipay.com/g2/demo/01-point/punch-card.html

The NZTA is probably going to change the way in which they publish the data underlying this project.

I first noticed that the data had stopped being updated on the website, which currently extends to only March 2015, when the quarterly update to June (or even September) 2015 should now be available to the public. Then the data download disappeared from the NZTA website entirely (no immediate fear, all the raw data is still contained in this repository as I have it on record that it has a permissive license). I emailed the Statistical Analysis team at NZTA asking for an explanation. Here is the exchange so far:

I was looking to update my record of the CAS data, but the page I have used in the past no longer exists: https://www.nzta.govt.nz/resources/crash-analysis-system-data/

I noticed a few weeks ago that although it was up, the available data only went as far as March this year. Is this data still available for download?

They replied:

Apologies for the delay in replying to your email. We are currently reviewing the CAS information we have available on our website to make sure it meets our privacy and security standards. As the new on line data will be summarised information and I understand you work with geospatial co-ordinates, would you like to apply for CAS access? This will give you access to the same level of information as was previously on the web.

Me again:

Yes I suppose I would like to apply for access, provided that the access will not cost me as I'm only using it as a hobbyist.

However I'm using the CAS data to make a public web map (http://www.nearimprov.com/national-crash-statistics/) in collaboration with some others. Will this review mean that my application will not be able to present the disaggregate information to the public?

I waited a week then prodded again:

Is there any information on this review available? I have some free time available over this summer I am planning to spend developing my mapping application, but I first need to know if the data will still be able to be made public via my application.

And then:

Thanks for your email. There is no cost associated with access to CAS, but you will be required to sign a data agreement. Under this agreement you will only be able to make aggregated information (totals of 4 or more) available through your app. Would you like to proceed with getting CAS access?

I find the proposed changes to be a tremendous step backwards, and I cannot find any information online about this review, including whether any external users of the data were even consulted about the changes. I plan to make an OIA enquiry into the review to determine what decision has been made, how, and why. Just imagine instead of hiding this information away, their review had instead decided to make a public API for accessing it? (This has been recommended: but the type of information will be diminished.) This is public information that the public deserves to be able to see.

I also have absolutely no plans to agree to that data agreement. How can I only show aggregate information meeting their minimum-of-four-crashes requirement that is still useful? There are thousands of intersections that have fewer than four recorded accidents. The best I can come up with is some form of clustering with Voroni polygons, with a summary of four accidents within each irregularly-sized zone. So much detail will be lost.

1. Does anyone have any ideas about how to meet the requirements of the agreement while still showing useful information? A brilliant idea may make me reconsider my position on signing the data agreement.
2. Is anyone willing to help me dig into this change? It's an immense backward step.

https://stamen.com/work/crimespotting/

#49

Rather than building the popup text each time in the JS, we could build the entire popup text in the Python script and store it as a single parameter. I don't know if this will actually make the file smaller, but it's worth a try as there is certainly a strong relationship between the number of properties and the file size. This also makes the popup marginally harder to style and tweak.

Needs to be less intrusive, use space better.

Potential two column approach (to be wider than tall) or for it to appear in the bottom right of screen.

People like heatmaps. It could be an interesting experiment.

http://www.patrick-wied.at/static/heatmapjs/example-heatmap-leaflet.html

This is a nice to have. Some ideas:

• https://github.com/ghusse/jQRangeSlider
• https://github.com/dwilhelm89/LeafletSlider

At zoom levels where more than one region can be seen, cluster current view of dots by TA.

1. Decide zoom levels
2. Incorporate TA information/representative geographic centre
3. Count current dots in region

The icons used at present I really consider placeholders, because:

• They're inconsistent in style
• They're inconsistent in size
• The injury ones should (IMO) be colour coded to match the colours we use to signify injury type with the circle markers
• Some of them are just shit

The icons themselves are stored in ./icons/ (weather and lighting), ./icons/injuries/ (injuries) and .icons/transport/ (vehicle types).

If the icons are changed or new ones are added, this'll need to be reflected in nzta2geojson.py in nztacrash.__vehicle_icons__(), nztacrash.get_injury_icons(), and nztacrash.weatherIcon() by specifying the new filenames in the appropriate places. This should be reasonably straightforward once new icons are prepared.

I think icons could also be used to represent lighting conditions better, such as through the use of an icon to indicate the presence (or absence) and (mal-)function of street lights at an accident location.

• https://developers.google.com/maps/documentation/javascript/3.exp/reference#StreetViewPanorama
• http://gis.stackexchange.com/questions/133878/working-out-street-view-heading
• https://developers.google.com/maps/documentation/javascript/examples/streetview-custom-tiles

Go from this (using static image API)...

...to the interactive version of this (using panorama tiles):

Probably should stick with only the static preview for small devices.

At present the static image API is used to position the viewport so it is facing the given crash location. However often this results in the view from the centre of the road looking at a building. Users can go to streetview by clicking on the image, but it would be easier just to allow camera manipulation inside the popup.

Currently crashes at the same location overlap and the crash displayed underneath cannot be clicked on for information.

• http://geocoder.readthedocs.io/providers/Google.html?highlight=elevation
• https://gist.github.com/dmofot/dc46e33eb19ac67e0ecf