FTAnalyzer and GenoPro

[Bryman]

I hope this is a reasonable thread for me to add this item. The download problem thread that I was about to use did not seem to be appropriate any more.

I have converted more of my census notes information into Contact and Source records for 3 people in my GenoPro 'test' environment, trying to keep similar fields completed for them each. Information has been entered for 1891, 1901 and 1911 censuses. The Lost Cousins tab was created as 1891 (N), 1901 (N) and 1911 (Y) in each case, according to instructions elsewhere on this forum.

GenoPro then created a Gedcom Report with dissimilar facts for the 3 subjects.
Subject A): no fact for 1891, RESI for 1901, CENS for 1911. - I will have to follow up with developers as to why this not similar to B and C.
Subjects B and C): RESI for 1891, RESI for 1901, RESI for 1911.

When loaded into FTA this produced the following colours in the LC Census Report:
Subject A): RED for 1891, RED for 1901, YELLOW for 1911.
Subjects B and C): RED for 1891, YELLOW for 1901, YELLOW for 1911.

1. Why aren't all 3 subjects GREEN for 1911?
2. Why is YELLOW possible for subjects B and C in 1901 (not LC year)?

I hope this is not too difficult to understand.

Also, what fact is expected to be produced for the Lost Cousins tab? I cannot see anything appropriate in the Gedcom file.

 

[Alexander Bisset]

Hmm sounds like the code for colours may have a bug can you submit a bug report on the website and include an example GEDCOM if possible. That way I can see what the code is doing with the various years and why it isn't working for you.

 

[Tim]

Hi Bryman,

Can you attach your GenoPro test file here? I will open it and have a look and see if I can spot something for you?

It sounds like you may not have selected the media type Census, but I'm going from memory.

 

[Bryman]

