Version 3.7.1.0 Released

[Alexander Bisset]

I've just released v3.7.1.0 of FTAnalyzer the significantly enhanced feature is the reporting of census refs. It understands a large range of possible census reference formats in particular those used by Ancestry in merges and those used in Family Historian and those from FMP.

However it may be that the particular format your program uses if it has different commas, semicolons, or names things slightly differently etc then your census references might not be recognised. However there is a feature on the census tab that will allow exporting of unrecognised references to a file so they can be reported. I'll then try to add the most common formats that it struggles with into the next version of the program.

The changes in this version are:
New Features
Census Tab now has four new reports showing census records that have :

• census references
• are missing census references
• partial census references
• unrecognised census references

Added button to export unrecognised census facts to a text file for reporting issues with patterns that aren't being recognised

Updates
Before 1600 don't warn about marriages pre 13 years old
Census facts now count for facts before birth
Census facts now used for loose births
Export to Excel referrals now uses custom interface
Filter out Out of Country entries in census and colour census reports
Reorganised Census tab to make it tidier
Tidied up census tooltip text
Added help button to link to census documentation
Use upper case for fact types
Added option to hide missing tagged people from census reports

Bug Fixes
Fixed out of UK but on UK census people not appearing on Lost Cousins reports
Export from People form was crashing
Counts for Lost Cousins facts was double counting people from UK eg: counting them as both Scotland & England
Fix census refs only showing for LC years
Out of UK Census refs werent being displayed
Facts before birth & after death no longer appear twice
Export Lost Cousins Referrals and Export Sources were crashing
Fix Column sizing of census refs

 

[Bryman]

There is a new report entitled Duplicate Census Facts which shows "Individuals which may have more than one census/residence record for a census year". Please can we have an extra column added to identify the year concerned?

Should individuals even be reported here if there is no overlap of the census date?
It is a useful reminder/warning if more than one address is given for the day of the census but sometimes several different residence facts are valid for a particular year. I have one entry in this table where there are two residence facts for periods later than the day of the census and there is no census record at all for that person. In this situation, the table entry is confusing.

 

[Bryman]

There is a new report entitled Duplicate Census Facts which shows "Individuals which may have more than one census/residence record for a census year".

I forgot to add that for another individual, I have two overlapping residence/census facts but the address is the same in both records. I believe that this is a valid situation which does not need to be reported, ie someone living in a house for the whole year, including the day of the census.

 

[Alexander Bisset]

Its an annoying situation of false positives for which there are no useful fixes. Unless you are being quite strict about all census facts have a CENS tag and all residence facts have a RESI tag. If that's the case then you can turn off the use RESI facts as census facts option. It is only there to fix a bug with Ancestry merges that erroneously stores census facts with a RESI tag.

If you turn off this option then your RESIdence facts won't be picked up as census facts and the false positives will disappear.

 

[Bryman]

The new Missing Census Reference report contains too many entries.

Where an individual has multiple residence facts recorded for a census year, without a corresponding census record, this is erroneously shown as a missing census reference. These are residence facts not a census fact. The census fact is recorded separately.

Also, I have one entry in the table for someone who was born in 1949 !!!! The year of birth is not an error. She is still alive.

 

[Alexander Bisset]

This is the same as I said before if you have always used CENS facts for census then turn off the option to use RESIdence facts as census facts. If you don't need the work around for Ancestry census facts being entered as residence facts then turn the option off and these issues will disappear.

The issue is that if you have this option turned on, and its on by default as lots of users have this issue, then your residence facts ARE census facts. Only if you turn this option off is your comment "These are residence facts not a census fact." correct.

The entry for someone born in 1949 is odd can you send me a PM with the GEDCOM for this individual please so I can check what is going on.

 

[Bryman]

Its an annoying situation of false positives for which there are no useful fixes. Unless you are being quite strict about all census facts have a CENS tag and all residence facts have a RESI tag. If that's the case then you can turn off the use RESI facts as census facts option. It is only there to fix a bug with Ancestry merges that erroneously stores census facts with a RESI tag.

If you turn off this option then your RESIdence facts won't be picked up as census facts and the false positives will disappear.

Thank you for the explanation. I had no idea that option could have that effect or that it might not be advantageous to select it.
I turned off the RESI/CENS equivalence option and the errors disappeared when the GEDCOM file was reloaded.
Sorry to have reported any false positives/negatives. (? ?)

Suggestion:
In order to avoid others being caught in a similar way, can the documentation (and/or option description) make this point specifically, that this option should not be selected except to overcome the Ancestry mistake?

 

[Bryman]

The entry for someone born in 1949 is odd can you send me a PM with the GEDCOM for this individual please so I can check what is going on.

I hope that this will not be necessary as changing the option resulted in this table entry disappearing.
I do like empty error tables/reports.

 

[Alexander Bisset]

Good to hear its fixed for you. Unfortunately several programs as well as Ancestry merge seem to be determined to ignore the GEDCOM standard and have recorded census events as residence events. Whilst its true that a census event does describe where someone is resident on a date it is a unique event that has its own GEDCOM tag and so in my mind it is perverse for programs to record census events as residence events. Your approach is the ideal situation have a residence fact that covers known periods of residence and have a census fact that provided snapshot information for that point in time. In fact if recorded correctly they should inevitably overlap.

Sadly this approach isn't that rigorously adopted and its all too common to have a residence fact used for recording a census. Hence the option and its default on status. This sort of detailed explanation would be useful in the documentation a fact I'm sure the documentation team will take on board.

 

[Alexander Bisset]

There is a new report entitled Duplicate Census Facts which shows "Individuals which may have more than one census/residence record for a census year". Please can we have an extra column added to identify the year concerned?

Martin raised exactly this point with me by email sadly this display format displays individuals and is used in 9 different reports, changing for just one report would mean breaking the other reports. It is also not that easy a thing to determine as it could be multiple error years. Thus I adopted the simple principal that the user can view the individuals in their tree and see why its an error or can double click the individual to see the facts leading to the error.

I'm guessing though that now you have disabled the double counting of residence facts that most if not all of your "errors" have vanished.

 

[Tim]

I hope to be having a little play with the new version today/tomorrow. There is just so much in it now. Great job Alexander.

 

[Bryman]

I hope to be having a little play with the new version today/tomorrow. There is just so much in it now. Great job Alexander.

I hate to suggest that Alexander might possibly slow down his development a little but there is now almost too much for some newcomers to get to grips with. Those who have 'grown up' with FTA from its origins might take it in their stride but I can understand how some might wonder where/how to start.

Without wishing to load anyone up with a lot of extra effort, is there any possibility of a simple "Introduction to FTA" or Getting Started type primer being created, possibly with input/suggestions from several users?

 

[Alexander Bisset]

I'm thinking of creating a few videos on getting started on FTAnalyzer. It would be useful to get ideas on themes. In particular it would be useful to have some tree data that needs fixed. As you say those of us that have grown up with FTAnalyzer have tidied up our trees no end.

I'll post a new thread on the subject.

 

[Tim]

A good suggestion and a good solution