-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] Crash IDs that do not have a unit. #7622
Comments
I put together a query to find all the crashes in the database without units. The three which are listed in the issue are correctly noted as being in that set, but I just wanted to get a handle on how big the total list was. As an aside, the query also checks to see if the crashes which are missing units are also missing people in the persons table. (They all are.) The query I used is:
This query returns 14 records, which means there are only these 14 crashes in the entire database in this problem set: I have pulled up many of these in the VZE and I have also looked at their rows in the I believe that these records were sent to us from CRIS in this degraded (read: mostly blank) state, such as if something went wrong on the data-entry or data-processing steps upstream of us. However, confirming this will take a fair bit of work, as I would need to parse through a big chunk of CSV files to find the original receipt of these crashes and then any updates that came later. Because of this, my recommendation for routes forward are the following, in order of preference:
|
I believe that all crashes should have at least 1 unit and 1 person. What I have seen is that some investigators do not use the "UNKNOWN" flag that is available to them and there doesn't seem to be a validation tool on the system prior to it being submitted to TxDOT. In the 3 cases I provided the CR3 has a null in the field to identify the unit. Currently, no one but me is actively checking for these types of issues and I believe we should be treating it like we do when we manually QA crashes. TxDOT and the investigating agency do not provide the most accurate location, so we manually adjust it. This is similar in its concept of improving our crash detail's accuracy. Although it is a small sample size, I believe we should create a process that provides an automatic unit and/or person if one does not exist. The unit is a MOTOR VEHICLE unit type and UNKNOWN body style and the person is of UNKNOWN injury severity. NOTE: This is a low priority task, but it does assist us in ensuring our system is the most accurate depiction of crash data (even if it is for 14 total crashes). |
@frankhereford has this been resolved? |
Hoping to get your assistance @xavierapostol. Would you be able to write SQL INSERT statements to add the rows you would like inserted into the units table? This would take the option 2 approach that Frank laid out in previous notes
That way we'll get the exact data you want, and can make the changes to the table on our end. |
Would this work for your purposes? |
Thanks @xavierapostol! I'll apply those inserts to a local copy of the VZDB and check them out - I appreciate you pulling that together. I'll report back here as soon as I have that done. |
Checked the database to see if any records had been resolved with the recent action taken to QA the VZV Fatality and Mode count widgets #8424. The number is now 6. |
Reference #8895 |
@frankhereford we're going to use this Issue to resolve the missing unit missing persons in #8895. |
@patrickm02L Patrick clean up, and reissue when actions are clear. |
Asked @frankhereford to investigate why crash ID 17451702 is missing data, and created a separate Issue for him to document his findings #9754. The new Issue will give us some room to investigate potential approaches with the hope that his findings will be able to scale to other Crash IDs that are missing persons and units. |
@frankhereford Based on your findings from #9754 where you determined that 17451702 no longer exists and that deleted crashes in CRIS do not show up in VZDB, can you find the list of crashes that were deleted in CRIS for the past year? Then delete those crashes from our system to ensure that our database is in sync . That action should close out this Issue. Then, I'll make another Issue to do the same process for the preceding years and bring it to the team discuss how to handle our database in a bigger picture way whether that's running a script manually to find the deleted CRIS crashes, creating an automation to find and delete them on a regularly schedule cadence or some other approach that we have yet to determine. |
@patrickm02L Sure thing. I have a one-year chunk of data from CRIS from the previous investigation, and I can use it to generate a list of the records in the The clean-up of our database only covers the time that I had downloaded data for, and so, I suggest we create another spin-off issue to do this same operation on the rest of the VZ data and formulate a plan to do it at regular intervals, perhaps every 6 months, going forward. Please feel free to catch me on slack if I can provide any more information - thanks! |
Vision Zero (Editor)
Here is the list of crash IDs that do not have a unit.
14832414
17451702
17546179
It does not appear that there is an issue with Comprehensive Cost (#6875), but this is a minor data integrity issue.
https://visionzero.austin.gov/editor/#/crashes/
Internet Browser: Chrome
Request ID: DTS21-102935
The text was updated successfully, but these errors were encountered: