Tuesday, 30 May 2017

Stuart Badger

Below is a piece I drafted and Stuart heavily filled in with details in his retirement in early 2017.
For me it marks a tribute to one of the truly remarkable characters I had the privilege of working with during my career.
Stuart was “Mr CAS” and worked from then on with the developer RTI until CAS was delivered slightly late at the end of 1997 but on quality and on budget, and as it turned out - award winning.

Stuart Badger

In the matter of crash analysis and crash systems there is one individual who has contributed much to road safety but (in my view) has been inadequately recognized outside government circles who needs special mention in this blog which is largely engineering centric.

That person is Stuart Badger. Stuart joined the Ministry of Transports (MoT) Wellington Research Section in Aurora House on the Terrace in May 1980, after spending time in the Economics Division working on Land Transport.

When Stuart joined the MoT Traffic Crash Reports or TCR’s were being coded by regional traffic engineers and forwarded to Head Office for bulk entry into a mainframe system. The system had been looked after by Nick Hendy and Bill White, and Stuart took over from Nick.

Analysis was via SPSS and SAS internally with an annual delivery of the coded listing in printouts form to NZ Police, local and regional bodies and consultants.

The next major step was the introduction of systematic black spot investigation when John Toomath brought Barbara Sabey to New Zealand. She had considerable experience in the area, and had finished her UK career as head of the TRRL.

The first study was a joint MoT/MoWD study on State Highway from Levin to Wellington. The spot analysis was done by sticking pins in maps manually, but that approach is inflexible if you want to break crashes down (night time, wet road, …) or drop the earliest year out of the analysis and replace it with the latest year.

Simon Robson found a cheap digitizer which was a drafting board that returned coordinates from the cross hair on the drafting arm. Stuart wrote the software to allow any of the street or topo paper maps to be mounted on the board, and the crashes that could potentially be geocoded against the map to appear in a list for the operator to select and locate. Once crashes had map coordinates blackspot clusters could be identified by what was to become the Accident Investigation System (AIS), and reports could be produced. GIS was too slow to run against all NZ on a PC at that time, so the approach that was used was to print scale transparent overlay crash maps for display on top of the relevant street or topo map.

Accident Investigation System (AIS) really came of age from 1988. A geocoding development was done for the 1987/88 travel survey trips, and it required purchasing toolboxes to add capability to the Basic compiler that was being used. They in turn were used to build the user interface for AIS and improve its performance, and a lot more capability was developed.

AIS was widely distributed to local bodies and consultants with data updates - a subset from the main data base (with private information removed) - sent on disk, the .rnd (random access) files.

AIS was the fundamental building block for all the Crash Reduction Studies from 1984 until 1998 when CAS took over. AIS alone can certainly be credited with its part in the massive savings attributed to the CRS program.

In the early 1980s the main mainframe crash system was changed to an online entry system, and the coding and entry process moved to the three regional MoT engineering teams. Data flowed from that system to the AIS crash geocoding analysis system and any changes (including map coordinates) flowed back again.

In the late 1980s an attempt was made to develop a PC server based system, which would have provided stronger regional capability. However the database (Advanced Revelation) recommended by the consultants was based more around budgetary limitations than its ability to do the job. It was slow, and the movement of data changes between the mainframe and the regional AREV/AIS systems was flakey.

After we saw an integrated Civil Aviation system that dealt with every aspect of operator and aircraft inspections our view of what we needed crystalised. We had been contemplating adding a GIS and a system for holding and providing scanned crash report images but the multitude of potential systems looked ugly. Another important requirements was that the system do as much of the crash geocoding itself as possible to make crashes mapable as soon as possible.

The call was made to replace everything with a single integrated system which would deal with crash data capture, query, reporting, GIS style mapping, crash report image capture and review. The Police saw the INCIS system they were working on providing crash reporting electronically in the future, so the entry side of the system would have dealt with the data flows from the Police, and message back to the Police.
INCIS fell victim to scope creep so paper forms remained for over 20 more years!

The first approach to the market was in 1993, but was not followed through on by LTSA. In 1995 funding was secured and the second approach to market followed, and the vendor for CAS (Crash Analysis System) was identified in 1996. Wang was the prime contractor and provided the crash report scanning application, Relational Technology International (RTI) did the core CAS development using a mix of Oracle and Formida (now xMArc Fire), and Critchlow Associates provided the spatial data and development. The system rollout was at the very end of 1997.

