Bryman
LostCousins Megastar
The file did also include the actual DOB as 06 JUL 1820 but I did not show that as I did not see that it was significant.
-
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!
-
It's easier than ever before to check your entries from the 1881 Census - more details here
FTAnalyzer questions.
- Thread starter Norman
- Start date
The file did also include the actual DOB as 06 JUL 1820 but I did not show that as I did not see that it was significant.
Doesn't cause an issue. The calculated fact is marked as non preferred. So from v3.7.0.1 onwards it would be used in the absence of any birth facts but a birth fact in the GEDCOM would always take priority over a calculated fact.
Norman
LostCousins Member
Recently updated FTA and pleased to see the plethora of additional reports available. The GEDCOM stats page lists quite a number of unknown fact types in my file. On looking at the "Data Errors" tab it appears that FTA does not like, or recognise, fact types that have been entered in upper case. I thought that it would be easy to go back and amend the originating source.
Unfortunately the source of the GEDCOM is Ancestry and the fact types are added when attaching the source and image to the individual. This is not editable within Ancestry's interface. The complicating factor is that Ancestry does not seem to be consistent in using upper or lower case. The vast majority of facts get entered as lower case and cause on problems in FTA but sometimes a fact will be entered in upper case even though there are many other instances of the same fact being entered in lower case. FTA only complains about the upper case instances.
Until Ancestry can be forced to get it's act together and enter all facts in lower case would it be possible to have FTA do a caseless check?
One other small issue is that Ancestry adds some images, school records for example, as a source of proof of residence. FTA then lists the residence fact in the data errors as "Residence date dd mmm yyyy is in a census year but doesn't overlap census date". This can, of course, be filtered out of the display.
Unfortunately the source of the GEDCOM is Ancestry and the fact types are added when attaching the source and image to the individual. This is not editable within Ancestry's interface. The complicating factor is that Ancestry does not seem to be consistent in using upper or lower case. The vast majority of facts get entered as lower case and cause on problems in FTA but sometimes a fact will be entered in upper case even though there are many other instances of the same fact being entered in lower case. FTA only complains about the upper case instances.
Until Ancestry can be forced to get it's act together and enter all facts in lower case would it be possible to have FTA do a caseless check?
One other small issue is that Ancestry adds some images, school records for example, as a source of proof of residence. FTA then lists the residence fact in the data errors as "Residence date dd mmm yyyy is in a census year but doesn't overlap census date". This can, of course, be filtered out of the display.
The fact type checking should be forced to check the text in upper case regardless of what was entered. Ie: it should already be a case insensitive check. Can you give an example of one that fails and I can check why that is.
Norman, I use FTM and I don't have any issues. I've just checked my gedcom and all facts are upper case.
Looking at the gedcom stats, I only have 1 unknown listed, which is one I created myself.
Have you looked at the facts tab?
Do you have facts that are in lower case then? That might be the issue?
Norman
LostCousins Member
I have been investigating this myself using a couple of instances of fact type "probate".
One instance shows within Ancestry like this:-
Another instance shows like this:-
As can be seen the first shows an editable field "Title" containing the fact "Probate" (lower case). This is populated by the attach command. The second instance shows no such field.
The GEDCOM entries for the two instances are thus:-
The two probate entries are being recorded differently by Ancestry. One as a probate fact the other as a probate event. It is the event that is reported as an unknown fact and reported in upper case.
One instance shows within Ancestry like this:-
Another instance shows like this:-
As can be seen the first shows an editable field "Title" containing the fact "Probate" (lower case). This is populated by the attach command. The second instance shows no such field.
The GEDCOM entries for the two instances are thus:-
Code:
1 EVEN
2 TYPE Probate
2 DATE 14 JUL 1930
2 PLAC London, England
2 SOUR @S56@
1 PROB
2 DATE 20 FEB 1925
2 PLAC London, England
2 SOUR @S56@The two probate entries are being recorded differently by Ancestry. One as a probate fact the other as a probate event. It is the event that is reported as an unknown fact and reported in upper case.
Thanks Norman. Interesting in one case ancestry has correctly recognised it as a Probate fact and stored it as such. In the other case it is saving it as an unknown event. This then isn't being recognised as an unknown event type. So nothing to do with upper/lower case it is because unknown event types aren't being checked for the full names of known events types.
However there is a mechanism for this in the program already I just need to add extra descriptions to pick up the mismatched fact types. Can you identify all the mismatched types from the GEDCOM stats tab and list them for me I'll add them to the list to check for.
However there is a mechanism for this in the program already I just need to add extra descriptions to pick up the mismatched fact types. Can you identify all the mismatched types from the GEDCOM stats tab and list them for me I'll add them to the list to check for.
The Probate Date one does it have a date entry too? Or is that a missing new line.
Code:
1 EVEN
2 TYPE Probate Date
2 DATE 14 JUL 1930
2 PLAC London, England
2 SOUR @S56@
or
1 EVEN
2 TYPE Probate DATE 14 JUL 1930
2 PLAC London, England
2 SOUR @S56@Ok added both, plus burial and a few other similar ones to type checking and forcing them to match the types they are meant to be. I'm waiting for the launch of lives of the First World War in 29+ hours to check that the new search works so I'll issue a new version with these fixes then.
Bryman
LostCousins Megastar
1. I have a few FUNERAL facts which are not being recognised by FTA. Please could that category be added to the acceptable list?
As an outsider, I don't understand the GEDCOM standard and would have expected Burial and Cremation, etc., to be sub categories of Funeral, or have I completely missed the point?
2. I have been using FTA to help me identify where similar Sources are used within a GEDCOM but then noticed that double clicking an entry in the Sources Report sometimes shows more instances than notified in the report. Why might that be? Am I falling foul of another option which is leading to double counting or are some instances not being included in the report count?
3. I am not sure how I should be stating occupation start and end dates because I am not getting what I expected. For instance the following GEDCOM records . . .
produce BEF 04 NOV 1907 and AFT 05 NOV 1907 in FTA, which is close but not quite the same. Should I be recording this differently?
I gave 04 NOV 1907 as an end date and 05 NOV 1907 as a start date in my FHS to avoid overlap.
As an outsider, I don't understand the GEDCOM standard and would have expected Burial and Cremation, etc., to be sub categories of Funeral, or have I completely missed the point?
2. I have been using FTA to help me identify where similar Sources are used within a GEDCOM but then noticed that double clicking an entry in the Sources Report sometimes shows more instances than notified in the report. Why might that be? Am I falling foul of another option which is leading to double counting or are some instances not being included in the report count?
3. I am not sure how I should be stating occupation start and end dates because I am not getting what I expected. For instance the following GEDCOM records . . .
Code:
1 OCCU Baker
2 DATE TO 04 NOV 1907
1 OCCU Soldier
2 TYPE full time
2 DATE FROM 05 NOV 1907produce BEF 04 NOV 1907 and AFT 05 NOV 1907 in FTA, which is close but not quite the same. Should I be recording this differently?
I gave 04 NOV 1907 as an end date and 05 NOV 1907 as a start date in my FHS to avoid overlap.
Ok added funeral as a type of burial. It could be a cremation but in the absence of a specific BURIal or CREMation fact FTAnalyzer can't tell.
Not sure what the issue with 2 is. I take it you are referring to the fact count in the sources report vs the list of facts once you double click on a source? I did notice the opposite that it sometimes showed less and this was when there were error facts counted in the list for sources but not displayed. I've fixed this so they are now displayed. I've got the same in my tree but for a census source that has 1892 census facts displayed but shows 1894 displayed facts. The problem is that to display the fact it needs to know who was associated with that fact so it has to check has this person got this fact and if so adds them to the list. Somewhere there is a mismatch although with 1894 entries its extremely difficult to work out where the issue lies.
Do you have a simpler example with miscounts? I can't step through 1892 entries to see where an extra 2 is as that's needle in haystack time.
On issue 3. This is the way that FTAnalyzer is displaying dates. In both cases you've recorded a bounded date but only one side of the bind. The displays all resolve FROM and TO dates to BEF and AFT which is as you say almost but not quite the same thing. It's just a display thing. Once the dates are parsed all I have is start and end date in this case for first example the start date is 01/01/0001 and the end date is 04 NOV 1907. Which the display converter chooses to use BEF and AFT for the display. Nothing really to worry about.
If you knew a start or end date you could tighten up the dates to say 2 DATE BET 1897 AND 04 NOV 1907 for example.
If you only know that he was that occupation on that date my own method would be to enter it as they were that occupation on that date but I don't know when it started so I'd just enter the date. If I later found a date range I'd expand it but typically I just record the occupation on the specific date.
Not sure what the issue with 2 is. I take it you are referring to the fact count in the sources report vs the list of facts once you double click on a source? I did notice the opposite that it sometimes showed less and this was when there were error facts counted in the list for sources but not displayed. I've fixed this so they are now displayed. I've got the same in my tree but for a census source that has 1892 census facts displayed but shows 1894 displayed facts. The problem is that to display the fact it needs to know who was associated with that fact so it has to check has this person got this fact and if so adds them to the list. Somewhere there is a mismatch although with 1894 entries its extremely difficult to work out where the issue lies.
Do you have a simpler example with miscounts? I can't step through 1892 entries to see where an extra 2 is as that's needle in haystack time.
On issue 3. This is the way that FTAnalyzer is displaying dates. In both cases you've recorded a bounded date but only one side of the bind. The displays all resolve FROM and TO dates to BEF and AFT which is as you say almost but not quite the same thing. It's just a display thing. Once the dates are parsed all I have is start and end date in this case for first example the start date is 01/01/0001 and the end date is 04 NOV 1907. Which the display converter chooses to use BEF and AFT for the display. Nothing really to worry about.
If you knew a start or end date you could tighten up the dates to say 2 DATE BET 1897 AND 04 NOV 1907 for example.
If you only know that he was that occupation on that date my own method would be to enter it as they were that occupation on that date but I don't know when it started so I'd just enter the date. If I later found a date range I'd expand it but typically I just record the occupation on the specific date.
Bryman
LostCousins Megastar
Correct. The Sources Report for a tree containing about 100 family members shows counts . . .
Source3 Cheshire Parish Records 5
Source4 Cheshire Parish Registers 18
Source12 Chester Parish Registers 23
but when I double click on Source4, a table is displayed with 20 rows.
Unfortunately, I have not always used the same terminology when recording this information and I have not found a way to update the Source record itself. Hence when I edit an individual's record to change the word "Records" to "Registers" a new instance is created rather than change it for all existing. This was a particular problem previously where I had some sources marked as Census events and some not.
Looking at the Source4 table I can see that there are 18 rows corresponding to 18 instances of "2 SOUR @S4@" in the GEDCOM file.
These are part of sections (level 1) relating to BIRTh, BAPtisM, DEATh, MARRiage, etc. That tallies with the Sources Report.
However, there are a further 4 instances of "1 SOUR @S4@" which are not so related. These appear as . . .
Code:
0 @ind00082@ INDI
1 NAME Surname /Forename/
2 GIVN Forename
2 SURN Surname
1 SEX F
1 EVEN
2 TYPE Lost Cousins
2 DATE 1841
1 BIRT
2 DATE 1788
2 PLAC Chester, Cheshire, England
1 BAPM
2 DATE 10 MAY 1791
2 PLAC St Oswald, Chester, Cheshire, England
2 SOUR @source00012@
1 DEAT
2 DATE 16 SEP 1847
2 AGE 59y
2 PLAC Great Boughton, Cheshire, England
2 SOUR @source00014@
2 NOTE Jul-Sep, Vol 19, Page 44.
1 SOUR @source00004@
1 CENS
etcI've made some updates to the handling of sources and facts to hopefully fix this issue can you check v3.7.2.0 to see if that looks better numbers.
I discovered and fixed an issue where it was counting two facts as identical if the dates and places were the same and ignoring whose fact it was and what the source was. Thus a fact with unknown date and place was matching incorrectly with all other unknown dates and places. This is what should be fixed in v3.7.2.0.
I discovered and fixed an issue where it was counting two facts as identical if the dates and places were the same and ignoring whose fact it was and what the source was. Thus a fact with unknown date and place was matching incorrectly with all other unknown dates and places. This is what should be fixed in v3.7.2.0.