Topic: Recorder Wishlist

Recorder now has its own dedicated website. One page on this website is the Future Developments page which lists ideas for added enhancements to Recorder along with a (very rough) cost estimate.

In order to help extend this list and get a better idea of what people really want from Recorder I thought I'd create this thread. If you think of anything you'd like to see added, changed or enhanced in Recorder, add it to this thread. You don't need to ponder on it for too long - if you have an idea, note it down here. Think of it as an on-going braindump of ideas.

Re: Recorder Wishlist

I'll get the ball rolling:

At present, columns returned by the Report Wizard are returned in a somewhat random order - they're all over the place. It's possible to re-arrange them by dragging and dropping, but rerunning the report after saving (File > Save As... on the Filter Results screen), the column order is lost. It would make sense if the column order got saved along with the report. Also, while I'm on the subject of saving reports, a 'save these report attributes' button next to the 'report output' icon or on the final 'summary of selected options' page of the report wizard would make it clearer that reports can now be saved for later use.

Re: Recorder Wishlist

Another one:

In the taxon dictionary browser, it would be useful to have a search facility that searches for taxa across checklists, not just in the currently selected one. It would work in the same way as the Find Taxon dialogue that gets opened when typing in a taxon name or abbreviation in the data entry screens. On selecting a taxon from the find taxon dialogue, the relevant taxon dictionary and taxon would be opened and selected.

Re: Recorder Wishlist

In the new import wizard, at the Species Matching Page, it would be useful if we could search on preferred checklists, rather than having to manually specify a checklist to search on.

Re: Recorder Wishlist

Now we have the new TAXON_GROUP table, it would be very useful being able to setup export filters based on one or more of these groups.

Re: Recorder Wishlist

I've started to look at the costs for the first few of these, and have updated the Recordersoftware.org website to include the suggested changes.  It will take a few hours for the update to appear though.

John van Breda
Biodiverse IT

Re: Recorder Wishlist

Editing saved reports.
Picking up on a thread that I think Ellie Bremner kicked off in the eGroup in August last year. A blindingly obvious facility that later messages seem to suggest has disappeared from later versions of Recorder and is certainly not in R6.
The request was "I want to set up a standard report, so that I can get data out of a particular survey using a bounding box or polygon.  I want to have a standard report that I can just change the bounding box - I don't want to have to go through the list of attributes each time." Charles replied with "... alas, you can't" and suggested using Access - which is not so easy an option with R6. I watched this thread with interest and felt Ellie's frustration keenly when she remarked "or is it because no-one thought that we want to edit reports?".
Charles put the suggestion succintly as "What I would like in Recorder is, very simply, the ability to save the attributes one selects in the Report Wizard so that one is then able to open up those report attributes in subsequent Report Wizard sessions, edit them, make tweaks to the filters, change a taxon group, change a polygon, etc, etc - a bit like saving a template for the import wizard. At present, you have to recreate a report each and every time you open Recorder, which is a major time-waster." he later called this feature "blindingly obvious" - a feeling that was supported by many others and isn't in the Future Developments list.
Fundamental features like this should be first in line for upgrading in Recorder as they relate directly to an LRC's ability to deliver services and LRCs don't have that time to waste.
I want to report on clusters of named 1Km squares - I had this as an SQL in old Recorder, let's see it built into a new reporting system.
How about scrapping the Report facility in Recorder altogether and building Crystal Reports into it. With the amount of time we've wasted on just this aspect so far, Crystal Reports would have paid for itself several time over.
TIP 1. Right click on a Location and you can perform a Quick report on it - which only gives records linked directly to that named location and not to its children. Anything other than a rigid location naming convention or an enquirer wanting a buffer zone around a location and this facility is only marginally useful.
TIP 2. Clear out your old .wzd files from your "queries" directory when you first get R6; one dodgy one crashes your Quick reports everywhere

Darwyn
LERC

Darwyn Sumner

Re: Recorder Wishlist

Darwyn,

I will try and spec out a change which covers what you want over the next couple of days and add it to the future development list.