Tony Bliss (General Manager of the Strategy Division, LTSA) was the driving force in getting the budget bid through the MoT. Tony was responsible for the preparation and delivery of the National Road Safety Plan, the New Zealand Road Safety Program and was looking to leverage better safety outcomes from safety engineering and crash reduction studies, Road Policing and other safety initiatives and analysis.

Stuart at that time working for Bill Frith in the LTSA Research team, and developed the budget bids and the RFI/RFP documents in consultation with the regional engineering teams.
The CAS build started in mid 1996 with Stuart in charge and fully supported from Tony and Bill. He had a small team of regional helpers – myself, Geoff Holland, David Croft and Simon Robson.  Since RTI was Auckland based David and I spent a lot of time at their Queen Street office with instructions from Stuart. Stuart was also frequently in Auckland.

(CAS Build team)

From the time CAS was delivered up to this day Stuart really has retained his mantle as the CAS god despite a number of (failed) attempts to clone him.

He has an ability to communicate with CAS users of all levels be they the technical assistants who do all the spade work in the background as well as speak to programmers in terms they respect. I know that the RTI programmers hold him in very high regard to this day.

Between 1998 and 2011 Stuart worked with the “Agency’s” traffic engineers, scientists, researchers and the wider consulting fraternity and the RTI to further develop and improve CAS. 

Stuart was a member of a number of the LTSA’s engineering expert/reference groups and retained his membership after the research team went back to the MoT when LTSA was merged with Transfund. We often referred to him as our honorary engineer.

One of the later safety promotions was KiwiRAP (Road Assessment Programme) which is an exercise that a number of Automobile Associations have spearheaded. It shows were the risky stretched of highway are (in terms of risk per km driven and crashes per km of road). LTNZ/NZTA specified how to split the high network up, and Stuart developed the methods within CAS to do the crash rate calculations.

He was a member a small group that looked after the inner workings of CAS called, unsurprisingly, CASTechs – this group was Geoff Holland, myself, Chris Butler, Lynette Billings and Stuart. This group was abandoned when the regional CAS teams were closed down.
I know however that the while the Transport Agency gives the illusion of running CAS when is comes to the tough stuff he is still the go-to guy. (even in retirement)

Stuart got back to working directly on data systems and analysis in 2007. The MoT needed a detailed vehicle and travel data feed for the vehicle fleet emissions model, and Stuart developed that from the vehicle register data and quarterly and annual reporting to meet policy needs.

In 2012 MoT launched FIGS (Freight Information Gathering System). The two large data feeds are every container loaded, discharged, entering or leaving a container terminal, and every rail wagon movement. There are commercial sensitivities in that data and what is reported has been agreed with the data owners. The third major leg are the Customs/Statistics NZ trade data which is provided in a more detailed form that is released elsewhere. The last two major components are analysis of the NZTA dynamic weighbridge data to estimate overall road tonnekm, and the Maritime NZ ship visit data. Stuart originally joined the short lived Operations Research team of the MoT economics division which was doing work on container ships flows, and whether Australia was getting a better deal from the services which visited both countries. The FIGS opportunity has an element of full circle.

Lastly a personal note which I have little doubt represents the views of many of us from the former engineering team in that I feel privileged to have worked with Stuart for 36 years. I know first hand how much his program AIS and later CAS shaped the way road safety is done in this country – for the better.  The interface end users saw with AIS and then with CAS is still far more user friendly than any system I’ve seen since and I would suspect into the foreseeable future.

Tuesday, 21 February 2017

Other Activties undertaken – James Kings' (Wellington Region) recollections

Road Safety Action Plans

Another area we became involved in was Road Safety Action Plans (RSAP).
I’m not sure when they were initiated or by whom (possibly 2004 and possibly under Demetra Kennedy’s  -Regional Manager)- watch in Wellington Region).

The idea was to get all parties within a local authority with an interest in road safety to come together to discuss and plan road safety actions that were within their milieu and that they could cooperate and have a positive impact on road safety in that authority’s area.

Generally, the group consisted of the road safety coordinator and the roading engineers from the authority, the Police, Accident Compensation Authority, Automobile Association, an LTSA/LTNZ/NZTA officer and a state highways representative.

In Wellington, these meetings were initially chaired by the Regional Director (which suggests the RSAPs were initiated by LTSA/LTNZ/NZTA possibly to better understand and support the work of the road safety coordinator whom we were largely funding), before they devolved to the local authority.

