• Only registered members can see all the forums - if you've received an invitation to join (it'll be on your My Summary page) please register NOW!

  • If you're looking for the LostCousins site please click the logo in the top left corner - these forums are for existing LostCousins members only.
  • This is the LostCousins Forum. If you were looking for the LostCousins website simply click the logo at the top left.
  • It's easier than ever before to check your entries from the 1881 Census - more details here

Version 3.7.0.0 Released

Success at last with beta7, csv file exported and loaded into Excel successfully. :) Thank you Alexander.

When the file is exported, do we still need all of the columns and might there be a better order?
The 4 columns Ind ID, Fam ID, Short Code, Include are of no real interest to the recipient.
Perhaps the Census and Relation Type columns should be swapped and a new column of Ahnentafel inserted between them.
That would then give the recipient all the information in the order in which it will be needed for insertion into the Ancestors page of LC.

Sorry not to have made these suggestions before. :(
 
Woops, I forgot that year of census is needed as first column when entering data into LC.
 
The column ordering is designed to mirror the Lost Cousins website Referral form. The include column for instance is meant to show what boxes you click on that form. The relation type is what you select on the drop down on the right.

The family ID and short code aren't needed and aren't shown on form so not sure why they appear as I thought hidden columns were suppressed.
 
Beta 9 out with 4 types of census reference report - full references, partial references, unrecognised references, and missing references. I've also refactored the export to Excel for referrals to more closely match what you were asking for Bryman.
 
Alexander Bisset said:
The column ordering is designed to mirror the Lost Cousins website Referral form. The include column for instance is meant to show what boxes you click on that form. The relation type is what you select on the drop down on the right.
Click to expand...

Beta9 looks good. Thank you. I will have to get back to you about the new Census Reference reports when I have looked into them further.

The column ordering in the online report is fine to help with preparing a referral to a new potential member. This was the original purpose of the report.

I only suggested a different order for the exported file to help with an existing member entering the data on their LC Ancestors page.
That is why I also requested Ahnentafel as an extra column, if it is available, in case the recipient did not know the appropriate value.

I am willing to hear other members views/suggestions on this, if any are interested (care a hoot :) ).
 
I forgot about Ahnentafel that's now added to the Export to Excel report between RelationType and Census as you suggested. The other things having been already cleaned up in beta 9. Note these are output as appropriate for the individual selected in the referral report so will be different from yours also note that the Ahnentafel will be useless if you have not selected the person you are sending the report to.

It was previously suggested that most times someone would send a report typically the person receiving it wouldn't be represented in your tree. In this case is having the Ahnentafel not a dangerous thing? As a lot of users won't understand it and will just enter the numbers in good faith.

I suspect that the Ahnentafel from the other users perspective is a bad thing. Actually I think I should remove it as it is only going to cause confusion. The Ahnentafel numbers would only ever be right for someone receiving them if you had a full accurate picture of their tree already. This is very rarely going to happen. Indeed a neater solution is to tell the recipient to load their tree into FTAnalyzer to get the right Ahnentafel numbers.
 
Interesting. I thought that I had considered Ahnentafel adequately.

When a LC member enters a Direct Relative on their Ancestors page, they are asked for the Ahnentafel Number relative to them. That is what I expected the exported file to contain, relative to the intended recipient. That value might not be known to the recipient until they have entered the details into their tree and possibly not even then.

Alexander Bisset said:
It was previously suggested that most times someone would send a report typically the person receiving it wouldn't be represented in your tree. In this case is having the Ahnentafel not a dangerous thing? As a lot of users won't understand it and will just enter the numbers in good faith.

I suspect that the Ahnentafel from the other users perspective is a bad thing. Actually I think I should remove it as it is only going to cause confusion. The Ahnentafel numbers would only ever be right for someone receiving them if you had a full accurate picture of their tree already. This is very rarely going to happen. Indeed a neater solution is to tell the recipient to load their tree into FTAnalyzer to get the right Ahnentafel numbers.
Click to expand...

I agree with your reasoning when the referral is being made to a potential LC member. In that case the referral details are sent from LC rather than FTA.