As to your suggestion for using Crystal reports, there is nothing stopping users who wish to purchase the product from using it against their database.  But using it as a replacement for the inbuilt reporting facility is not likely to happen because to my knowledge you have to buy a license to design reports in Crystal and there is no royalty free option.  Also, in my experience within IT generally many users of Crystal are not that happy with it as a product and Microsoft's SQL Reporting Services is making huge inroads into Crystals market share.

Finally, the Quick Report facility was designed to be a flexible, extensible way of plugging queries into the front end in a quick and easy way.  Unfortunately not many users have taken up report writing with this facility, possibly because they are intimidated by the XML aspect of it (which is actually very easy, once you have written the query which can easily be done using Access' Query designer).  The report you mention was just written as a demonstration of the technology by myself, originally for testing, but we included it in the package to give an example to other users.

John van Breda
Biodiverse IT

Re: Recorder Wishlist

Darwyn,

I have sketched out a few ideas for changes which I think will make the reports much more useful for you in the context of what you describe above.  Before I go ahead and spec these out properly, what are your thoughts on the following?

1) Change the format of a saved report in the wizard so that it holds the state of all the wizard screens, not just the SQL it generates.  On subsequent loading of a report, use the saved state to allow the user to return to the wizard pages, change settings and re-run the report.

2) Enable the XML reports to integrate with the Map Browser window

John van Breda
Biodiverse IT

Re: Recorder Wishlist

There are some very good and useful suggestions there, John.
In terms of this kind of work we are driven by the demands of customers and the kind of information they want and we'd like to carry out this work as quickly and smoothly as possible.
The driving force for us LRC operators comes from these people - here's a few notes on this as it may help focus the direction of development (hopefully others might chip in on these observations).
In terms of species reports they want the simplest possible means of specifying the area of study and experience has shown that they can be trained to use OS maps and give us a list of 1Km squares (e.g. SK1234, SK1235 etc.); ask them for more complex things like GIS layers, specifications of buffer zones, circles around points and life becomes complicated (especially since we have to match the study area with a map using another application).
In the regular work we carry out, the first report for them is in the form of an area summary so there are things that are not asked for in the bulk of our work, and so reports on polygonised locations (which Recorder seems to be fine at) is very much of secondary importance.
So firstly, in terms of defining the area of study we have a few problems:
1. The bounding box will not deal with long "diagonal line study-areas" which means that only some of the requests can be dealt with using this system (actually the majority of them).
2. We can draw a shape onto a "commercial" layer on the map and use this to define the study area. This would be an ideal way of dealing with complex shapes but the processes involved are also complex; the shape drawn is imprecise if it is done using the quickest method - in Recorder (believe me they do complain if one is not precise) so a suggestion might be a "snap to grid line" option here.
3. We can have a layer of predefined 1Km squares and report on a mutiple selection (I have made these for all the country so sourcing the layers is not a problem)
4. There is the SQL reports option which I had in Recorder 2002 in which a linked table referenced multiple 1Km squares to one Job Number (Mike Weideli commented on mine and said several people had done this kind of thing - so 1Km square reporting isn't just my idiosyncracy). There is no doubt an XML solution to this but we do need more sample XMLs bundled with our installations and we may need some sort of standardised table to do this linking
5. I'm avoiding the drawing of shapes in external GIS applications and importing the mifs as this is time-consuming or too demanding on the customer, although we do have to use it from time to time.

Secondly we have the categorisation of the species we are reporting
Full lists of species are of interest to no-one (apologies to phenologists and those who like to see huge lists of Episyrphus balteatus but I am writing about a business application in a business context here).
1. The primary driving force for such categorisation is Government Policy and Legislation and customers want this almost exclusively although we perhaps want a say in conservation and therefore secondarily we want our Red lists.
Our customers, therefore, want WCAct and BAP exclusively in a list.
Currently I have to maintain rucksacks to produce these reports. If I use "Taxon designation type" & "Kind" I want to see WCAct output if I enter it as input in the filter, not, as occurs now, some Northern Ireland designation. Whatever the background reason for this, the fact remains that it's a fault which needs solving as it makes the statuses provided with the species dictionary unusable.
2. On the matter of the secondary lists of IUCN & Nation "Kind"s we need to see all statuses incorporated into the species dictionary. Not Dorset software's responsibility I realise but probably JNCC's; they have for example just published the "Review of scarce ..." on Empidae but I cannot access these statuses through Recorder.

Thanks for your kind attention, John, I look forward with interest to other's comments on this topic (Charles!)

Darwyn

Darwyn Sumner

Re: Recorder Wishlist

Thanks for your reply Darwyn.  Its important that we, the developers, understand the underlying business uses of the application so this is useful information.

Based on your notes, here are a few more suggestions to throw in to the pot.
5) Add a page to the wizard that allows you to specify a list of grid squares as a filter for the report, simply by typing.  Allow this list to be saved and loaded to an XML file for later re-use (a bit like the specification of polygons that you can save when reporting).
6) Allow XML reports that use the aforementioned SampleList where clause type to link to a map or a sample to be also run from the Run Reports dialog.  When accessed from this dialog, Recorder automatically generates a parameters screen with a box allowing you to type in grid squares to run the report against.  Therefore it would be easy to run the XML reports against lists of grid squares.  If implemented alongside 5), then the same XML files could be used to save and load lists of grid squares.
7) Provide a modified version of the species list XML reports supplied with Recorder that only lists species which have one of several identified designations, identified by a csv file listing the designation keys.  Supply csv files which identify wildlife & countryside act, red data book designations and so forth - the user can select the appropriate file when they run the report.  (Incidentally, this can all be achieved through the XML reports without updating the core code - a challenge for someone!).
8) Enable a 'snap to grid' facility when drawing map polygons, with options to snap to 10m, 100m, 1km.

