48 Allan Raymond [email protected] http://www.btinternet.com/~allan_raymond/Monarchies_of_Europe.htm FreeBMD - putting birth marriages and deaths on the Internet http://FreeBMD.rootsweb.com/ ----- Original Message ----- From: "Gypsy" <[email protected]> To: <[email protected]> Sent: 05 August 2001 08:27 Subject: How Many Syndicates G'day All Just to satisfy my own curiosity, can anyone tell me how many Syndicates there are please. Cheers Teri ============================== Search over 1 Billion names at Ancestry.com! http://www.ancestry.com/rd/rwlist1.asp

Whilst browsing through the data base looking for my brick walls, I came across some entries that are double keyed by the same person. Whilst not wanting to question the ability and accuracy of our transcribers in any way at all, I thought that the idea of double keying was to have two independently transcribed entries so that they could then be matched for accuracy. Surely there is potential inaccuracies if the same person double keys entries. Sheelagh

Dave, Many thanks for your assistance in my 1837 un-readable scan problem, All is now easily readable :o) But, I have one more request for knowledge, I had moved on from 37D4F0591 because it was not readable, hence it was only partially complete, now that I can read the downloaded files, how do I re-open the earlier files to continue the transcription into them? Tony Meighan

On Sun, 29 Jul 2001 15:22:57 +1000, you wrote: >Dave, > >Many thanks for your assistance in my 1837 un-readable scan problem, >All is now easily readable :o) >But, I have one more request for knowledge, >I had moved on from 37D4F0591 because it was not readable, hence it was >only partially complete, now that I can read the downloaded files, how do I >re-open the earlier files to continue the transcription into them? From the opening menu; F4 - Correct an earlier batch -- Dave Mayall

Hi All, I am at present working on handwritten 1837 Deaths, the first page 37D4F0591 is 50% unreadable because of the nature of the scan. But it gets worse, 37D4F0598 is totally missing, it appears to have slide sideways of the planet. Then with 599-560 they are back to only 50% readable. Do I simply submit that which I can read or is there another scan available elsewhere that I can use? What do I do? Tony Meighan

Quoting Tony Meighan <[email protected]>: > Hi All, > > I am at present working on handwritten 1837 Deaths, the first page > 37D4F0591 is 50% unreadable because of the nature of the scan. > > But it gets worse, 37D4F0598 is totally missing, it appears to have > slide > sideways of the planet. > Then with 599-560 they are back to only 50% readable. > Do I simply submit that which I can read or is there another scan > available elsewhere that I can use? What do I do? Ask for a re-scan see http://freebmd.rootsweb.com/scan-source2.html -- Dave Mayall ------------------------------------------------- This mail sent through UK Online webmail

Anne Cruise wrote: > > Good day all. > > How about: > > This search cannot be run as it is too wide-ranging to complete within > available time and computing resources. Possible. > In order for your search to be completed please be more specific about the > range of years and/or the event and/or the Registration Districts selected. Tricky, as it isn't that easy to work out in a given case whether any particular course of action will improve things (in particular, adding a district will *NOT* improve the complexity score. > Available computing resources mean your search can only be completed by > limiting your criteria of date range, event and/or Registration District. Same problem! > We would like to help but you must be more specific with your criteria in > order for the search to be run. This implies that searches with just surname are *never* permitted. They are! The rejection is based upon an assessment of the *particular* complexity of this search (as opposed to one for a different surname) > I'm sure there are some better phrases out there but I hope these > suggestions help. They do! -- Dave Mayall

On Mon, 23 Jul 2001 17:28:29 -0700, you wrote: >At 10:22 AM +0100 7/23/01, Dave Mayall wrote: >>Brian Smart wrote: >>> >>> Hi All, >>> I am sorry to say this again but we must move to creating the scans using 8 >>> bit rather than 1 bit. The files may be bigger but at least we may be able >>> to read them. Is this something that can be used for the future. >> >>We can discuss it with Ancestry, but we aren't in a position to insist. > > >Sure we are. Is the goal speed, or accuracy? I say accuracy. Since >i'm sure you would agree with me there, i belive we most certainly >should reject 1 bit scans. We can afford to wait a bit longer for >Derek or Camilla to get to them if it means we get 25% more accuracy. The goal is accuracy, and marking entries as unreadable in part doesn't conflict with that. The volume of scans that we can provide without the Ancestry input simply isn't enough to keep all our transcribers supplied. -- Dave Mayall

