* TMG to FH import of Flags

[E Wilcock]

There were conflicting answers about whether and how fh handles flags from TMG.

I have one project imported from TMG And it has arrived with the Flag titles intact. So I can see listed the flag ancestral interest - ie all direct ancestors of my Grandmother.

But that doesnt actually mean that the data has come across. A query for people with that flag brings up everyone in the database (presumably because eveyrone has that flag with one value or another) while a proper fh query for the ancestors of my grandmother shows 15 names.

My grand mothers direct ancestors show in fh on the focus window because I selected her as the root person.

Other people report that they have imported flag information in Event tags? I dont see that behavior. May be we could have an update on Flags?

[tatewise]

I am not a TMG expert, but in how_to:import_from_tmg|> Import from The Master Genealogist (TMG) it says "Every Flag is a Flag but the Yes/No/? values are omitted".

So if you have added that ancestral interest flag to everyone in TMG, and set different values on that flag for different people, then that flag will import to everyone in FH but the different values cannot be imported because FH Flags do NOT have values, but simply exist or do not exist per person.

Thus in TMG you need to adapt the flags before migrating in order to get the desired FH effect.
e.g.
Keep all the ancestral interest flags with value Y and delete all those flags with value N, etc.
If in TMG you have complex multi-value flags, then you need to create a TMG flag for each value and substitute appropriately.

In the particular case of direct ancestors of a person such as your Grandmother, you do not need a Flag in FH at all, because the =IsAncestorOf(...) function will do the job instead, and more effectively. That function can be discussed in more detail if required. For example, as you find more direct ancestors of your Grandmother, if you use a Flag then it would have to be manually added to each new Individual record, whereas the function will automatically signal the direct ancestor without you doing anything.

[DonF]

I don't think any reworking of the TMG Flags is required, but one does need to understand how TMG Flags come across into FH - the "Every Flag is a Flag but the Yes/No/? values are omitted" statement is correct, but a little cryptic.

Basic rules - in TMG a Flag can have multiple values, as defined when the flag is setup.
In FH a Flag can only be present (implying a Yes condition) or be absent (implying a No condition).

In the transfer from TMG to FH, any simple Y/N flags (like Living) carry across to FH without issue, with the exception that TMG can also have a 'Living=?' (i.e. "I don't know if they are alive") which becomes a 'No' in FH.