Any comments?

John van Breda
Biodiverse IT

Re: Recorder Wishlist

It's looking good, John. I'm in favour of letting Dave Cope and Charles Roper have time to chew over this one before you and I get too carried away.
It needs the thoughts and comments from a wider group of LRC people too so I'll bung a note to NFBR and the Association for Local Record Centres (ALBIC). I'm afraid this wider consultation might slow down the flow of ideas a little but it protects us from later chastisement.
Cheers
Darwyn

Darwyn Sumner

Re: Recorder Wishlist

Your last point 5) is beginning to grow on me.
If you're familiar with ExeGesIS' Map Templates for MapInfo then you'll see that they have "user-definable" fields which drive through to the report. So in that 1Km square specification panel you'd need a handful of these: Job Title, Job reference, Section number (for use e.g. on long motorway jobs when the customer likes the report breaking up into surveyable sections). In addition your "simply by typing" could be improved by allowing delimited text strings (e.g. grid references separated by commas) pulled out of their Word file and Excel copy and paste.
Darwyn

Darwyn Sumner

14

Re: Recorder Wishlist

Sorry guys, I've only just come to the table..been keeping 1/2 an eye on the discussions as I'm working on other things. Hopefully get a bit of time to read it all carefully tmrw. Some good comments here.

John, sorry this is a bit of topic, but whilst your here....I've been meaning to comment on the technique of using

Re: Recorder Wishlist

Lots of good discussion here - I will read and re-read it to properly digest it all. Darwyn, you've touched on a couple of really important issues: 1) more flexibility in specifying the area on which to query and 2) working with designations. Both big issues here in Sussex and I know in other LRCs too. I'll take some time to formulate a reply.

Dave: you're right about the IN clause, it did cause a stack overflow on large polys with lots of samples. It was caused by a bug in SQL Server 2000. I reported this a while ago and it appears to have been fixed in the latest test version I have a copy of. I would assume John's proposals above would take this into account.

Charles

Re: Recorder Wishlist

Charles,

You are correct, an incident (JNCC696) was raised and has been fixed in release 6.6.9.  This fixes the problem where reporting on polygons containing large numbers of samples causes the stack overflow error described here.

For anyone interested in the technicalities of this, the way around it is to create a temporary table, insert all the keys into it required for each sample, then join it into the query using an INNER join to filter for the correct samples.  This way the query size does not grow as you add samples so there are no limits.