Sorry for delay folks, I needed some sleep (I'm in NZ).

I have tried to attach the .ged file (via Upload a File?) but am told that no files match requirements although file exists and file type is included in list.

Please tell me what I should be doing.

 

[Tim]

You might have to zip it first, and then attach the zip file.

 

[Bryman]

Thanks Tim.

Attached file contains several subjects but main ones referenced before are:
A - William John
B - Elizabeth Margaret (wife)
C - Alfred William (brother)

 

[Alexander Bisset]

Thanks a prefect example of a limited subset of data that shows the issue. That made it really easy to step through and find the issue, many thanks. I've have now fixed that issue and the fix will appear in the next release.

The problem was caused by the unusual (note nothing wrong with it just unusual) method of recording census dates. The dates all seem to be expressed as AFT xxxx. So you get a RESIdence fact saying they are resident at the location AFTer the census date. The more common way of recording is to have it as an exact date (ie: census night) or a year or an ABT. AFT has the connotation that it is sometime after that date, when in fact they may have been moving on census day and been recorded at their old address, only to be at a new address AFTer the census night. So logically AFT feels unusual.

 

[Bryman]

Sorry Alexander, I'm still getting used to how best to use the available system. Your comments may help me record things better.

The limited subset of data is actually my whole genomap for that surname. I then use the GenoPro external hyperlink facility to cross-link to other surnames. This keeps most sub-trees to a reasonable size and easy to handle. I am gradually finding some disadvantages with this approach but feel it is worth continuing at the present time.

Originally, I recorded census information as my own formatted note in the comment fact. This made it very easy and quick to copy to other people recorded in the same census entry. However, that is not a form which programs can usefully access so I am trying to make the recording more formal, using the existing template. If I enter the census date for both Start Date and End Date for the Contact then it would look as if occupancy was only for a single day. That is why I have left the note in the comment while I try to decide how best to proceed.

 

[Alexander Bisset]

Ah I understand the confusion. I'm not sure how exactly GenoPro usually records dates but I'd have expected that recording the actual census date rather than an AFT or BEF could be read as "they were at that address on this date, I don't know if they were there before then or after then."

I think that's what most dates are. eg: How do you do a marriage date? It is an event the date should surely be entered as the exact marriage date if you know it? Recording the location they were at on the day and possibly recording residence facts for the participants on the day?

That's how I'd think about it a date if its an exact date says that was true on that date, I cannot be sure what was true before or after that date.

 

[Bryman]

I agree with your thinking but the Contact information seems to be set up for recording the duration of an occupancy.
A marriage date would only have a single value and any AFT or BEF would only indicate uncertainty.

 

[Tim]

Hi Bryman,

Sorry for the delay, just got caught up in lots of things going on. I've opened your file in GenoPro and had a look at the names you mentioned. Things are now making more sense and we now have a bit more hindsight that we can bring to the table.

So, on your Custom Tags tab, you have the ability to create a CENS and RESI fact, however you can't add multiple census years this way. Unfortunately this is not a solution.

It appears that the Contact tab does create a RESI entry, but as you've discussed above it adds a FROM date.

But, it looks like we've had a stoke of luck!!

I've discovered that if you add a start date of 1911 and and end date of 1911, then it produces a RESI fact with a date of 1911 only.

So it appears all you need to do is to create a Contact Entry, enter the address, type = primary residence, source = 1xx1 census, start date = 1xx1 and end date to match the start date.
e.g.
occupancy place = 1 Some House, Somewhere
type = primary residence
source = 1911 census
start date = 1911
end date = 1911

You need to add the Lost Cousins Tags, I've entered them on the example you've sent me and tested them and they create correctly in FTA. I tested them on Elizabeth b1856.

So in summary, if you create a contact for each census for each person, then you can import directly into FTA.
If you then populate the Lost Cousins tag with a "Y" for the people you have entered at Lost Cousins for those years, then you can use the full functionality of FTA.

 

[Bryman]

Thank you Tim, I feel that we are getting there, slowly, one step at a time.

The new version of FTA 2.0.2.0 has corrected the coloured table entry for non-LC years but LC years are still shown as Yellow even when the LC tag is 'Y'.
However, that is probably not an error within FTA as I can find no indication in the ged file for the presence of such a tag. That would seem to be a short coming of the Report Generator within GenoPro and should be followed-up elsewhere. BTW, what gedcom record is expected by FTA to indicate that LC has been updated?

I had already tried specifying the same Start Date and End Date for Contacts but had used the date of the census rather than just the year.
Perhaps that is trying to be too accurate. Not knowing when the family actually moved to those premises (nor when they left) I also tried recording the Start Date as before the census date and the End Date as after the census date but FTA did not like that.

I am still concerned about the lack of CENS records. FTA is able to process RESI records in place of CENS but there seems to be yet another problem with the gedcom file generator which only creates the first CENS record and then no further such records. I cannot see any reason for this. Shouldn't there be a CENS record created for every Source entry which has a Source Media Type of Census?

The original concern about FTA would now seem to have been resolved so is there another part of the forum where these other matters can be discussed?

BTW Alexander, I love the automatic program update when the program is started. Well done.
Might it be possible to display a mention of the functional changes when such an update has been performed?
A full list of all changes since the old replaced version would be nice but that might be asking for too much.

 

[Tim]

BTW, what gedcom record is expected by FTA to indicate that LC has been updated?

My GenoPro gedcom produces this code.

1 EVEN
2 TYPE Lost Cousins
2 DATE 1911

The file I sent back should produce this code when you create a gedcom.
When you created the custom tag, it did say "Lost Cousins"? Advice on creating the custom tags can be found here.

I am still concerned about the lack of CENS records. FTA is able to process RESI records in place of CENS but there seems to be yet another problem with the gedcom file generator which only creates the first CENS record and then no further such records. I cannot see any reason for this. Shouldn't there be a CENS record created for every Source entry which has a Source Media Type of Census?

It created CENS records for me when I tried it on my file. Assuming you have the latest skin, can you send me a zip file of the .gno file so I can try and replicate it here?

 

[peter]

Can I suggest that in future we DON'T post gedcom files on an open forum, because even though in this case it's a very small part of Bryman's tree, users who come across this discussion in the future might not make the distinction.

Files can be attached to personal messages - that's usually the best option.

 

[Tim]

Thank you Tim, I feel that we are getting there, slowly, one step at a time.

The new version of FTA 2.0.2.0 has corrected the coloured table entry for non-LC years but LC years are still shown as Yellow even when the LC tag is 'Y'.

Hi Bryman,

The latest skin seems to have fault in it which I have passed back genome.

The skin I have been using created an event in this format,

1 EVEN
2 TYPE Lost Cousins
2 DATE 1911

But this latest skin does not create any events!

In case you want to try this older version, I have attached it for you.

This will be why FTA is not working correctly.

 

[Alexander Bisset]

Thank you Tim, I feel that we are getting there, slowly, one step at a time.

The new version of FTA 2.0.2.0 has corrected the coloured table entry for non-LC years but LC years are still shown as Yellow even when the LC tag is 'Y'.

The issue is with it recording the census date eg : AFT 03 APR 1881. Now the check is does the date in the fact overlap the exact census date. Well for 1881 yes it does. However after 03 APR 1881 also overlaps 1891, 1901 and 1911. The issue is the way the date is being presented.

BTW Alexander, I love the automatic program update when the program is started. Well done.
Might it be possible to display a mention of the functional changes when such an update has been performed?
A full list of all changes since the old replaced version would be nice but that might be asking for too much.

If you visit the website there is a page called downloads that lists each version and what the summary of the fixes were. For a detailed list of fixes for each and every fix I "commit" to the server you can view this list.

 

[Tim]

Hi Bryman,

Well I've had another conversation with Genome, and he reminded me that I'd added some code into the skin so that I could export the Lost Cousins tags in the gedcom. Adding this code is doable for some people but probably not for the majority.

However, he has added some new functionality to be able to record different events. See this post here.

And so there is a new way that you can record that someone has been entered on to the Lost Cousins site.

On the Occupation tab, add a new record called |EVEN|Lost Cousins in the Occupation/Profession/Job Title box and in the start date field add 1911 and in the end date field add 1911. This then exports out correctly.

You can even add the RESI fact here, thus doing away with the need to add a census record.
I managed by adding |RESI|Age: 72; Relation to Head of House: Head (add the data you want here) in the Occupation/Profession/Job Title box, add the address of the census in the Work Place box and n the start date field add 1911 and in the end date field add 1911.

I've attached a sample so that you can see what I did.

 

[Tim]

The issue is with it recording the census date eg : AFT 03 APR 1881. Now the check is does the date in the fact overlap the exact census date. Well for 1881 yes it does. However after 03 APR 1881 also overlaps 1891, 1901 and 1911. The issue is the way the date is being presented.

That style of formatting has been entered by Bryman. The method I've described above negates the issue now

 

[Bryman]

And so there is a new way that you can record that someone has been entered on to the Lost Cousins site.

On the Occupation tab, add a new record called |EVEN|Lost Cousins in the Occupation/Profession/Job Title box and in the start date field add 1911 and in the end date field add 1911. This then exports out correctly.

You can even add the RESI fact here, thus doing away with the need to add a census record.
I managed by adding |RESI|Age: 72; Relation to Head of House: Head (add the data you want here) in the Occupation/Profession/Job Title box, add the address of the census in the Work Place box and n the start date field add 1911 and in the end date field add 1911.

Thanks for that information Tim but I think that use of Contact and Source to record census data is easier to understand and more intuitive.
My only concern is the time taken to enter that data and the likelihood of something being missed.
I think that I saw mention of a technique to copy such information to all members of a household at once, which should help considerably.

 

[Bryman]

If you visit the website there is a page called downloads that lists each version and what the summary of the fixes were. For a detailed list of fixes for each and every fix I "commit" to the server you can view this list.

Thank you for the reminder Alexander. I'm sorry to say that I was just being lazy as I couldn't remember where to look for that information.
I have slapped my wrists and pinned a reference above my desk so that I do not forget again.

However, after further thought, some sort of standard reference displayed at the time of update might help point others to the information in the future.
Just a suggestion. It might save you having to repeat your comments, possibly many times.