FTAnalyzer questions.

According to the GEDCOM 5.5.1 standard Address is structured whereas place is typically a single line of text. Address structure is typically used for things like source repository address, submitter address, address of company writing GEDCOM software etc. However it is perfectly valid to be included in a fact.

Code:

ADDRESS_STRUCTURE:=
n ADDR <ADDRESS_LINE> {1:1} p.41
+1 CONT <ADDRESS_LINE> {0:3} p.41
+1 ADR1 <ADDRESS_LINE1> {0:1} p.41
+1 ADR2 <ADDRESS_LINE2> {0:1} p.41
+1 ADR3 <ADDRESS_LINE3> {0:1} p.41
+1 CITY <ADDRESS_CITY> {0:1} p.41
+1 STAE <ADDRESS_STATE> {0:1} p.42
+1 POST <ADDRESS_POSTAL_CODE> {0:1} p.41
+1 CTRY <ADDRESS_COUNTRY> {0:1} p.41
n PHON <PHONE_NUMBER> {0:3} p.57
n EMAIL <ADDRESS_EMAIL> {0:3} p.41
n FAX <ADDRESS_FAX> {0:3} p.41
n WWW <ADDRESS_WEB_PAGE> {0:3} p.42

Code:

PLACE_STRUCTURE:=
n PLAC <PLACE_NAME> {1:1} p.58
+1 FORM <PLACE_HIERARCHY> {0:1} p.58
+1 FONE <PLACE_PHONETIC_VARIATION> {0:M} p.59
+2 TYPE <PHONETIC_TYPE> {1:1} p.57
+1 ROMN <PLACE_ROMANIZED_VARIATION> {0:M} p.59
+2 TYPE <ROMANIZED_TYPE> {1:1} p.61
+1 MAP {0:1}
+2 LATI <PLACE_LATITUDE> {1:1} p.58
+2 LONG <PLACE_LONGITUDE> {1:1} p.58
+1 <<NOTE_STRUCTURE>> {0:M} p.37

As you can see Place is typically just a line of text whereas address can have far more structured details. Place also can optionally have a MAP tag to record Latitude/Longitude. I've not properly handled ADDR tags yet as they are quite rare to find in events and often where they do exist are simply structured versions of PLACe tag. However I really should handle them and use them where a place tag is absent but an address tag is present.

 

Edit: Correction I have handled ADDR tags (I must have added it a while ago and forgotten). Can you provide a GEDCOM snippet of the whole fact where the ADDR record was not loaded correctly. I can then check why its not handling the code as expected.

 

Thanks for the feedback.

 

Not sure Bryman, I think it was Tim that got that fix included. Tim?

 

Yes, there's some code that you add to the skin, I must have sent it to you before?

 

I found this that I posted.

So it depends which way you did it. If you did it by adding code, then you'll need to add the code again. If you followed the new method, then it should have worked and you could ask Genone as it to why it might have stopped.

 

You need to contact Genome.
Genopro have not updated their software for years. Genome has been updating the skins to fix any reporting errors like this.

This is the primary reason that I moved to a newer different FHS. The secondary reason was FTAnalyzer!

Genopro is the best for visualising your tree but falls way behind on the data side.

 

The colours should be hinted at from tooltip popups. Red means a direct ancestor, bold means known to be alive on this census.

It would be useful to capture your initial impressions as a series of questions so that this can enhance the documentation. A fresh pair of eyes asking questions is always helpful.

I'm not quite sure what the "GEDCOM compatible" question means. The program should read any GEDCOM file produced by a GEDCOM v5.5 compliant program. If your ONS data is just in a spreadsheet then that's somewhat more tricky to create a GEDCOM file from, as Excel won't know about family relationships.

Assuming you are talking about a spreadsheet you'd need a bit of programming to generate a suitable GEDCOM format file from the spreadsheet, not that difficult but not that straightforward either. It depends how rusty your programming skills are. Basically a lot of loops to write each field in a separate line. Of course once you have it able to export to GEDCOM you could load the file into any family history program as well as FTAnalyzer.

 

I can't quite recall how you'd exclude people not in UK, I suspect if there is an emigration fact then it would exclude them but I'd need to revisit the logic to remember. It may well just be if they don't have a census record it highlights them, you could find them on the Canadian census for that year for example.

The cut off for those that are too old should be implemented there is a selection box on the census form that implements an upper limit on age, this defaults to 90 years. This does of course depend on the user having actually entered dates for birth/death events. Unfortunately all too often users have no birth or death facts for an individual despite knowing something about them. So for instance if you know Joe Bloggs is the father of Mary Bloggs born 1850, then he must have been born BEF 1834 (assuming you count a default of 16 years old to be a parent - some people will use 14 or even 12). Its a technique that few people use which is surprising as it is extremely effective at giving you narrow date ranges to concentrate searching.

This technique is what the Births/Deaths tab is all about it works out where you already know information about the individual and suggests ways you can narrow down the birth or death dates to more accurate dates than typically just unknown. It is what I call "Loose Births" or "Loose Deaths", by "tightening" up the date range based on known facts you can focus your research better.

 

On your VBA/VB6 (blast from past) census facts export routine if you export it as a CENS fact this is what FTA is expecting. For extra info if you include a PAGE tag as an extra line on the census fact you can put the census reference there. eg:

Code:

1 CENS any comment here
2 DATE 1881
2 PLAC some parish, some town, some county, some country
3 PAGE Class: RG11; Piece: 3580; Folio: 59; Page: 32; GSU roll: 1341857

similarly if you have entered them on Lost Cousins you can add a

Code:

1 LOST COUSINS
2 DATE 1881

Then FTAnalyzer will pickup both the census record and the fact that you've entered the individuals census record on Lost Cousins. To add a page tag to the census record the format of the PAGE tag needs to match one of these regex.

Code:

EW_CENSUS_PATTERN = "Class: RG(\\d{2,3}); Piece: (\\d{1,5}); Folio: (\\d{1,4}); Page: (\\d{1,3}); GSU";
EW_CENSUS_1841_PATTERN = "Class: HO107; Piece: (\\d{1,5}); Folio: (\\d{1,4}); Page: (\\d{1,3}); GSU";
EW_CENSUS_1841_PATTERN2 = "Class: HO107; Piece:? (\\d{1,5}); Book: (\\d{1,3});.*?Folio: (\\d{1,4}); Page: (\\d{1,3});";
EW_CENSUS_1911_PATTERN = "^RG14PN(\\d{1,6}) .*SN(\\d{1,3})$";
EW_CENSUS_1911_PATTERN2 = "Class: RG14; Piece: (\\d{1,6})$";
EW_CENSUS_1911_PATTERN3 = "Class: RG14; Piece: (\\d{1,6}); Schedule Number: (\\d{1,3})$";
EW_CENSUS_1911_PATTERN4 = "Class: RG14; Piece: (\\d{1,6}); Page: (\\d{1,3})$";
SCOT_CENSUS_PATTERN = "Parish: ([A-Za-z]+); ED: (\\d{1,3}); Page: (\\d{1,4}); Line: (\\d{1,2}); Roll: CSSCT";
SCOT_CENSUS_PATTERN2 = "(\\d{3}/\\d{2}) (\\d{3}/\\d{2}) (\\d{3,4})";

PS. The main database application at work is a VB6 app I wrote 15 years ago so nothing really that wrong with VB6 apart from fact support is totally dead for it now. It's why I do almost everything in c# or VBA these days.