Also, a note for Dave, when filtering a polygon we do indeed initially do a quick 'pre-filter' based on the bounding box of the polygon, then do a secondary filter to find the samples that lie inside the polygon.

Another thing to note is that Recorder 6.7 contains a new set of report attributes, one for each taxon designation type.  These allow you to add a column for a WCAct or similar with 'Yes' in the cells against any taxa that are listed against that designation.  This might be useful for you, though I doubt it will solve all the designation reporting requirements discussed here.

John van Breda
Biodiverse IT

17

Re: Recorder Wishlist

Thanks for the resolution of the stack overflow problem John. The report attribute for taxon designation types will be very useful.
I'll have to obtain the update as we have 6.6.8.59

Thanks for the note about the spatial search. I do a similar thing here within our IMS system - the key fields from the sample table are mirrored from Rec6 to PostgreSQL, which has spatial queries. The result set of sample_key and survey_event_key is passed back to a procedure to build the model back up from Recorder.

Re: Recorder Wishlist

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?

Designations
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.

Snapshotting
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.

Charles

19

Re: Recorder Wishlist

I think I'll second both Charles and Darwyns comments. Good ideas that anyone would wish to see. I'm also a report wizards novice and therefore I'm hestiant to comment without sitting down and thinking things through (and it's nearly going home time!). I've built our own in-house reporting system here so maybe that would be my starting point.

Generally, we do selections by geography, contrainst layers, status and species. Almost every geographical select has a buffer which is reported on seperately. We format the report with custom headers depending on who the report is for. Report metadata I guess.

I'd also like to comment that building a general reporting tool which will satisfy every users is going to be tough. The pre compiled report idea is a very strong one, and having the opportunity for John and/or users to be able to plug-in (and share) more "standard" reports would be fine.

Like I say, I'd like to think on a bit more about custom reports and the interface for them. - Is there any deadline for this or are we brain storming?

Re: Recorder Wishlist

Just brainstorming. smile

Be sure to check out XML Reports for the custom reporting side of things. This feature already allows us to plug-in custom reports using XML to 'hook' queries into various elements within the UI. To create XML Reports just requires someone with a decent knowledge of the the Recorder db, some basic XML knowledge and some time on their hands.

Charles

Re: Recorder Wishlist

Charles, I notice you mention that you can go back and edit attributes of a saved report.  If you use the Report Wizard, you can load the attribute list from a previously saved report, but you can

John van Breda
Biodiverse IT

Re: Recorder Wishlist

Just one small Windows thing that needs fixing. If you open another programme whilst the Report Wizard is running, the RW window disappears and Recorder will not respond. The only fix is to shut down that second program and then the RW window pops up again.

Darwyn Sumner

Re: Recorder Wishlist

Report wizard attributes
I'm missing a number of attributes in the Report Wizard ("all information about a place"! - ?) that I consider fundamental in building a report in this way:
1. Location: File Code (our one and only way of identifying a geospatial object or differentiating between Locations of the same name)
2. Location: Designations (bang goes any possibility of providing background details in the report concerning BAP and Local Wildlife Site designations, their dates and authorities)
3. Location: Comment
4. Sample: Type (depends how you use this and it may be that some might think that Survey: Survey Type is a sufficient alternative but we need to differentiate between different professional/amateur sampling methodologies such as "Community surveys", "Phase 1" surveys, "Local Wildlife Site", "BAP" surveys etc. as this provides an additional tier of qualification against which to judge validity whilst removing the need to shuffle Events between Surveys in order to provide a category which rightly applies to the Sample and the Recorder who carried out that work.)

Rincewind (novice wizard)

Darwyn Sumner

Re: Recorder Wishlist

Darwyn,
The attributes you require could easily be added to the report wizard - Mike Weideli has already done some (not the ones you need though) that are available on his website. I'd suggest giving him a call. John: perhaps as an extension to your moderator for XML reports, you could also extend this to report wizard attributes with a view to including them officially?

