1

Re: Why?

I'll kick off :)

What are the advantages of having a separate recording package for maritime users?

Charlie Barnes
Information Officer
Greater Lincolnshire Nature Partnership

2 (edited by stevemcbill 08-02-2010 15:51:15)

Re: Why?

A good question Charlie - something I have wondered myself ever since Marine Recorder was in testing.

Personally I would have thought that diversification of the software was not a thing to be sought and/or encouraged !

Steve

Steve J. McWilliam
www.rECOrd-LRC.co.uk
www.stevemcwilliam.co.uk/guitar/

3

Re: Why?

Marine Recorder was developed because R2k could not handle replicates (as they are used by marine scientists). MR has been around almost as long as Recorder itself and is currently at version 4. It is mainly used by the country agencies and their contractors. It is considerably faster to enter data in MR than Rec and the mapping & reporting tools are quite advanced. The data model has diverged somewhat from the original R2k
http://www.jncc.gov.uk/page-1599 & http://esdm.co.uk/MarineRecorder/index.html
One thing I do not like about MR is the fact that it is a suite of seperate applications and is not a single coherent package as R6 is. MR has one main app to store and input data, another to report, another to merge, another to create snapshots....

CyprianPayne
CCW

4

Re: Why?

It is perfectly possible to hold marine species records in Recorder, but it was decided some time ago that another application would be needed to enable users to record additional information about the sample that is of interest to marine users. Things like depth of water, exposure to tide and wave action, salinity, make up of the substratum - is it mud or boulders? This was also in order to hold data collected under the Marine Nature Conservation Review.

Hope that answers the question.

Paul

5

Re: Why?

cmp260 wrote:

replicates

Replicates? Please enlighten me! :rolleyes:

Paul Robinson wrote:

enable users to record additional information about the sample that is of interest to marine users. Things like depth of water, exposure to tide and wave action, salinity, make up of the substratum - is it mud or boulders?

But can't Recorder hold that sort of information?

Charlie Barnes
Information Officer
Greater Lincolnshire Nature Partnership

6

Re: Why?

Actually I'd say that yes Recorder can hold pretty much all the data that Marine Recorder holds (they use - or at least used to use - exactly the same data model after all) - though there was some requirement to understand how related data such as replicates were grouped together - that wasn't particularly easy to do in Recorder.

The main reason that certain types of marine data (particularly the more structured surveys) could not practically be entered into Recorder was due to the large number of attributes that are collected alongside a record (upto 50ish bits of physical data for example).  Whilst in theory Recorder can hold these without issue - it was extremely time consuming to enter - and much of the cross validation (e.g. that substrate percentages add upto 100 etc) was not readily available.

Developing a marine addin for Recorder was also considered and even piloted I believe - but this still didn't really address the issues sufficiently - from memory entering the same data was still taking something like 15 to 20 times as long in Recorder when tested - and this was deemed not practical.

Some types of marine data - particularly the more ad hoc sightings where there isn't a whole raft of associated attribute data probably fit better into Recorder than marine recorder - use whatever is most appropriate to your situation I suggest.  Data from both Marine Recorder and Recorder have the potential to end up on the NBN gateway - so in that respect it makes no difference which application data is entered into.

Hope this helps
Best wishes
James

7

Re: Why?

A marine add-on (I think to cope with the sheer volume of attributes) was produced for an early version of Recorder. JNCC commissioned a trial of entering data into this marine add-on (somewhere there is a JNCC report on the findings) which among other things compared the time it took to enter data into the old MNCR database (which was badly in need of replacement) and the then new Recorder add-on. As stated by others the time taken to enter the same data 20 times longer. That report essentially as I understand it under-pinned the business case for devloping Marine Recorder.

James (SNH)

8

Re: Why?

When it took longer to enter the data into Recorder, was that a deficiency in the user interface (i.e., not as efficient as a bespoke marine-centric UI), or a deficiency in the database itself (i.e., create, read, update, deletes took a long time to process)?

Charles Roper
Digital Development Manager | Field Studies Council
http://www.field-studies-council.org | https://twitter.com/charlesroper | https://twitter.com/fsc_digital

9

Re: Why?

The user interface was the problem with speedy entry. I seem to remember a doc a few years ago comparing data entry to Rec and MR and finding it 10 times faster with the new UI.
-I may be mis-remembering though...

CyprianPayne
CCW