Improvements I would like to see; where others have also mentioned these points I have not expanded on the topic.

1) More flexibility in the fields available for use in the Import Wizard.

2) More fields to be available within the Report Wizard.  In particular the following:
   a) Reference documents.  In the case of our transfer of data from Recorder 3 the reference for each record appears in the Observations hierarchy view against Taxon Occurrence-Sources, so we would like the appropriate fields for author, year and title, etc.  at least included, but there is probably a case for including the fields for Sample-Sources, Event-Sources and Survey-Sources.
   b) Keys.  Being able to output Taxon_Occurrence_Key (likewise Sample_Key, Survey_Event_Key, Survey_Key) would be of great help, so that when a possibly erroneous record is spotted in a report, the key could be used in conjunction with the GoToKey addin, to check the original record.  There will be times when I wouldn’t want to do this direct from the report wizard grid (Charles’ point 2.2.2) which would also be a very useful feature.

3) Direct connection to MapInfo, with option of plotting record at centre of resolution, (preferably resolution size related).

4) Batch updating and manipulation.

5) I don’t know if it is the Recorder team or the NHM Species Dictionary team who set the Recommended Taxon Sort Order within Recorder 6, but where a published taxonomic order is available, could it be followed.  The checklist available on the BSBI website is taxonomically ordered yet the Recorder 6 preferred Vascular Plants and Stoneworts list is ordered alphabetically for any taxon rank below phylum.  Likewise the Bryophytes list at all levels.  The lists for Birds, Lepidoptera, Odonata and Reptilia do seem to be ordered taxonomically at all taxon ranks.  The inconsistency is frustrating when reporting across all taxonomic groups; I regularly resort to using a lookup table of the old Recorder 3 SP_CODE.

6) Concatenating into a single column for ‘observation measurement data’ and ‘observation measurement qualifier’.

7) Continuing on from Charles’s 2.3.5, for the Taxon Occurences I find the easiest way of checking another persons data entry is the order in which it was entered, so could the Taxon_Occurrence_Key be a sorting option besides Scientific Name and Common Name.

8) A higher level grouping of surveys, using the ‘tagging’ option.  Currently, our surveys are nearer to a dataset level.

I also have a couple of comments which I have not seen raised before, where a minor change to what is shown on some tabs in the Data Entry windows would make a big difference.

9) Sources tabs. Internal Documents shows Document, Original and Type.  We have a large number of references which are effectively the same author and with almost identical document titles but it is the year which distinguishes them.  The Author, Year and Document Title would be of more use as the visible fields.

10) Locations. Geo Info tab-Administrative Areas and Grid Squares tabs.  Would it be possible to make these sortable so that e.g. the parishes are grouped together alphabetically, or all 1km squares listed together in order.  We have many large sites that cross several parish boundaries or fall in more 1km squares than are shown in the available space and I have recently wasted quite a lot of time scrolling up and down checking through out-of-order lists.

Alison Stewart
Environmental Database Manager
Dorset Environmental Records Centre

Charles,

We do practically all of our data searches in MapInfo and have exported flattened records from Recorder 2002 to produce various GIS layers, the two most often used being:

“All Records” – Everything held in R2002 – Currently 532,000 records.

“Notable Records” – Rucksack-maintained list of species that we think consultants should know about in data searches – About 38,000 records.

In the course of creating these layers the grid ref is converted to three additional fields: Resolution (m), X and Y, with a “5” inserted at the relevant place in X and Y to map to the centre of the record’s resolution. Thematic maps can colour the resulting dots according to resolution. (Square polygons of the record’s resolution size might be a desirable alternative, but I don’t yet have the skills to know how to produce).

As far as I know the ability to produce these three fields is not in Recorder wizards/snapshots and so each LRC must devise their own methods of getting records into GIS. I bet there’s a lot a wheel-reinventing by busy LRC staff which could instead be provided centrally by R6 developers or best-practise shared by LRC super-users.

Another example - I’m considering linking JNCC’s latest (11th Oct) spreadsheet of species designations (http://www.jncc.gov.uk/page-3409) to R2002 and MapInfo so that we can display records of any designation(s) against layers of Sites, Habitats, Soil types, Districts, 1:10000 maps, MasterMap, etc. We increasingly want to interrogate records in GIS where they are most useful.

Ideally GIS tables would be produced from “live” Recorder data such that the MapInfo user wouldn’t have to do anything (or much – just a button press) to get the latest records on their screen. (If we had MapBasic and I knew how to program it then such things might be possible. I'm seeing what I can achieve via DBMS, but as its all self-taught experimentation in snatched moments, I could easily be heading up a cul-de-sac).

On a philosophical point I would suggest though that R6 should be kept as simple as possible, following the KISS principle (Keep It Simple (and) Stupid) so that it is robust, maintainable and efficient, and that fancy features, such as GIS-aids, should be kept separate for the smaller subsets of folk that need them.

Regards,
Keith Balmer
Beds and Luton LRC

Here are some ideas that could help facilitate these requirements (which are very similar to requirements here in Sussex too):

1. Add eastings (& eastings centred), northings (& northings centred) and grid resolution as report wizard attributes.

1.1 As an addition to this, it would be useful if Recorder could output a GIS layer (a .shp for instance) showing a grid square at the appropriate resolution (see how the NBN Gateway plots records for an example of what I mean). If this were implemented, each grid square would need to be able to refer back to the data that created it, so one of the attributes of the layer would be a sample_key or taxon_occurrence_key, thus allowing it to be joined to the snapshot or database.

2. Filtering in the report wizard is improved to include filtering by group and designation(s), and to allow specification of filters through control lists (as when entering a record) instead of free text. This would make reports/snapshots much more effective and flexible.

3. Enable XML Reports to be output to a snapshot.

4. Allow for snapshots to be run on a schedule (overnight, several times a day, etc.)

5. Allow for a snapshot to be triggered externally on demand; i.e., from the command line or another application (like MapInfo or ArcGIS).

The good news is that no. 1 can be done already (we have those attributes in our report wizard). They were added by Mike Weideli, so if you're desperate for them, do get in touch with him. He can also add other attribs; just ask and he'll tell you if something is possible or not.

In regards to the GIS accessing the latest data live, that, I'm afraid, is something that could only be accomplished in the GIS itself really. As Keith pointed out, it would need to be done in MapBasic on MapInfo and on ArcGIS there are various ways of doing it (as a VBA extension, or .NET extension or similar), but it's stuff that would need to be built into the GIS rather something that could be built into Recorder. Exegesis are probably you best best for that sort of work.

Having said this, it is possible to build a View in SQL Server and then use MapInfo to connect to that view. I've done this in ArcGIS, but because views are queries that run on-the-fly, it's very slow unless you build highly constrained views that pull out only relatively small chunks of data. I think a better solution (for now) to viewing live data is the facility as described above to run snapshots on a regular schedule. If you needed completely up-to-date data, you could always go into Recorder and run a snapshot manually and thus give yourself the latest data.

Hi

I would like to add my small contribution to this thread:

- The import wizard should check that the records to be imported do not duplicate records already in the system (not just do a check for duplicates in the import file - not especially helpful to me).

- A 'search and replace' facility to move all records of species 'a' in Checklist 'A' to the relevant species name in any new Checklist.

- Improved reporting options (eg I wish to get a list of observers who have contributed records in a year - I cannot find a way of doing that with the Report Wizard). Perhaps a set of instructions to prepare queries in Access to check the R6 database - currently, I have no idea how to tackle this).

Cheers, Ian