Regarding the running of saved reports, I didn't realise you couldn't edit them if you choose the Run... method. Darwyn: have you tried pulling up a saved report from the layout selection screen of the report wizard? It's the screen with a drop down menu that is initially greyed out. You select the second radio button and choose your saved report from the drop-down. When you click next you're fast-forwarded to the last stage of the RW. You can then click back to edit attributes.

John,
Your list looks good. Regarding the selection of points, how feasible would it be to first expand a point into a square, then select that instead of the bottom left corner? I realise this is (sort of) straying into GIS territory, but selecting the bottom left corner of a grid-ref square is a fundamental misconception of what a given grid-reference actually is. That is, when a recorder refers to TQ2113, what they're actually referring to is 'anywhere between TQ2113 and TQ2214 (or TQ2199913999)'. If you go this route, though, then there's the inclusive vs. exclusive selection argument. Do I include all squares that (fully and partially) intersect my polygon, or do I exclude squares that are not entirely within my polygon. Ideally it needs to be an option. I view this as a fundamentally important concept when selecting spatially, but it's often glossed over.

Here are some quick notes relating to your points:

1) Saving the column order of reports should also be rolled into the improvements to saved reports. This is a different CCN at the moment, but from feedback I've had, this is quite an important issue.

2) Where exactly would the user click to get the right-click menu? Anywhere within the poly?

6) Just a clarification on this one: we would need to specify multiple designations, and/or (ideally) designations of a certain KIND or region. Eg. be able to select all IUCNOld or all UK designations, again with the ability to multi-select and also to save a selection. But if a selection is savable, then perhaps this isn't such a big requirement.

12) I love the idea of RSS functionality (pat on the back for whoever thought of that one), but to clarify, do you mean allowing Recorder to access pre-written reports from a repository on the web?

13) This would make tighter integration with GIS much more accessible to more people, as would point 14

Charles

Re: Recorder Wishlist

Printing:
Can we have a few more Print options in the File menu. My PC is set up for Adobe pdf as default and it's a nuisance having to remember to change it before sending a Recorder report to the printer. I'm sure these are fairly standard "off-the-shelf" dialogue boxes.

Darwyn Sumner

Re: Recorder Wishlist

It

Rob Bradley
Edinburgh

Re: Recorder Wishlist

This is a classic example of the problem with selecting by polygon. John's suggestion of using the grid refs associated with a location as the basis for the search would be one solution. However, getting these grid refs in place would be a time consuming process on large datasets. I think Kent BRC have plans to get a tool produced that will work out the gridrefs associated with a location based on a polygon.

Re: Recorder Wishlist

A little more about "Report wizard attributes"
The more I explore this, the more fundamental stuff I find missing.
Let me just outline the ideas about what I want to get out of it - the "business context" seemed to ring bells in previous messages.
We carry out the administrative and database work for our region's Local Wildlife Sites (or SINCs or SNCIs - call them what you will they are the non-statutory sites that form the core of the sites work in an LRC and they are (or should be) intimately associated with the region's Habitat Biodiversity Action Plans. Both of these are of great importance in terms of LRC work as they relate to our data provision to partners for use in Planning (for which these partners pay through Service Level Agreements), our data provision to commercial enquirers for the same reasons and to provide a guide to our surveyors. They are also key elements in current legislation and so the demand for information about a Site is enormous - far more than information about species.
Thus we need to have a strong emphasis on the management and characterisation of Locations within Recorder. To deliver appropriate services we make extensive use of the following:

1. Designations - to track LWS designations as sites are proposed, ratified, monitored and destroyed; to cross reference to previous or external designations such as Phase 1 survey designations or English Nature's Ancient Woodland inventory; to tag candidates with HBAP for future LWS work which might later provide the fieldwork which assigns a biotope.
2. Measurements - e.g. hedgerows under hedgerow regulations, ancient trees
3. Other info - of prime importance is Land ownership under "Tenure"
4. GIS - there's nothing even in the data model to relate to this except a single "File code" field

Part of our work for the LWS partnership includes the provision of key Location/Site information to enable the site to be surveyed in the first place and to follow up with evidence that we have gathered together the necessary information about a Location for it to be ratified.
We have the necessary data model in Recorder to move away from a time-consuming "citation"-based system in which all this is typed into a Word document (linked into Sources) to simply entering it into Recorder and compiling a report.