In the first meeting, there was a general discussion of what each organisation thought were the road safety issues that needed to be addressed and what if anything could be bought to the table to address the problems.

Subsequent meetings generally came together on a quarterly basis to discuss progress and liaise with each other on their programmes.

These meetings required some analysis of their projects or trends in the road safety data they obtained associated with their projects and hence whether they believed they had made some progress.

We bought crash trend statistics for each of the problem categories that had been defined for the group to tackle.

I had, now, “discovered” that Excel could get data directly from CAS, so promptly set about producing a spreadsheet that could extract the appropriate data for individual authorities (see ‘RSAP Printout’) that tied in to the problem categories.

It was well received in Wellington and Christchurch Regions and though I wanted them to be run locally there were blockages in the network that did not allow the program to run from Christchurch or Auckland.

The program thus was never fully developed but I consider it to have been successful.

(Note from Chris Hewitt - In Auckland the origins were much older most certainly in the 1990's or before and these groups and the term RSAP was not used until much later. 
I remember them being really functional in Auckland.  I was looking after "south" at that stage which was Franklin District, Papakura District and Manukau City. Each one had its own "road safety liaison" group reflective of  geography and population. 

For myself they were a chance to deliver data, stay connected, keep pushing road safety and develop quality working relationships with local bodies. 
I thought as a single point of contact for the relatively diverse professions that made up these liaison groups they were excellent as an information exchange. 

I met many highly skilled and motivated people in that time from the local bodies, Opus (who helped Franklin and Manukau out), ACC, the Fire service, NZ Police , St Johns, Police Intel and the Road Safety co-ordinators. In Franklin the Road Safety Co-ordinator Mark Ball later became the Mayor - nothing like support from the top. 

As a personal view I felt they fell over once HQ started demanding a more formal one size fits all RSAP type approach possibly because that sense of local ownership and operating style was being taken away. 

I do remember working hard with Inspector Sandy Newsome of the Manukau Police to develop some data driven road safety objectives, but I did have a sense of frustration that many of the "targets" suggested were far from measurable. 

I can't remember if anything in the way of a full plan was ever completed as by that stage all the LTSA/LTNZ/NZTA mergers had muddied the water. Certainly after Doug Miller stopped being our manager the idea of rolling up ones sleeves and getting stuck in with the local people all but ceased. Under the CAS Manager we were even pulled from CAS training outside the Agency, which we'd seen as an essential activity to get local bodies up-skilled and doing their own fishing in CAS which the NZTA supplied free).

Crash Rates

Crash rates on individual roads was the target with this analysis but was never fully realised though I believed it had promise.

It took data from CAS and from the database on local authority’s traffic volume and length of individual road links and matched them to determine a crash rate on that road.

This was feasible because each crash was supposedly tied to an individual piece of a road on which that crash event had occurred.

One problem that was discovered in this process was that crashes at intersections were not being correctly assigned to the roads on which the crash occurred and that they were just being assigned to one of the intersecting roads. (Bugs in CAS turn up in the most unexpected moments)

I was also looking to aggregate the individual roads but had not developed a robust way of doing so given the different traffic volumes on individual bits of a road and the likely difference in section profiles.

(Note from Chris Hewitt - a reliable crash rate system built into CAS had been a goal from the outset but one of the issues is the way the traffic volumes are gathered. Much of the network is not actually counted regularly, if at all and this alone can lead to wild variations in the resultant rates. As this was an area that most end users wanted Stuart Badger and RTI worked to refine the process over many years and got close at the time the Investment Group at NZTA took over CAS , with Stuart just needing to do further testing. However a lack of enthusiasm from the new NZTA CAS Steering group and the dropping of the maintenance contract with RTI saw the end of development.)

Risk Profile

Late in the piece (2009/2010) we looked at risk profiles and again I used data extraction from CAS to Excel to create a table of the risk profile. This was then further advanced by Colin Morrison.

I am sure there were other minor projects undertaken for other parties and even some assistance given to others with Excel problems but I’ll need reminding!

Wednesday, 15 February 2017

Road Safety Briefing Notes - the teams most popular, most recognised safety publication

The Road Safety Briefing Notes or Road Safety Issues Reports as they were initially called were the LTSA’s most popular road safety product – running in their “booklet” form from 2000 through to 2011. That these are still mentioned today in conversations with road safety professionals is testament to the success of the format.

