There are two general complaints about the reporting interface. These relate to functionality, and amount of detail available.
The 1998 rewrite of the software focused on performance in the reporting interface. Some functional aspects were sacrificed in the name of the speed.
The critical speed factor has to do with avoiding recalculating the total distance each time the results need to be displayed. The method used to avoid this work is to precalculate this and store the answer in auxiliary tables. This sacrifices functionality as it makes it difficult to customize the report as much as desired.
The recommended fix is to avoid pre-calculation, but also to avoid duplication. This should be done by having an automatic process (a daemon) that accepts requests to do the calculation, and returns an appropriate reference to the calculated results in a database. All requesters that ask the same question (such as the default results) would get the a reference to the same (already calculated) answer.
This would have solved Nanaimo's problem: PR#429293.
The second problem relates to the need to accept partial results. The auxiliary tables that were created where augmented with another set of tables that would permit organizational tallys to be entered. This process needs to formalized at multiple levels: organizationally (both per mode, per day and week totals) and at the city level.
The spreadsheet input format is one such manner in which inputs are accepted. This needs to be generalized. The recommended data interchange format is through use of an XML schema.