When the report from FTA is sent as a csv file to an existing member then I would expect the recipient to be represented in the originator's tree. In my case, I intend to send a file of about 50 individuals to my 4th cousin who only has a few of his family recorded on LC. I hope that having more details in a form which assists the entry to LC will act as a spur. If such action succeeds then I would certainly recommend the use of FTA to determine further Ahnentafel Numbers and other information.
 
Bryman said:
Interesting. I thought that I had considered Ahnentafel adequately.

When a LC member enters a Direct Relative on their Ancestors page, they are asked for the Ahnentafel Number relative to them. That is what I expected the exported file to contain, relative to the intended recipient. That value might not be known to the recipient until they have entered the details into their tree and possibly not even then.
Click to expand...
I think you mean "that value might not be known by the sender until they have entered the details in to their tree". The recipient should be able to calculate ahnentafel numbers assuming they have heard of them. However the sender and hence FTAnalyzer cannot know the recipients ahnentafel numbers unless the recipient is in the senders tree and the sender has selected the recipient when generating the report.

Far more likely that the sender will select someone that is the common ancestor that gave rise to the contact in the first place. I know of plenty of times I've contacted someone about a common ancestor and have exchanged emails but have never actually ended up with the full line from the common ancestor to that person. Often is stops from online records with the people marked as private as they are living.

Asking the person to reveal those private details feels like an intrusion so I more commonly than not have not got the intended recipient in my tree. Which suggests to me that more commonly than not the ahnentafel numbers wouldn't make sense to them so it is likely to be better that they fill in that info for themselves so that it is accurate.
 
Alexander Bisset said:
I think you mean "that value might not be known by the sender until they have entered the details in to their tree". The recipient should be able to calculate ahnentafel numbers assuming they have heard of them. However the sender and hence FTAnalyzer cannot know the recipients ahnentafel numbers unless the recipient is in the senders tree and the sender has selected the recipient when generating the report.

Far more likely that the sender will select someone that is the common ancestor that gave rise to the contact in the first place. I know of plenty of times I've contacted someone about a common ancestor and have exchanged emails but have never actually ended up with the full line from the common ancestor to that person. Often is stops from online records with the people marked as private as they are living.

Asking the person to reveal those private details feels like an intrusion so I more commonly than not have not got the intended recipient in my tree. Which suggests to me that more commonly than not the ahnentafel numbers wouldn't make sense to them so it is likely to be better that they fill in that info for themselves so that it is accurate.
Click to expand...

I did mean recipient as I was not expecting the sender to initiate the transfer of information without having such details in their tree already. In my case, the match between trees was made in a side branch of mine with the common ancestor unknown to LC.

I am appreciative of other people's privacy concerns and have no wish to intrude but as published census information is over 100 years old I am unlikely to antagonise any living relatives. I am mearly trying to make life as easy as possible for my cousin, if he would like to extend his tree and enter further details on his LC Ancestors page. He may have lost interest since his initial recordings in which case that will be the end of the matter.

I asked for the export csv file for a particular purpose and not one that everyone would necessarily require. However, anyone else wishing to help a relative in a similar way to me would probably not attempt this manually. I hope this file will be useful to others.
 
The new Census Reference reports are identifying errors already!
I was expecting these to be blank after my massive clean up of sources. However, two reports show anomalies.

There are four rows in the Blank Census Reference report. I was about to blame FTA (again) but this time the program is absolutely correct.
Thank you Alexander. The GEDCOM contains a RESI instead of a CENS in one year each for four individuals but my sources are all defined as census so I must follow up elsewhere. I cannot see a significant difference between the data for instances of RESI and CENS.

The other surprise was to find about a dozen entries on the Unrecognised Census Reference report. I look forward to reading the help for this when your documentation team is able to catch up with all the changes as I am struggling to understand.

BTW, a quick starter for ten, what does the Preferred column indicate?
 
Bryman, once you have exported the Referral list to excel, you can export other reports from FTA as well, and then use vlookup in excel to combine other bits of data to that person.
 
Bryman said:
The other surprise was to find about a dozen entries on the Unrecognised Census Reference report. I look forward to reading the help for this when your documentation team is able to catch up with all the changes as I am struggling to understand.

BTW, a quick starter for ten, what does the Preferred column indicate?
Click to expand...