For a multi-value TMG flag, the transfer process breaks up the flag into multiple flag values in FH, so each can still be given a yes/no setting.
As an example, I have a TMG Flag called RELATED_BY, which has potential values of U, S, A, D, C, M (I won't bore you with what these mean). Let's say a particular person in TMG has 'Related_by = D'; in FH, they have a Flag called RELATEDBYD, which is present (i.e condition is 'yes'). Likewise, a person with 'Related_by = C' in TMG has an FH RELATEDBYC flag present, and so on.

As long as you understand this transfer method, you can still test FH flags for the same conditions as were present in TMG without needing to revise anything in TMG.

[tatewise]

Thank you for that explanation Don.
It sounds like FH has improved its import since the Knowledge Base article was last updated, and I will correct it ASAP.

However, that raises two questions.

What happens to a TMG flag with the ? value?

The scenario by E Wilcock does not seem fit your explanation, because in FH everyone has the ancestral interest flag, and there is no mention of a value tagged to the end of the flag name.
I am assuming here that the Query used was the Standard one Has Flag that has a droplist of all FH Flags in which it would be obvious if there was a series of ancestral interest flags with different value suffixes.
Alternatively, a custom Query could have been written that just matches ancestral interest against the Flag name and might match all such Flags whatever the suffix.

[johnmorrisoniom]

Mike,
If the flag name is too long FH truncates it (The limit is about 7/8 characters) you can see the effect by opening the flags file in a text editor (Which can also be used to change the names) You can also see the internal flag names using the data assistant on a query.
So, to Quote DonF's example above, all those TMG flags would be imported as the same name because the first 7/8 characters are identical.
John

[E Wilcock]

I have not quite worked this out yet. And I may not be a good case for detailed examination.
I did not often use flags in TMG. The TMG sample Project shows that Ancestor was an inbuilt Flag. And I did not add the flag manually - It was added en masse to a selected list. Most TMG users used Ancestor Interest in conjunction with a colour to mark the names on People lists.

As Mike says, the visual marking of ancestors of the root person is completed automatically in fh and can switch the tick marks from one person to another by changing the root person in the Project.

Mike is correct that I used the inbuilt fh query to bring up the list of people with the flag. And that when running the query, my TMG flags showed up in the list of available flags.
Apart from using this query, I do not know any other way of seeing whether or not an a person has a fh flag? Is there any way? For instance from the Property box when they are the focus person?

The issue of flags came up in the context of marking my direct ancestors on a website list. When making a site from a TMG Project using Second Site software, an icon could be selected to mark these direct ancestors in the indexes. I need to update one of my website trees and wanted to do the same using fh and Gedsite. John Cardinal told me via the Gedsite Group list that this was part of the future plans but not yet possible. And that Gedsite would not be using the Flags from the source software.

Import of TMG flags isnt a big problem for me. My only other use of flags has been with values Yes and ? - e.g. Killed in action for a first world war project. I never used Flags in negative cases. I could at some point do a trial import of another TMG Project and report back.

But I have been using flags more in fh - so the exportability of information from fh Flags or named lists might worry me and that needs another thread.

[tatewise]

You can see Flags attached to Individual records a number of ways.
In the Records Window each Flag can be added via Lists > Configure Record Window Columns.
In the Records Window click the [+] against a persons name to expand all and Flags are listed at the bottom.
In the Property Box on the All tab they are similarly listed.
In the Property Box a custom tab can be added with a tick entry for each Flag.

John, I don't think Flag names are as limited as you suggest.
The V6 Family Historian Sample Project has two Flags named 1901 UK Census and 1911 UK Census.
Their tags are __1901_UK_CENSU and __1911_UK_CENSU i.e. truncated at 13th character ignoring leading underscores.
I have also edited the Flags.fha file with Flags such as RELATEDBYALPHABETICAL and RELATEDBYBRAVO.
Those remain intact and keep the full tag in both the Flags.fha file and in the Gedcom file.
So the restriction imposed on manually created Flags may not be applied to imported Flags from TMG.

I also note that Don says a TMG Flag such as Related_by=C becomes RELATEDBYC in FH where the punctuation symbols have been discarded, so it seems likely that for Related_by=? the ? will get discarded giving RELATEDBY.

If anyone can confirm those findings with actual imported Flags from TMG then it would help our understanding.

[johnmorrisoniom]

Mike,
Thanks for the clarification.
I was on V4 when I last seriously looked at flag names, so the character limit may have been lower then.
I have greatly reduced my use of flags, and now tend to use them mainly to show "Not in 1911" etc to show that I have looked very hard, but not found.
John

[brianlummis]

Mike

In TMG you defined the default value of the flag, and to give an example I used the Ancestor Interest flag in my project. This meant that all the individuals in my TMG project had a N flag as this was the default unless they had been amended to Y.

In FH, using the TMG Import, I now have flags (which incidentally I have not used) for Ancestor Interest where Y was used but those with a N or ? have been discarded.

From the other threads in this topic it would appear that FH during the import defines the flag as being Y or N and if these are not already present concatenates the name with the qualifier as described by Don so that there can be a binary choice leading to the creation of a new flag.

Brian

[tatewise]

Thank you Brian for those extra special cases for Y and N values.
But that does not explain how E Wilcock has imported the same Flag on every Individual in FH.

Is one explanation that the Ancestor Interest flag with value Y becomes Ancestor Interest in FH, and if it has no value it also becomes Ancestor Interest in FH?

[brianlummis]

Is one explanation that the Ancestor Interest flag with value Y becomes Ancestor Interest in FH, and if it has no value it also becomes Ancestor Interest in FH?

I don't think so - as I said, there has to be a default value in TMG so there is no opportunity to leave it with no value - for Ancestor Interest the normal qualifiers are Y,N or ?.

I unfortunately don't have a copy of TMG on either of my computers but I have just imported the TMG Sample project into FH and it does seem to follow the criteria of only importing those flags with a Y qualifier. Bizarrely, the project, according to FH, has only one person without an Ancestor Interest Flag , which is May Florence Corbauld-Warren, so if anyone has a copy of TMG and could run the Sample Project to check if this is the case then it would prove the theory that FH only retains the Y value. For clarification I am using the UK Sample Project which I believe shipped with the UK Version of TMG 9.

[tatewise]

I have an expired free trial copy of TMG and looking at the Ancestor/Descendant Interest flags they have numerical values 0 to 3 to indicate the level of interest, unlike others that have Y & N values.
When the Sample project is imported into FH almost everyone has the Ancestor/Descendant Interest flags, whereas only a few have the others.
So it seems that FH does not append numerical values to the flag name.

[brianlummis]

Mike

The 0 to 3 sounds more like the surety value rather than the flag value. Perhaps I had better dig out my old TMG program and fire it up.

Brian

[tatewise]

The Help page clearly explains those Flags indicate levels of interest.

The ANCESTOR AND DESCENDANT INTEREST flags can be used to indicate your level of interest in a particular ancestor or descendant. For example, 3 might be used for a direct ancestor or descendant.

Also

The MULTIPLE BIRTH flag designates a person who is part of a multiple birth -- 2 for twins, 3 for triplets, etc.

[brianlummis]

Sorry Mike, my mistake due to the way I used the Ancestor Interest in my project where I had a straight Y or N. To me someone is either an ancestor or isn't!

Having reinstalled my copy of TMG (and had lunch) I have now had a look at the Sample Project again. It seems that Calico Pie made the decision to import all the Ancestor Interest flags with a value between 1 and 3 as the only person with a 0 flag is May Florence Corbauld-Warren and is not flagged in the Sample Project when imported to FH. So if E Wilcock used the TMG flag values, that could explain why the flag is being seen so many times. In TMG the first value listed becomes the default so if the order has been changed from the original value of 0 it could be that everyone is then included upon import.

Brian

[tatewise]

Yes, that matches what I am seeing.

In order to distinguish the different numerical values would it be easy in TMG to substitute letters (or words) in place of the numbers by some automated process, such that 3 becomes HIGH or H, and 2 becomes MED or M, and 3 becomes LOW or L. Then those values would become part of the FH Flags on import.

[brianlummis]

Unfortunately it appears as though the Standard flags cannot be edited - from the help:-

The standard flags (SEX, LIVING, BIRTH, MULTIPLE, ADOPTED, ANCESTOR, DESCENDANT) cannot be edited. Their Edit screen will be view-only. Any standard flag may be disabled so that it does not appear in the Flags window.

I think that is why I decided on a new flag with the simple Y/N option.

Brian

[brianlummis]

Thinking on this further there are a couple of options that might be viable but are dependent on the criteria used when applying the flag in TMG.

It is possible in TMG to change the value of the flag in bulk using Reports. The List of People report allows for the selection of a Flag with a specific value and then using the Options button - Secondary Output tab define a new value for that Flag. So, for example, if for Ancestor Interest you had a value of 1 which you wished to exclude from the import to FH, you could change it's value to 0 by running that report.

To meet the requirement of changing the value to HIGH/MED/LOW you could take this one step further by adding 3 new Flags in TMG, e.g. Ancestor Interest High with a Y/N value, then for that Flag using the List of People report filter all those with Ancestor Interest value 3 and using Options/Secondary Output allocate the new Flag with a Y value. Once all the new Flags have been defined then the original Ancestor Interest Flag could be disabled which I think will exclude it from the Import. If not the values could all be set to 0 using the method in the previous paragraph.

Brian

[tatewise]

If E Wilcock is still following this thread, that may offer a solution. Thanks Brian.

Do you know, or can you find out, if the following rules are generic, or are any limited to standard flags only?
When importing TMG Flags to FH Flags they are converted as follows:

• A TMG Flag with value N or 0 or ? is discarded and no Flag appears in FH
• A TMG Flag with value Y or number 1 or greater produces an FH Flag of the same name
• A TMG Flag with any other value produces an FH Flag with the same name but suffixed by the value
• Any punctuation symbol in the Flag name is discarded, and each space replaced by underscore in the underlying tag and is truncated to ?? characters

If those are valid I will add them to the how_to:import_from_tmg|> Import from The Master Genealogist (TMG) advice.

[brianlummis]

Mike

I can experiment to see under what conditions Flags are imported but perhaps the best way of getting a definitive answer is to ask Calico Pie. I will drop them a line with the query.

[DonF]

Being out of UK timezone makes it difficult to keep up, but here's some more info. The claim that FH truncates TMG flag names to 7/8 characters is incorrect (it seems to be 13) - the 'RELATED_BY' examples I quoted above are real ones, and I'll add to that below.
Firstly though, when I gave my example I was reading direct from the GEDCOM data that FH stores, and so my example was possibly misleading - FH stored a GEDCOM Flag name (in this example) of RELATEDBYC (or -D, etc) with a value of 'Related_by_C'. So what you see as displayed by FH as the Flag belonging to this person is the 'Related_by_C' value. And its presence implies the value of 'Yes', absence implies 'No', as I have explained.

Now to Mike's rules:

When importing TMG Flags to FH Flags they are converted as follows:
A TMG Flag with value N or 0 or ? is discarded and no Flag appears in FH
A TMG Flag with value Y or number 1 or greater produces an FH Flag of the same name
A TMG Flag with any other value produces an FH Flag with the same name but suffixed by the value
Any punctuation symbol in the Flag name is discarded, and each space replaced by underscore in the underlying tag and is truncated to ?? characters

Rule 1: agreed. An N value means No, so there will be no FH flag; '?' is something FH doesn't know what to do with, so it discards it, implying 'No' in the FH world (which is disconcerting for TMG Living=? flags as the meaning changes drastically); and 0 is also discarded, implying 'No'
Rule 2: agreed. TMG Y flag becomes an FH flag (implied Yes); any number > 0 also becomes an FH flag (implied Yes). So a TMG MULTIPLE BIRTH flag set to 2 (twins) or 3 (triplets) loses its meaning and just becomes 'yes, it was a multiple birth' in FH
Rule 3: agreed, in as much as that is how my RELATED_BY flag was converted.
Rule 4: this is more complicated and random. Best thing I can do is give you the GEDCOM code - this is for a chap who is a Living twin, a cousin (hence Related_by=C) and who has both Ancestor Interest and Descendant Interest flagged as '1' in TMG (although I don't use those flags, just set it up for this test). His FH GEDCOM FLAG section reads like this:
1 _FLGS
2 __LIVING Living
2 __MULTIBIRTH Multibirth
2 __ANCESTOR_INTE Ancestor Interest
2 __DESCENDANT_IN Descendant Interest
2 __RELATEDBYC Related_by_C

The TMG Ancestor/Desc Interest flag names do not have an underscore connector (that has been inserted by FH), and FH has truncated at 13 characters; in TMG the multiple birth flag name is 'MULTIPLE BIRTH", but FH has changed it to 'Multibirth'; and you can see what has happened to my relationship flag.
So I think your Rule 4 is difficult to write, as Calico Pie have made some arbitrary decisions of their own (like in multibirth).

[DonF]

To add to my own post above, on further reflection, Mike is correct when he said TMG users may have to convert some flags into simple Y/N options.
MULTIPLE BIRTH is a perfect case in point - in FH it just becomes a straight Y/N answer to whether it was a multiple birth, having lost the TMG numbering of 2, 3, etc. In this case a TMG user would first create a TWINS flag (possible settings of N (preferred) or Y). As also noted above, the TMG user would then run a TMG List of People report, choosing a Filter of 'all MULTIPLE BIRTH =2', and set a Secondary action to change the TWINS flag to Y. Repeat this process for a TRIPLET flag and QUADS as well if needed(!) and then the MULTIPLE BIRTH flag would become redundant. If it was also reset to be N for everybody, then the FH conversion would effectively ignore it and the TWINS, TRIPLETS etc flags would have real meaning in FH. Simples.

[E Wilcock]

Yes indeed I have followed this thread and appreciate the trouble that has been taken and the clarity of the explanations.

I followed the thread with care because software is entirely logical whereas users are not. I like to understand how software is working. And you provide explanations.

This is not a major problem for me just now - I have deleted as redundant the TMG ancestor and descendant flags from the Project now in fh. And I had no others.

But you have all done great work on updating the guidance to anyone importing to fh from TMG. And if among my hap hazard and inconsistent use of custom flags in TMG projects I come across one that I need to import, I shall know how to do it. Thank you.

[tatewise]

Thank you, that gives me enough to update the how_to:import_from_tmg|> Import from The Master Genealogist (TMG).
See the Import Guide under Flags, and the Import Discussions cross-reference to this thread.

[brianlummis]

Mike

I have been out all day but I have received a response from Calicoe Pie. Unfortunately, one of their stated rules is not what happens in practice so I have gone back seeking clarification. It would appear that there is either an exception to one of the rules or that rule is not working as intended. Critically it relates to the Ancestor Interest/Descendant Interest Flags.

Brian