The Briefing Notes were born from two needs:
  1.  A desire to get more easily digested (and brief) statistical material from the 100 page data report available at a media and chief executive level (Dennis Robertson – LTSA Regional Manger Christchurch) and
  2. A need to provide something in more detail (than Dennis’s idea) highlighting key safety issues in a relatively consistent format for each local body in NZ (Glenn Bunting Regional Manger in the Hamilton Office) again in a more easily digested form. 

Glenn says he can clearly remember selling the idea to the other RM’s so I think we can safely give credit for the general idea to the then group of Regional Managers at the LTSA.

The look of the original 2000 Road Safety Issues Reports :

As with the Road Safety Data Reports the process was managed by one of LTSA’s Expert groups, the same one as managed the Data Reports. In 2002 this group was David Croft, Robyn Denton, Colin Goble, David Curson, Jeremy Byfield and Yvonne Warnaar (convenor) with help from Stuart Badger and Alan Dixon.
Chris Hewitt, Geoff Holland and Colin Morrison took over in the Performance information time.  In the Investment team era Colin Morrison carried on as best he could with a much reduced resource. 

Thus the overall concept of the Briefing notes was to provide road safety professionals – and non-professionals with a document that gave between three and five key road safety issues for a particular local body or local government region. Each report was specifically written for the local body in the issues contained but presented in a consistent format nationally.

The general time frame: 
  1. December – February production of MS Publisher "issues" subject templates to be used (giving a consistent national look and feel) - around 15 variants for example speed, bends, alcohol, pedestrians, cyclists, motorcyclists, intersections, weather, driver age etc etc, 
  2. End of March - finalisation of all the previous years CAS data, that is all editing (grid positions added to crashes, all error checks done, all fatal crashes accounted for)
  3. Early April – development of the issues. Initially from the data reports and later using CAS directly and even later confined to NZTA's funding agenda.  
  4. April – June - production with drafts sometimes shared with local body for whom report was being written. Initially this was wholly via hard copy, later by printed and .pdf and towards the end in .pdf with selected recipients receiving hard copy. Even later when produced solely from HQ only in downloadable topic by topic format.
There were some regional variations depending on need – for example in Auckland the Motorway system was treated as a separate entity to prevent the huge number of rear-end crashes unduly colouring what was found in the adjoining local authorities.

Following the initial year 2000 note the format matured and it may have been the involvement or the LTSA’s comms team that got them there, however this marriage proved a frustrating one as I recall with delays, meanings being changed and pedantic arguments over grammar rather than content.

In the end the engineering team divorced Comms and took full ownership with most of us coming to grips with MS Publisher which proved a far more flexible means of production than MS Word - and wasn’t so hard to learn thus destroying the comms teams mystique.

LTSA variant - corporate colours of the time .....

Geoff Holland, Colin Morrison and Chris Hewitt (the LTNZ days) further matured the look of the product and streamlined production. 
There is a lot to be said for taking full responsibility for a product and managing the data, the issues and finally publication. 

In any case the engineering team definitely “owned” its product and took great pride in its popularity with clients.

LTNZ - NZTA Performance Info version and corporate  colours.....

How the issues were derived (prior to their being confined to what the Agency would fund):
  1. Crashes in the area (local, regional or State Highway Region) being examined were compared to the rates found in national data and in peer authorities. This being made possible utilising the two page summary report in CAS. Issues were those crash types or crash causes that appeared to be “over-represented” when compared to peer or national values. Or sometimes just by share number – for example in Auckland intersection crashes would be an issue most years because there are a lot of intersections and by default a lot of crashes.
  2. The Data Reports was also a tool - being a tool used more before the CAS summary report matured
I know when I was looking after the process in the Auckland and Waikato areas in the LTNZ Performance Information days it would take me about a week using CAS to develop the issues to be discussed.

The demise of Doug Millers three Performance Information teams spelt the end of the Briefing notes as they were originally intended.

Colin Morrison struggled on man-alone making them a page-by-page download from the Transport Agency’s web site however even this was terminated when Access and Use took over what remained of the Engineering / CAS team. 
However a "fetch" approach does not always work as well as a "push" approach and I very much doubt that Colins reports reached the same audience - which is a shame considering the massive effort needed.

I have little doubt that these products would be very well received should they ever be revived.

Monday, 13 February 2017

Road Safety Data Reports Part 2 - James Kings' technical notes

From James King – former Senior Engineer Wellington Region .

"I cannot remember exactly when I took over the programme for producing the crash data reports but it was definitely after they were in Excel.