The Unrecognised Census References means that whatever you have as I census reference the patterns were unable to match it and gave up. This will very likely mean I need to add or tweak patterns. Indeed I'm toying with the idea of creating an export that is just the unique references that are unrecognised that users could report as an issue so that patterns can be improved. Meantime if you can tell me the failed reference I can see why the pattern matching failed.

Preferred column is the fact in your tree for that person marked as the preferred fact. The GEDCOM definition says this is the first fact of its type in your file for that person. So for instance it is common to have several birth facts eg: you aren't terribly sure on the exact birth and its one of those people that randomly ages between census (ie: not a regular 10 years each census). One of those facts will be the one you are most sure of but you are keeping the others as evidence that the census showed something different. The one you are most sure of is your preferred fact, if your software doesn't have a means of marking a preferred one it defaults to the first of that type for the person in the GEDCOM anyway.

FTAnalyzer then uses a preferred fact where possible for calculating ages etc.

Note in particular calculated birth facts are always set to not preferred so they never interfere with a birth fact in your file. They are used for information or in the absence of a birth fact in your file. eg: you have a census fact with an age, this generates a calculated birth fact which is only used if you don't already have a birth fact.

Having answered the starter for 10 what topic is the next three questions on? :)
 
Alexander Bisset said:
The Unrecognised Census References means that whatever you have as I census reference the patterns were unable to match it and gave up. This will very likely mean I need to add or tweak patterns. Indeed I'm toying with the idea of creating an export that is just the unique references that are unrecognised that users could report as an issue so that patterns can be improved. Meantime if you can tell me the failed reference I can see why the pattern matching failed.
Click to expand...

I have had to remove the small window print (from ALT+PRTSC) as I get a forum error that the message is too long.
Unknown Census Ref: Class: RG10; Piece: 3730; Folio: 26; Page: 6;
Unknown Census Ref: Piece 435, Folio 51, Page 40
plus 9 others similar to 2 above.

If I get much more of this I may give up too.
Rows 1 and 6 are for Wife and Husband. I can't see anything wrong with these references.
The remaining rows I thought I had changed but obviously somethings remain hidden and then come out of the woodwork unexpectedly.
":" and ";" must be the appearance that something has escaped (like wornholes) and will be the death of me yet - K.I.S.S.
 
Alexander Bisset said:
Note in particular calculated birth facts are always set to not preferred
Click to expand...

That makes sense. I always prefer not to have a birth fact calculated in preference to a fact of a calculated birth. :confused:


Alexander Bisset said:
Having answered the starter for 10 what topic is the next three questions on? :)
Click to expand...

How about "Uses of cranial artefact for demolition of masonry edifice"? (sorry, I can't find Tim's 'smiley' and now time has run out.) :p
 
Bryman said:
Unknown Census Ref: Class: RG10; Piece: 3730; Folio: 26; Page: 6;
Unknown Census Ref: Piece 435, Folio 51, Page 40
plus 9 others similar to 2 above.

If I get much more of this I may give up too.
Click to expand...

The issue is that its a new feature and getting the patterns right so it tolerates all the variations is a right royal pain, so bear with me. As you say lots of variants of colons, spaces and semi-colons etc make it difficult to make sure I'm matching all variants.

The first one looks fine with the current tweaks, and I've made a lot of recent tweaks so it may be in beta 10 (not out yet). 2nd one is missing "Class" which wasn't being catered for, it should be now. A problem with that pattern though is it can match lots of different formatted years and isn't that specific. However I've added support that in the event if fails to check everything else then check those patterns.
 
Beta 10 now out. I've added several more recognitions of census references including US and various forms of Scottish ones and a button to report ones it still doesn't understand. Fixes to unknown reference crashes, and additional filters to exclude from census reports those known to be out of country.
 
Alexander, you are a star. Thank you for your efforts.

Sorry if I seemed to be getting at you earlier but it was just frustration at not being able to see clearly what I must do to avoid problems. If only all program authors were as responsive as you.

You are probably on a hiding to nothing in trying to cater for all possible variations of census reference and that is why I didn't ask for my format to be added to what must be becoming a very long list. Now if I can just find where those unmodified sources are hiding . . .

BTW, I have found my cousin's email address and it is still valid! He has asked me to send him the Referral Report details so now we get a chance to receive real live feedback about this approach. Don't hold your breath in case it takes a while.
 
You must log in or register to reply here.
Back
Top