• 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

FTAnalyzer questions.

Can you give me a GEDCOM snippet for a person with this record. I can't think why it would change by changing the range so checking the way the data is processed with something you have already tested would be the easiest to reproduce.

Edit: I suspect it is census year. Something with a year of start and end year of 1911 will be tolerated as a census year if the year option is set. Whereas something with a range of years (even if its as this case just one day more) will see if the date overlaps the census date.

The census in 1911 was 2nd April 1911 which is the date you have so I can only imagine there might be an issue with the "overlaps" check. I'll add some checks to see if I can work it out with some random test data.

Edit 2: Overlaps seems to be working with two test dates...
Code:
FactDate census = new FactDate("BET 31 Dec 1910 AND 2 APR 1911");
Assert.IsTrue(census.Overlaps(CensusDate.UKCENSUS1911));
census = new FactDate("BET 1 JAN 1911 AND 2 APR 1911");
Assert.IsTrue(census.Overlaps(CensusDate.UKCENSUS1911));

One other thought, a numeric month is not valid in GEDCOM could it be that your family history program is interpreting dates as American format and 02/04/1911 is export as 4 FEB 1911 instead of 2 APR 1911 that would explain not overlapping census date but I'd need to see the GEDCOM to be sure.
 
I compared gedcom files for the two situations and the only record which changed was . . .
1 CENS
2 DATE FROM 31 DEC 1910 TO 02 APR 1911
which FTA showed as Orange

became
1 CENS
2 DATE FROM 01 JAN 1911 TO 02 APR 1911
which FTA showed as Green.
 
Ah FROM xxx TO yyy, as opposed to BET xxx AND yyy which I tested I suspect a subtle difference involving end points. Let me test.

I tested with
Code:
0 @I1@ INDI
1 NAME Test /PERSON/
1 SEX M
1 BIRT
2 DATE ABT 1910   
2 PLAC Somewhere
1 CENS
2 DATE FROM 31 DEC 1910 TO 02 APR 1911
2 PLAC Someplace
1 EVEN
2 TYPE Lost Cousins
2 DATE 1911
Which worked and only showed green!! The only thing I can think that also affects it is the location, as it checks valid census against a census location. What is the PLAC and/or ADDR record for this CENS?
 
What is the PLAC and/or ADDR record for this CENS?

Code:
1 SEX F
1 BIRT
2 DATE 1878
2 PLAC Chester, Cheshire, England
1 EVEN
2 TYPE Lost Cousins
2 DATE 1911
1 CENS
2 DATE  FROM 31 DEC 1910 TO 02 APR 1911
2 PLAC 3 Charles Street, Chester, Cheshire, England
2 SOUR @source00116@
3 PAGE Class: RG14; Piece: 21879; SN: 120;
 
0 @source00116@ SOUR
1 TITL RG14/21879/120 @@ 1911 census
1 PUBL Publication Date: 02 APR 1911
2 CONT Media: Census

still shows as Orange indicating CENS not accepted!
 
Code:
1 SEX F
1 BIRT
2 DATE 1878
2 PLAC Chester, Cheshire, England
1 EVEN
2 TYPE Lost Cousins
2 DATE 1911
1 CENS
2 DATE  FROM 31 DEC 1910 TO 02 APR 1911
2 PLAC 3 Charles Street, Chester, Cheshire, England
2 SOUR @source00116@
3 PAGE Class: RG14; Piece: 21879; SN: 120;
 
0 @source00116@ SOUR
1 TITL RG14/21879/120 @@ 1911 census
1 PUBL Publication Date: 02 APR 1911
2 CONT Media: Census

still shows as Orange indicating CENS not accepted!

Isn't a CENS fact just a single day? And not a FROM/TO?
A RESI fact can be a FROM/TO
 
Isn't a CENS fact just a single day? And not a FROM/TO?
A RESI fact can be a FROM/TO

Correct, but my ancestors are known to have lived at that address for more than the day of the census. Hence my earlier question about whether I needed to add another RESI fact for the census. I was assured that FTA could cope with just the single fact and that is fine where the date range is all in one year.
When the FROM date is a day earlier, FTA no longer accepts the CENS record.

Please ignore the [COLOR] / [/COLOR]. I took that out when I saw the preview but they returned when I made the post.
 
I still get Orange when I run the following.

Code:
0 HEAD
0 @ind00001@ INDI
1 NAME Mary /Leach/
2 GIVN Mary
2 SURN Leach
1 SEX F
1 EVEN
2 TYPE Lost Cousins
2 DATE 1911
1 BIRT
2 DATE 1908
2 PLAC Chester, Cheshire, England
1 DEAT
2 DATE 1913
2 AGE 5y
2 PLAC Chester, Cheshire, England
1 CENS
2 DATE  FROM 31 DEC 1910 TO 02 APR 1911
2 PLAC 3 Charles Street, Chester, Cheshire, England
0 TRLR

Changing DATE from "31 DEC 1910" to "01 JAN 1911" produces Green.
I can even additionally change the TO DATE from "02 APR 1911" to "02 JAN 1911" and get the same results when changing the FROM DATE.
 
Very odd cutting and pasting that GEDCOM and ONLY that text above into a file and loading into the current code, I get...
not orange.png

Interestingly I thought I better check the current live version and I get orange with that so I must have done something with the code since 3.6.1.4 but I'm not sure what. I'll run a diff to see what's changed.

