NZR Incidents: Difference between revisions
(Created page with "== NZR INCIDENTS == As with any industry, everything does not always go to plan, there are breakdown, operators loose control of their machinery, or someone causes a collision. Then you also have cases of willful damage, often with little regard of the possible consequences, and then there are cases of just being in the wrong place at the wrong time. In an organisation as big as the national railway, with a history going back more than 150 years now, there were of course...") |
No edit summary |
||
(21 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
== | == INTRODUCTION == | ||
As with any industry, everything does not always go to plan, there are | As with any industry, everything does not always go to plan on a day to day basis, there are breakdowns, operators loose control of their machinery, or someone causes a collision. Then you also have cases of willful damage, often with little regard of the possible consequences, and then there are cases of just being in the wrong place at the wrong time. In an organisation as big as the national railway, with a history going back more than 150 years now, there were of course many incidents. During the years of rapid growth, any railway incident was of public interest and keenly reported in the local news papers. With many back-issues of newspapers now being available on-line, there is a ready source of the more significant incidents. | ||
The key to managing such data will be designing an appropriate data table to hold the range of incidents that could be encountered, then writing appropriate queries so the data can automatically appear on the relevant pages in the wiki. | The key to managing such data will be designing an appropriate data table to hold the range of incidents that could be encountered, then writing appropriate queries so the data can automatically appear on the relevant pages in the wiki. This is a large task requiring some dedicated resources over an extended period. Each Incident is in effect one or more 'railway facts' but all of a particular type. There are several books that deal with railway accidents, these being generally the more significant ones, and the one covering the widest range is titled "[[Book - Danger Ahead|Danger Ahead]] New Zealand Railway Accidents in the Modern Era" by Geoffrey Churchman. I will use that publication to work out the data structure needed to capture incident data as fully as possible. | ||
DANGER AHEAD - individual incidents as recorded in that publication will be used as test cases for setting up data tables. These will be recorded in MSExcel for transfer to the wiki, either as tables or for loading into the Cargo database from where queries can generate formatted output on wiki pages. The following few lines are an example of the data that can be collected in a structured way. | |||
{| class="wikitable" | |||
|+ Example NZR Incidents as recorded in the publication [[Book - Danger Ahead|Danger Ahead]] | |||
! Seq | |||
! Update | |||
! Reference | |||
! Page | |||
! Sector | |||
! Date | |||
! Line | |||
! LinRef | |||
! Prefix | |||
! StartLocation | |||
! Sub/EndLocation | |||
! Train1 | |||
! Item1 | |||
! Detail1.1 | |||
! Detail1.2 | |||
! Train2 | |||
! Item2 | |||
! Detail2.1 | |||
! Detail2.2 | |||
! LocoCount | |||
! WagonCount | |||
! Fatalities | |||
! EventType | |||
! Cause/Qualifier | |||
! ImageCount | |||
|- | |||
|1 | |||
|Cover | |||
| | |||
|[[Woburn]] | |||
| | |||
|1963 | |||
| | |||
|[[Loco_Ew1803]] | |||
|Shunt | |||
|Collision | |||
|1 | |||
|- | |||
|2 | |||
|pg.1 | |||
|near | |||
|[[Ongarue]] | |||
| | |||
|1972 | |||
| | |||
|[[Loco_Da1500]] | |||
|washout | |||
|Derailment | |||
|2 | |||
|- | |||
|3 | |||
|pgs.4+5 | |||
| | |||
|[[Mamaku Bank]] | |||
| | |||
|1958 | |||
| | |||
| | |||
| | |||
|Runaway | |||
|1 | |||
|} | |||
Having processed the whole book (over 2 days), I have expanded the column number to 25 to cover the wide range of material that I came across. Further changes may still be required as I move into the next stage. | |||
'Facts' need to be recorded in a structured way in the wiki. Where multiple items like loco's or wagons are listed, they can be entered as a list in the Item fields, however if railway people are to be recorded as being involved in an incident, each person goes on a separate data line. Multiple bits of information for the same item e.g. Loco or Bridge or Person, all have to have separate lines. This enables data queries to return more meaningful and focused results. A publication like 'Danger Ahead' only records a minimum of data, however, other sources may well be able to supply fill-in data, so the records may be able to be expanded at a later date. For this reason,each MSExcel row has an Update field enabling the same records to be reprocessed if new information comes to hand. | |||
Incidents are identified by Date and Location, and as I work through the intricacies of all this, I see it would be useful to maintain a copy of the MSExcel Incidents data in a table on the wiki, accessible from the Incidents balloon. I am not sure how all that will be achieved yet, but see it will provide a means for any user to be able to add missing data to those records. | |||
Incident facts will all form a special grouping of 'railway facts', meaning they will be stored in the same Cargo table as general 'Facts' but be tagged as 'originating from an incident report. Each will be linked to the MSExcel record that generated the Wiki Records so these can be flagged for deletion before a reprocessing run. Working through 'Danger Ahead' generated 234 rows of data which will likely expand to maybe 500 Wiki Facts records. Writing the VBA code to generate these will be the next challenge. |
Latest revision as of 09:40, 24 September 2024
INTRODUCTION
As with any industry, everything does not always go to plan on a day to day basis, there are breakdowns, operators loose control of their machinery, or someone causes a collision. Then you also have cases of willful damage, often with little regard of the possible consequences, and then there are cases of just being in the wrong place at the wrong time. In an organisation as big as the national railway, with a history going back more than 150 years now, there were of course many incidents. During the years of rapid growth, any railway incident was of public interest and keenly reported in the local news papers. With many back-issues of newspapers now being available on-line, there is a ready source of the more significant incidents.
The key to managing such data will be designing an appropriate data table to hold the range of incidents that could be encountered, then writing appropriate queries so the data can automatically appear on the relevant pages in the wiki. This is a large task requiring some dedicated resources over an extended period. Each Incident is in effect one or more 'railway facts' but all of a particular type. There are several books that deal with railway accidents, these being generally the more significant ones, and the one covering the widest range is titled "Danger Ahead New Zealand Railway Accidents in the Modern Era" by Geoffrey Churchman. I will use that publication to work out the data structure needed to capture incident data as fully as possible.
DANGER AHEAD - individual incidents as recorded in that publication will be used as test cases for setting up data tables. These will be recorded in MSExcel for transfer to the wiki, either as tables or for loading into the Cargo database from where queries can generate formatted output on wiki pages. The following few lines are an example of the data that can be collected in a structured way.
Seq | Update | Reference | Page | Sector | Date | Line | LinRef | Prefix | StartLocation | Sub/EndLocation | Train1 | Item1 | Detail1.1 | Detail1.2 | Train2 | Item2 | Detail2.1 | Detail2.2 | LocoCount | WagonCount | Fatalities | EventType | Cause/Qualifier | ImageCount |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Cover | Woburn | 1963 | Loco_Ew1803 | Shunt | Collision | 1 | |||||||||||||||||
2 | pg.1 | near | Ongarue | 1972 | Loco_Da1500 | washout | Derailment | 2 | ||||||||||||||||
3 | pgs.4+5 | Mamaku Bank | 1958 | Runaway | 1 |
Having processed the whole book (over 2 days), I have expanded the column number to 25 to cover the wide range of material that I came across. Further changes may still be required as I move into the next stage.
'Facts' need to be recorded in a structured way in the wiki. Where multiple items like loco's or wagons are listed, they can be entered as a list in the Item fields, however if railway people are to be recorded as being involved in an incident, each person goes on a separate data line. Multiple bits of information for the same item e.g. Loco or Bridge or Person, all have to have separate lines. This enables data queries to return more meaningful and focused results. A publication like 'Danger Ahead' only records a minimum of data, however, other sources may well be able to supply fill-in data, so the records may be able to be expanded at a later date. For this reason,each MSExcel row has an Update field enabling the same records to be reprocessed if new information comes to hand.
Incidents are identified by Date and Location, and as I work through the intricacies of all this, I see it would be useful to maintain a copy of the MSExcel Incidents data in a table on the wiki, accessible from the Incidents balloon. I am not sure how all that will be achieved yet, but see it will provide a means for any user to be able to add missing data to those records.
Incident facts will all form a special grouping of 'railway facts', meaning they will be stored in the same Cargo table as general 'Facts' but be tagged as 'originating from an incident report. Each will be linked to the MSExcel record that generated the Wiki Records so these can be flagged for deletion before a reprocessing run. Working through 'Danger Ahead' generated 234 rows of data which will likely expand to maybe 500 Wiki Facts records. Writing the VBA code to generate these will be the next challenge.