Good day all. How about: This search cannot be run as it is too wide-ranging to complete within available time and computing resources. Or In order for your search to be completed please be more specific about the range of years and/or the event and/or the Registration Districts selected. Or Available computing resources mean your search can only be completed by limiting your criteria of date range, event and/or Registration District. Or We would like to help but you must be more specific with your criteria in order for the search to be run. I'm sure there are some better phrases out there but I hope these suggestions help. Best wishes Anne Cruise [email protected] Dave Mayall wrote: > > > To be honest, I plucked "complexity" out of the air when implementing this. > The original term used (and still used within the code) was "cost". Of course > using anything on those lines would cause even more confusion.

At 10:22 AM +0100 7/23/01, Dave Mayall wrote: >Brian Smart wrote: >> >> Hi All, >> I am sorry to say this again but we must move to creating the scans using 8 >> bit rather than 1 bit. The files may be bigger but at least we may be able >> to read them. Is this something that can be used for the future. > >We can discuss it with Ancestry, but we aren't in a position to insist. Sure we are. Is the goal speed, or accuracy? I say accuracy. Since i'm sure you would agree with me there, i belive we most certainly should reject 1 bit scans. We can afford to wait a bit longer for Derek or Camilla to get to them if it means we get 25% more accuracy. -Ben -- NOTE: Please change my address in your address book from bhines at san.rr.com to bhines at alumni.ucsd.edu as my UCSD address will be permanent. <http://freepages.sf.rootsweb.com/~bhines/> - My Genealogy Pages

Dave, > Dave wrote: OK, We will look at how it could be implemented (once we have finished tweaking everything for efficiency) >>Brian Smart wrote: >> >> Hello All, >> >> My request was for a list of files that have been uploaded but NOT yet >> incorporated in the main database. i.e. not as Mary Muir has interpreted. >> Any way that the information can be listed including as Mary suggests would >> be OK. If it is practicable to have a file list after selection of the volunteer, would it be possible to include both date/time each file was created and date/time it was last modified, and order the list with most recent files first? (Just a suggestion...) Jennifer

Anne Cruise wrote: > > Good day all. > > Thankyou to all who offered words of encouragement to still my fears about > upgrading SpeedBMD. I upgraded this evening and it appears all is working > fine - but > > oh dear. > > I know you can't please everybody and I know the transcribers asked for the > new modifications - but is it going to be too much of a disaster if I go > back to the previous version? > > I really cannot cope with those numbers on the "End of Batch" bar in the > surname column when in Block Input mode. Every time I look up from the > keyboard to check my page number input, my eyes which are looking for a set > of numbers are automatically drawn to the gaudy yellow set instead of the > plain black ones at the other side of the page. > > Is it just me? I can only hope that I will get used to it eventually. In your SpeedBMD folder, there is a file called colours.txt Open this file with Notepad, and edit the line; o o yellow to read; o i yellow Save the file and start SpeedBMD -- Dave Mayall

Philip Powell wrote: > What is the position wrt "rejected" scans? I've had to highlight 5 scans > as being completely blank. Does my syndicate leader feed that back up > the chain and what is the [theoretical] next step? The co-ordinator will check scans either side to determine whether these are intentionally blank pages. > What is the position wrt patchy scans - scans that are otherwise ok but > have a very poor [illegible] section? Should these be mentioned to > syndicate leaders? The general rule is that if a scan is hard to read, asking for a re-scan is the default way of proceeding. If the rescan is no better we make the best we can of it. -- Dave Mayall

Peter Norman wrote: > You have explained why it was necessary to do this. But it might be helpful > to change the terminology employed since the issue is not strictly one of > complexity but of the number of potential hits. Not really! It is the number of records read from the database to come up with a hit. The complexity bears no relation to the number of hits that the search will produce, only to the number of records returned in the first pass by the best index. > A complex search implies, at least to me, that it is one that seeks to match > multiple criteria. Such a search might be anticipated to require more cpu > time. Whereas searching for a single but common surname is not complex. But > the number of hits also takes up too much cpu time. Yet the current default > explanation implies that it is searches lacking a surname that will cause > problems. I see the problem, and would welcome a better word (searches that we describe as too complex are I/O bound rather than CPU bound though. The complexity is the number of disk reads that will be required). To be honest, I plucked "complexity" out of the air when implementing this. The original term used (and still used within the code) was "cost". Of course using anything on those lines would cause even more confusion. -- Dave Mayall