All the current Wizard offers is species and/or biotopes. There is absolutely nothing which can be pulled out of this system which is related to the Location itself.

Darwyn

Darwyn Sumner

Re: Recorder Wishlist

Recorder 6 Import Wizard function. It would be good if it could include additional fields to import, namely start time and duration into the Sample and weather information into the Event. We regularly receive hundreds of records with this information and to include it in the import process will save a lot of editing after it has been imported.

Cheers

Brian Miller

Data & GIS Officer, BBOWT

Brian Miller
BMERC Manager
www.BucksMKERC.org.uk

Re: Recorder Wishlist

Darwyn, whilst looking at this I noticed your point about getting access to Location Measurements from the Report Wizard.  You can include Location Measurement columns in the Report Wizard - they are under the "Sample" node in the attributes list, at the bottom under "Location Measurements".

Best Wishes,

John van Breda
Biodiverse IT

Re: Recorder Wishlist

I move lots of locations about in the locations hierachy, between parishes, SSSI's and wildlife sites, that sort of thing.

I'd like a 'promote one level' command like the 'promote to top level' command we have right now,
or maybe the ability to drop a location on the grey lines to the left of the locations list and it appear in the relevant upper level. That would be snazzy.

Best wishes,

Lizzy Peat
HBIC

Re: Recorder Wishlist

I would also really like a longer history of changes, at the moment we have 'The record was created by Lizzy Peat on 20/11/2003 and was last changed by Darwyn Sumner on 19/04/2006.'

