Topic: MapMate usage in LRCs

I was just wondering how many LRCs use MapMate. If you do, in what way do you use it? Is it your main database, or a secondary one used for compatibility with other MM users?

We use it for (incoming) syncing with other MM users. We then use Recorder's import wizard for importing into our main Recorder database and converting GUKs into NBN standard GUIDs. Unfortunately, we've still not devised a bulletproof system of syncing records back to MM users whilst ensuring non-duplication of existing data. As a result of this problem I have a general policy of recommending against the use MM if a recorder requires two-way syncronisation with us. My having to recommend against MM is a real shame as I like the software a great deal, and think it is far better suited to an individual recorder's needs than the much more complex Recorder 2002.

I'd like to hear what other's think.

Charles

2

Re: MapMate usage in LRCs

At BIS we use it in a similar way to Charles. We have a number of Recorders who use it as they prefer it to Recorder for various reasons. Given that, we do support it and provide the software to Recorders. (Thanks to a grant from Powys CC). MM has a lot going for it for single use recorders.

We import into Recorder too, and I note the issues about data exchange. I do wish there was a standard data format schema to allow data exchange between biological databases as this would make life easier. (The NBN XML format is Recorder specific). Trying to run two (or more!) disparate databases is hard work! smile

Re: MapMate usage in LRCs

Dave, have you seen the Common Transfer Format document (it's a Word doc)? I found it by accident while Googling for something else; it looks like the format documentation to the now defunct MapMate/Recorder data exchange software.

Charles

4

Re: MapMate usage in LRCs

Thanks Charles. Had a quick look at the doc and it's very interesting. This is, IMHO, the sort of thing we could do with. Maybe it could be looked at in broader terms in the future. Nice to stand on the shoulder of giants! smile

Re: MapMate usage in LRCs

The sheer number of MapMate users in South Wales has meant that we had to adopt it alongside Recorder - the thought of importing 400,000 records from MapMate was just far too scary!

So the system that we currently have is that any records that are purely Lepidoptera are entered directly into MapMate and sync'd with the Glamorgan Moth Recording Group. Other Lep records that come to us from within reports are input in Recorder with the aim (when I get round to it) of importing these into MapMate. These records will have their 'Reference' set to somthing like 'Imported from Recorder'. So for our general operation we combine records from both Recorder and MapMate into a third central Access database (based on something that Dave Cope uses in BIS). The duplicated MapMate records will be filtered out.

Of course this system is not yet fully tested (or indeed implemented for that matter!), but it seems to work at the moment.

Dave

Dave Slade
Senior IT & Records Officer,  SEWBReC
13 St Andrews Crescent, Cardiff, CF10 3DB

Re: MapMate usage in LRCs

I do something similar but use MapInfo as a repository. This will have to change soon and had hoped that Recorder 6 would be out by now. I would have had a chance to evaluate it for a way forward.
I agree with Charles and Dave, we need a common format. I expect an increasing volume of data through MapMate and at present it looks like we will all end up with our own solutions.
I shall have a look at the Document when I get a little time.

Tony Price
Data Manager, Somerset Environmental Records Centre (SERC)

Re: MapMate usage in LRCs

Tony, you should ask Hannah for a test version of R6 -- I'm using v6.6.5 here and it's very stable. More so than any version of 2002!

I think bespoke reporting systems are fine, even inevitable, along with bespoke data manipulation tools. The important thing is to have compatible core databases (NBN standard), with other technologies spinning off from there. I like to think of the NBN standards as the HTML -- or, more accurately, web standards -- for biological recording. Indeed, they're similar in many respects. The internet would never have become what it is without the standard that is (X)HTML (and of course the TCP/IP protocol - another 'standard'). Companies tried to build their own, proprietory, networks (AOL, MSN, Compuserve, CIX), but these have faded as they were not open standards and couldn't talk to one another. Then the browser makers tried adding their own, proprietory, extensions to the browsers causing huge headaches all round, with a seperate version of a website having to be coded for each browser. It's taken well over ten years (a looong time, in internet time) to finally reach a stage where web designers are finally demanding that software for the web be strictly adherent to the defined standards; and for software developers to deliver on that promise. Even Microsoft is committed to web standards, and we all know what MS are like when it comes to non-proprietory stuff.

I know it sounds a little preachy, but if we don't make an effort to support and advocate standards ourselves, we're doomed to suffer the mess of proprietory, non-interoperable systems for a long, long time.

Re: MapMate usage in LRCs

One other thing I'd like to add - Recorder (2K or 6) isn't a panacea, although I think it was initially (wrongly) marketed as such. I see it rather as a baseline technology - a standard framework with which to build further tools. The real meat of it is the database -- the GUI is pretty basic when compared to what the database itself is capable of, especially when running off SQL Server (or any other 'proper' RDBMS) with its support for stored procedures, views, user defined functions and so on.

9

Re: MapMate usage in LRCs

I agree with your analysis Charles. A standard framework is the key. Perhaps the NBN data model would seem like a fair place to start. As we are "preaching" a bit smile, I'd like to think of the framework as transferable as possible given that I would prefer to work with PostgreSQL then MS SQL server. If the majority of the data validation was carried out by stored procedures then the work of client applications would be easier.

I've asked for a copy of Record 6 to test ages ago, but still not here. Charles, I'd be interested to know what the status of the stored procs in Rec 6 if you get a moment. Thanks.

Re: MapMate usage in LRCs

Yes, there are loads of stored procedures in R6 that do a variety of things. There's a whole suite of (new) import wizard validation sprocs in there too. In addition to this, there's a nice set of user defined functions to do things such as converting RTF to plain text, concatenate multiple recorders into one field, generate new GUIDs and convert grid ref resolution and so on. There's loads of really, really good stuff in there to make life much easier. Making use of Views is going to be useful too.

Is there anything in particular you'd like to know?

Charles

11

Re: MapMate usage in LRCs

Thanks for the info Charles. Everything I was hoping for has been mentioned. This is great news as it means data access clients will be able to hand off work to the server and I may not have to code routines in the client. In particular the import validation procs will be very useful.

Re: MapMate usage in LRCs

I think I was just using different words to describe the same as you. I just don't like mentioning the 'NBN' word. The last time I looked at their documentation it was so out of date as to not be worth a look. I do note the entries here and was surprised that the data suppliers to the NBN had to wait for this forum to find out these things where an email would have been nice. Oh I love the things you are talking about here I just don't have time play at present.

On R6 I'm not prepared to play or look at an unfinished product. I've been through all this before and believe I have lost 10years waiting for a promised fix for Recorder's problems. I was persuaded not to make our own solution in the 1990's because the replacement was going to be worth it. I see no sign of that yet!. The dictionary situation alone in R2k is a joke. The data entry is retrograde and for what gain? Oh compatibility with the gateway. Hmmm.

Sorry but 10 years is a long time to wait. Oh and we're a bit off track here as this is MapMate. smile

Tony Price
Data Manager, Somerset Environmental Records Centre (SERC)

Re: MapMate usage in LRCs

TonyPrice wrote:

Oh and we're a bit off track here as this is MapMate.

Good point. I've continued the thread here

Charles