First, can I just say thanks for the input from everyone on this thread. John, it's a real step forward being able to communicate with you directly and getting such useful feedback in this fashion, so many thanks for this.
Here are my thoughts:
Editing saved reports
This can already be done if you build a query using the Report Wizard then, at the filter results screen, select File > Save As. On subsequent running of the saved report, the back button can be clicked to go back and edit attributes. However, I'm assuming the reports saved using the template designer is the problem here. The attributes for these cannot be edited? I have very little experience with the template/report designer, so I'll have to bow to others' experiences here, although being able to edit attributes associated with saved templates would make the report designer more useful as a tool. Would this not cause problems whereby a report expects an attribute you have subsequently removed? The CCN that mentions being able to save out to Access and Excel would also make life more flexible in these areas.
Flexibility in specifying areas to query on
The points Darwyn raised resonate with me. We too need to report on grid squares, lists of grid squares and bounding boxes. John's suggestions sound like good solutions: being able to type in a list of references, specify a pre-existing list of references, and saving a list of references from the report wizard are all highly desirable.
Snapping to grid lines for bounding boxes would be very useful, as would making bounding boxes available to the report wizard. I would add to this, being able to draw and/or specify a radial bounding box would be another essential selection method. We are increasingly asked for data drawn from a single point or site with an xKM buffer. E.g. "give me all bat records within a 5KM radius of this site". A natural enhancement to this idea would be the ability to specify a buffer around a polygon, e.g. when selecting a polygon to use for a report, prompt for a buffer value. But perhaps this is beyond the capabilities of the GIS component within Recorder. Buffering a polygon or point is certainly easy enough to do in a GIS app, so I would place this functionality with a lower priority, but if the GIS component in Recorder is able to easily create buffers, then it would cut out an extra step and the creation of new polygons. It would also enable those without GIS to access some crucial reporting methods.
Being able to use polygons with XML reports would be a very welcome addition. Again, being able to pass a point (actually, a whole grid square) or polygon with a buffer would make this even more useful.
John: on the subject of reporting by polygons, how is the selection of grid references handled? Specifically, does a point get selected if a point sits within the poly, or does the point first get converted to a square and then that square is used as the basis for the selection. E.g. if I have a tetrad reference, does it get selected if any part of the tetrad is intersected by the selecting poly, or does it only get selected based on the actual origin (lower left corner) of the tetrad?
To round this section off, here's a summary of the kind of geographic area reports we get asked to do on a regular basis:
- a grid square
- a range of grid squares (contiguous or separate)
- a bounding box
- a linear feature (usually with a buffer)
- a point or grid square (with and without a buffer)
- a polygon (with and without a buffer)
Would others agree with these? Have I missed any?
Reporting on species with a particular or range of designations is crucial to the work of LRCs (and other orgs) - this is a clear business use. In addition to being able to specify a list of designations for XML Reports to consume, I'd like to be able to specify a list of designations as criteria via the Report Wizard. In addition, being able to see what designations apply to taxa is crucial. I like the newly added ability to select designations to include in a report (Darwyn, it's in the latest test version of R6 - 6.7.x), but it is a very unwieldy if, for instance, we simply want to discover all designations that apply to a particular species. Further to this, there are many designations that are irrelevant (and will nearly always be so) for a given region or organisation, so there's a need here for some sort ability to select (semi-permanently via, for example, a rucksack, a table or XML file) only those designations we're interested in working with. This problem with designation overload looks like it could get even worse with the internationalisation of Recorder. At present, if I dutifully tick all designations I'm left with a huge set of tabular data full of mostly empty columns, or at least empty cell and it is quite difficult for me, or the reader of any resulting report, to read and make sense of it. Which nicely brings me onto...
Mike Weideli has written a UDF and attribute for the Report Wizard that builds a field with all designations that apply to a taxon in a concatenated and semi-colon delimited form. This is restricted by a table that specifies what designations to include, but it is a) extremely slow and b) difficult to select and/or change those designations required. Some sort of index would possibly be required to speed up the processing of the query, as would an ability to easily select, change and save multiple sets of designations.
Finally, the designation KIND is often more usable in a report that the full designation, although this is a personal preference as the abbreviated short form of the designation when concatenated is easier to present in a tabular report. Perhaps others agree that kind is a useful field that shouldn't be forgotten here.
XML Reports in general
This is a very powerful addition to Recorder, but I do agree with Darwyn that many more queries should be present 'out-of-the-box'. Replicating those available by default in MapMate and the old SQL Reports would seem to be a sensible benchmark. In addition to this, comprehensive and clear documentation is required. Mike Weideli has written a good starter tutorial, although I don't think he's publicly published it yet. As the number of reports under the 'default' category grow, some sort of hierarchy view in the same vein as SQL Reports would make things more usable.
The knock-on effect of any reporting improvements should be that result sets can be 'snapshotted'. An enhancement to the snapshotting functionality that occurred to me would be for some sort of command-line driven trigger or schedulable action that could be invoked to enable, for instance, overnight runs. The ability to save the SQL that generates the snapshot might be a good solution, then this SQL could be fed to SQL Server as a scheduled action.
Whew, I think that's all for now. Darwyn: all these ideas will need to go to wider consultation eventually, but that shouldn't slow down the flow of ideas here. With our combined efforts and John's feedback we can hopefully build a set of proposals that can later be put to ALBIC and others. As I'm sure you're aware, any developments for Recorder need to be funded somehow, and it's only though combined funding from LRCs and other interested organisations that I envisage progress can be made. A little contribution from a lot of orgs can go a long way. I'm not sure how JNCC fits in, but I understand that there is only so much budget available for Recorder development and most (all?) of this is purely for maintenance, not new features.