I would like it to say;
'The record was created by Lizzy Peat on 20/11/2003, changed for no apparent reason on 10/06/04 by Darwyn Sumner, changed back by Lizzy Peat 20/03/05, renamed on 23/04/05 by Darwyn Sumner, re-numbered on 10/03/06 by Lizzy Peat more records added by Lizzy Peat on 16/03/06 and was last changed by Darwyn Sumner on 19/04/2006.' For example. (Of course I've only used Darwyns name as a purely fictional example and this bears no similarity to real people living or dead.)

I would settle for a longer list of 'changed by **on **'
We can forget the 'what' for the moment, and ignore the 'why' unless we can install a mind reading bit of kit. Oooh can we?

Wishing,

Lizzy Peat
HBIC

33

Re: Recorder Wishlist

Lizzy Peat wrote:

I would also really like a longer history of changes, at the moment we have 'The record was created by Lizzy Peat on 20/11/2003 and was last changed by Darwyn Sumner on 19/04/2006.'

I would like it to say;
'The record was created by Lizzy Peat on 20/11/2003, changed for no apparent reason on 10/06/04 by Darwyn Sumner, changed back by Lizzy Peat 20/03/05, renamed on 23/04/05 by Darwyn Sumner, re-numbered on 10/03/06 by Lizzy Peat more records added by Lizzy Peat on 16/03/06 and was last changed by Darwyn Sumner on 19/04/2006.' For example. (Of course I've only used Darwyns name as a purely fictional example and this bears no similarity to real people living or dead.)

I would settle for a longer list of 'changed by **on **'
We can forget the 'what' for the moment, and ignore the 'why' unless we can install a mind reading bit of kit. Oooh can we?

Wishing,

Hi Lizzy.

What your asking for is a for is a form of transaction logging and I fully support that request. Having logs is *so* important to an LRC, not just when things go wrong (as they do), but to track changes within the data. This applies to any form of automation - e.g. imports. What was imported, when, by whom, what was rejected - why?

I'd also like to see a simple form of version control. When data is edited the old data is marked "not current" and the new data takes its place. The log should reflect that. Its something I try do do for my own systems. The other thing that this allows is the possibility of (either manually or via critiera) to mark records not current and keep them "out of sight".

What I do in my database is exactly that, with the option to copy non current data to a secondary database. The general idea is that data is never deleted directly. Non current data can be purged at a later date (by a sysadmin) when one is really sure that it is what is needed. There is then a backup anyway. (Until that is purged too!).

Presently Recorder holds its "changed on" data as fields within individual tables. For the type of logging advocated here I imagine Recorder would need to be modified to hold this data in seperate tables. I undertand MS SQL server has transaction logging so maybe there is a way for Recorder 6 to store relevent entries from that into a human readable form.

I doubt we would see this in Recorder 2002.

Re: Recorder Wishlist

Lizzy/Charles,

SQL Server does indeed have transaction logging, but this is only for the purposes of SQL Server's own internal processes so can't be used in the fashion we would require.  The way to do this would normally be using triggers on the tables which can trap any updates, deletions or insertions and record them in a new table.  We would need to think hard about what level of detail is required, for example, if you use the record card to enter a single taxon occurrence it could easily log additions to the Survey_Event, Sample, Survey_Event_Recorder, Sample_Recorder, Taxon_Occurrence, Taxon_Occurrence_Data, Taxon_Determination tables and more!  This amount of information would make the log hard to use.

Food for thought though!

Regards,

John van Breda
Biodiverse IT

Re: Recorder Wishlist

It was Dave, not me, but it still sounds like a very interesting feature.

Charles

36 (edited by Darwyn Sumner 24-04-2006 10:34:11)

Re: Recorder Wishlist

johnvanbreda wrote:

Darwyn, whilst looking at this I noticed your point about getting access to Location Measurements from the Report Wizard.  You can include Location Measurement columns in the Report Wizard - they are under the "Sample" node in the attributes list, at the bottom under "Location Measurements".

Best Wishes,

To be precise.
In the Location window I have access to six tabs which characterise aspects of the Location:
1. General
Name(s) - Preferred name is accessible through Sample only
File Code - inaccessible (and this is our reference to GIS polygon)
Type - inaccessible
Central spatial reference - inaccessible (bear in mind that this may be different to the Sample reference)
Central spatial ref (type) - inaccessible
Description - inaccessible
2. Designations
all inaccessible
3. Measurements
all accessible under "Location Measurements" (which is a child of "Location", not "Sample"), we use this extensively to characterise hedgerows and the like.
4. Geo info
all inaccessible
5. Other info
all inaccessible
6. Sources
all inaccessible

The solution would be a new parent "Location" in the "Select attributes" list.
Within this hierarchy would be children named after each tab (including the moving of "Location Measurements" to this new parent)
Filters should be enabled for all the fields.

To give a practical example of this, imagine a situation where surveyors are about to head off into the field to resurvey some Local Wildlife Sites.
From Recorder they are able to select potential survey locations.
They generate a print-out which contains all the information they need to carry out their survey efficiently, key facts they need are:
General: Grid reference, how this was determined plus any notes about the site (description) which makes sure they survey the correct side of the road for a roadside verge for example.
Designation: Is it currently a Local Wildlife Site, who says so, what's the reference to other bits of paper they might take with them, when's it due for resurvey (whoops! these fields won't accept future dates) plus any comments about the designation
Measurements: This lot is available for use in a print-out, it's also data which the surveyor is redetermining in the field
Geographical info: Administrative area might be useful to determine Parish but since our Location hierarchy provides this, it might be more useful to be able to access parents in the Location hierarchy
Land parcels would be terrificly useful as the surveyor could relate to OS maps they take out with them, we don't use this facility because we cannot get the information out.
Other info: Potentially very valuable stuff in here for the surveyor, Approach is surely designed specifically for this purpose and Tenure (i.e. details of Land ownership, whether permission has been obtained, who to speak to) is mandatory for all surveys
Sources: Further cross-references to electronic documents (though not to paper ones - see previous posting on this site)

All this material should be available for incorporation into a report which can be printed out, not just for the surveyor but also for evidence to the Local Wildlife Site partnership panel that the appropriate information has been gathered, otherwise the location will not be approved for designation.

Darwyn Sumner

Re: Recorder Wishlist

Dear All,

I have uploaded the list of change requests from this thread into the Future Development page of the web site.  See Future Development.

John van Breda
Biodiverse IT