Brian Smart wrote: > > Hello All, > > My request was for a list of files that have been uploaded but NOT yet > incorporated in the main database. i.e. not as Mary Muir has interpreted. > Any way that the information can be listed including as Mary suggests would > be OK. OK, We will look at how it could be implemented (once we have finished tweaking everything for efficiency) -- Dave Mayall

Brian Smart wrote: > > Hi All, > I am sorry to say this again but we must move to creating the scans using 8 > bit rather than 1 bit. The files may be bigger but at least we may be able > to read them. Is this something that can be used for the future. We can discuss it with Ancestry, but we aren't in a position to insist. -- Dave Mayall

Hi All, I am sorry to say this again but we must move to creating the scans using 8 bit rather than 1 bit. The files may be bigger but at least we may be able to read them. Is this something that can be used for the future. Regards Brian Smart

Hi, Mary's suggestion giving read only access to files in a users area would not hit the db and so is a possibility. The big load is listing files which have been allocated by a user whoc is partof a syndicate. We can certainly think about Mary's suggestion and see what we come up with ... Cheers Graham Brian Smart wrote: > > Hello All, > > My request was for a list of files that have been uploaded but NOT yet > incorporated in the main database. i.e. not as Mary Muir has interpreted. > Any way that the information can be listed including as Mary suggests would > be OK. > > Mary Muir said: > > "Currently you have to be a mind reader and know how your > syndicate member names the file:) (which isn't always totally logical)" > > Regarding choice of file name, why are you not specifying the way the files > should be named? One of my allocations has about 4000 individual files, if > they were named by syndicate members in a random way it would be impossible > to manage. > > Regards > > Brian Smart > > ============================== > Search over 1 Billion names at Ancestry.com! > http://www.ancestry.com/rd/rwlist1.asp

Hi Peter, Peter Norman wrote: > > ----- Original Message ----- > From: "Dave Mayall" <[email protected]> > To: <[email protected]> > Sent: Sunday, July 22, 2001 10:15 AM > Subject: Re: The Complex Search Issue > > > On Sun, 22 Jul 2001 10:27:13 +0200, you wrote: > > > > >Hi Susannah > > > > > >If the name you are researching is very rare, then even searching the > entire > > >database does not return a complete page, let alone multiple pages. > > > > And would not give a "Search too Complex" error. > > > > >So to those who want to change the search engine, please consider the > whole > > >range of people who will want to use FreeBMD, including the one-name > study > > >style or researcher, and those researchers whose family names are extinct > in > > >20th century England and Wales. > > > > "Those who want to change the search engine" reads as if the changes > > that have been implemented have been implemented because of some > > strange desire to make life difficult. > > > > Let me state again that the changes were NECESSARY. Cross database > > searching makes HUGE demands on the server, and if hugely complex > > searches are allowed EVERYBODY else who is searching at the same time > > gets thrown out. > > > > It is not acceptable that a single search should prevent 40 others > > from working, so we have blocked the searches that were causing the > > problem. It is *still* possible to get the same information by > > searching a limited timescale (say in 10 year chunks). I realise that > > this is less convenient, but it can still be done. > > Dave > > You have explained why it was necessary to do this. But it might be helpful > to change the terminology employed since the issue is not strictly one of > complexity but of the number of potential hits. > > A complex search implies, at least to me, that it is one that seeks to match > multiple criteria. Such a search might be anticipated to require more cpu > time. Whereas searching for a single but common surname is not complex. But > the number of hits also takes up too much cpu time. Yet the current default > explanation implies that it is searches lacking a surname that will cause > problems. It is genuinely a complex search. What the system is saying is: "That search is so complex that I am going to have to look through more than 2 million records to find the answer" Searches without Surnames are a good candidate for this but so are searches on common surnames across medium to large data ranges. We can look at the wording but its not possible to have a generic piece of advice to the searcher except try to narrow your search. We can look at search hints and tips, but that'll have to wait while the indexes are being tweaked because it changes from upload to upload :) Cheers Graham > > Peter Norman > > ============================== > Visit Ancestry's Library - The best collection of family history > learning and how-to articles on the Internet. > http://www.ancestry.com/learn/library

Hello All, My request was for a list of files that have been uploaded but NOT yet incorporated in the main database. i.e. not as Mary Muir has interpreted. Any way that the information can be listed including as Mary suggests would be OK. Mary Muir said: "Currently you have to be a mind reader and know how your syndicate member names the file:) (which isn't always totally logical)" Regarding choice of file name, why are you not specifying the way the files should be named? One of my allocations has about 4000 individual files, if they were named by syndicate members in a random way it would be impossible to manage. Regards Brian Smart