I recall we often had problems with the sizing of the charts usually because we were individually extracting the charts for use in the data reports and trying to associate the charts with specific text.
Each of us was also running the Excel to get the files for the authorities we were writing the report for after the Master Data File (MDF) had been created and distributed to each Regional office.

I am not absolutely certain but Yvonne (Warnaar) may have been having problems with the VBA aspects of the Excel and I must have offered to help even though my VBA skills were not great.
In any regard, I seem to have taken responsibility for the maintenance of the program which was distributed annually to the Regional offices when it had been modified/updated to the current analysis period.

The process for creating the charts started after we were satisfied the crash data for the last year had been entered into CAS and that the data was as clean as could be expected. This was usually expected to be about April in the current year.

The first step was to run a SAS program that extracted the required data from CAS to a file that could be read by an Excel spreadsheet.

The Excel program then created the MDF which also required population data obtained from Statistics NZ which was contained in a separate spreadsheet and usually had the need for some extrapolation of data and some estimations as there was some boundary clashes and some data was incomplete.

The Ministry of Transport (MOT) also supplied the social cost of crashes for the year and they also supplied Health statistics that enables a comparison between CAS injury numbers and reported hospital admissions.

There was also a program that used CAS data that gave an estimate of the crash rates.
All these data sources were then input into the MDF and the spreadsheet that created the individual authorities’ spreadsheets.

Copies of the MDF and the spreadsheet for creating the charts were then distributed to the Region’s coordinator.

Running the spreadsheet to create the individual spreadsheets for the local authorities, the Regional authorities and Transit NZ Regions was generally straight forward provided the individual (person doing the report) remembered to rename the resultant spreadsheet with the correct name rather than just saving and ‘contaminating’ the base spreadsheet that everyone was using.

There were problems with the spreadsheet and it was advisable to review the individual sheets to check the charts for size and axis problems and sometimes title problem before printing out.

There were also page size problems which generated much hair pulling but overall the process was usually fairly quick and would take about half an hour for each authority.

It was also possible to create sets of charts for specific aspects of crash investigation but this required making changes in the MDF by the coordinator/administrator at the Regional office using their copy of the MDF.

It occurs to me that Yvonne may have allowed me to take over the administration of the process when several local body mergers happened as it required changes in all the programmes and the Groups we were using.

The first changes required were in the SAS program and I had to relearn what I was doing there which did not prove too onerous.

The main problems were in the spreadsheets where lines disappeared and tables had to be resized.
There were also changes that had to be made in the population, health and rates programs which overall was not exactly a nightmare but created a few strange errors that had to be found and fixed.
It was often a case of changing pointers in the VBA but it also allowed me the opportunity to get all the charts slightly more standardised.
Some charts remained stubbornly difficult to get their axis correct and they remained a problem that had to be corrected individually – the problem appears to be related to small numbers and/or division by zero (I did try to overcome the problem but was not successful).

We were also individually creating blackspot lists from CAS that were put into the reports.

That problem was countered to some extent by local bodies being able to get the data themselves though there was the comment that our reports were independent and what they could produce was not in the same format.

Consequently, I began to automate the process to create all the individual authority reports in one run which reduced production time from about 10 minutes per authority to 5 minute for all 80+ authorities with the files posted to the server for anyone to access.

I also looked at creating the blackspot tables on a more automated basis, were more uniform and in similar format to the charts/tables in the data reports.
This was done by creating files of the blackspots for each authority from CAS which were then imported into an Excel spreadsheet which could then define how much of the blackspot information could be displayed by number of crashes at sites or the social cost of the crashes.

There was also the ability to select sites on the types of crash (injury/non-injury).

Somehow, I acquired the responsibility for all the data reports and was thus able to create all authority report incorporating the blackspot tables in relatively short order.

I also tried my hand at creating the specialist report and succeeded in doing individual data reports for pedestrians, motorcyclists and trucks which were well received if not widely used.

We were posting the reports to NZTA’s web site and I believe some of the reports are still available if you know where to look.

It was proposed that there be an interactive posting on the web site that would enable anyone to obtain crash data information and download a spreadsheet of the information they wanted.
The spreadsheet was duly produced by an outside contractor and it accessed the MDF but it seems no one maintained this as no MDF was produced after 2010 and the program only used data to 2009 and the version on the web was a beta version.

There was also another web based program that could get data down to the suburb level but the data was somewhat limit as I recall and I do not know if that has been maintained."