Edit: Hmm checked the diff and the only new bit of code in that area is the addition of the Missing tag handling but that shouldn't have affected this at all.

I've released v3.6.1.5 which as I say produced the green above. Lets see if something goes weird once it installs for you.
 
Ok so v3.6.1.5 gives the same orange. So its not the code it was the option on my downloaded version I have the option "Tolerate Slightly inaccurate census dates" set to true whereas on my version I have running most of the time in the code building tool I have it set to false.

Now the effect of this option is to allow slight variations in census date which it does by effectively ignoring the day & month components and just checking if the year is a census year. In this case it's using the start year which when its 1910 fails to show up as a census year.

So you have two choices
1) turn off the option to tolerate slightly inaccurate census dates which would mean that dates MUST include the census date; or
2) leave it on and have a CENSus fact and a RESIdence fact

given the effort you have put into tiding up your data I suspect the best option for you is to turn off the tolerate slightly inaccurate dates option and then to fix any dates that then show up as errors. eg: where you have the census as 01/04/1911 instead of 02/04/1911. In saying it was ok to have a range of dates I was thinking about RESIdence facts treated as census facts rather than CENSus facts themselves. A CENS fact really shouldn't be a date range as its a snapshot in time fact type.

Note I'm lazy and usually record the date in my CENS records as just 1911, 1881 etc ie: I put just the year and FTAnalyzer is written to cope with this form of laziness :) It also means I don't need to keep remembering exactly what the census date was in any given year I can just put the year and know it will work.
 
Thank you Alexander.
I am glad that this has been resolved, especially as it does not need program or massive data changes to get things working correctly.
I have inadvertently been using both belt and braces as I have the full date specified for all census records using a crib sheet next to my desk.

I have already changed the husband to have both multi-year RESI and single day CENS so will probably now do the same for his wife.
I am still awaiting availability of the modified report generator from GenoPro which will produce both facts rather than just either RESI or CENS.

As mentioned elsewhere, a date range is just confusing for CENS records.
 
An individual with the following death information in the Gedcom file
Code:
1 DEAT
2 DATE BEF APR 1881
2 AGE 60y 9m
2 PLAC Chester, Cheshire, England
2 NOTE Jan-Mar, Vol 8A, Page 269
produces the following error message when the file is loaded into FTA.

Error with Individual : ind00115: George Pinches
Invalid fact : BEF APR 188160y 9mChester, Cheshire, EnglandJan-Mar, Vol 8A, Page 269.
Error The added or subtracted value results in an un-representable DateTime.

It is as if the data from several lines of the Gedcom file have been concatenated. Have I missed something?What should I change?
I don't get this error anywhere else although I have not specified a BEFORE date of death previously.
It is needed in this instance as I have a note that he died Jan-Mar 1881 and the census date was 03 APR 1881.
FTA does not recognise the death and reports RED for all following census years instead of Grey.
 
You could try Bef 1 Apr 1881?

What date of birth do you have? is it after Jul 1820?
 
An individual with the following death information in the Gedcom file
Code:
1 DEAT
2 DATE BEF APR 1881
2 AGE 60y 9m
2 PLAC Chester, Cheshire, England
2 NOTE Jan-Mar, Vol 8A, Page 269
produces the following error message when the file is loaded into FTA.

Error with Individual : ind00115: George Pinches
Invalid fact : BEF APR 188160y 9mChester, Cheshire, EnglandJan-Mar, Vol 8A, Page 269.
Error The added or subtracted value results in an un-representable DateTime.

It is as if the data from several lines of the Gedcom file have been concatenated. Have I missed something?What should I change?
I don't get this error anywhere else although I have not specified a BEFORE date of death previously.
It is needed in this instance as I have a note that he died Jan-Mar 1881 and the census date was 03 APR 1881.
FTA does not recognise the death and reports RED for all following census years instead of Grey.

This does look like a bug where the age is getting concatenated. I'll investigate.
 
Ok fairly easy one it was subtracting the years from the start date. However for a BEF date the start date is 01/01/0001. Subtracting 60 from that gives a negative year and an error. I've added a fix for this. Note it reported red for all the census entries as it had ignored the death fact due to the error.

I've also noted that I could add a calculated birth fact if it finds facts like this with ages so that's been added as a feature too.
 
You will notice its a calculated birth as it has a comment saying so and where the birth was derived from so you can fix errors if its wrong. Incidentally I've added an option to show "Alias" or Also Known As facts into the display of the persons name eg: Red 'Charty' Dragon.

The new US, Canadian & Irish colour census reports is working but I need to do a bit more testing with the searching on those. Problem is lack of Ancestry worldwide & FMP subscriptions so I can do the testing. I may just release it as is and fix issues as users alert me.
 
You will notice its a calculated birth as it has a comment saying so and where the birth was derived from so you can fix errors if its wrong. Incidentally I've added an option to show "Alias" or Also Known As facts into the display of the persons name eg: Red 'Charty' Dragon.

The new US, Canadian & Irish colour census reports is working but I need to do a bit more testing with the searching on those. Problem is lack of Ancestry worldwide & FMP subscriptions so I can do the testing. I may just release it as is and fix issues as users alert me.

Haha, I bet he's never been called that before!

Yes, release it and let the users test it, it makes sense in this case. And you'd be in good company, isn't that now MicroSoft do their testing? :rolleyes:
 
Back
Top