* small rearrangements with subtle consequences

[Ron Melby]

How can I prevent FH 6.2.2 from rearranging this:

1 EVEN
2 Type Mortuary
3 PLAC Herman Munster and Sons, Wadena, , Wadena, MN, US
1 BURI
2 DATE 1944
2 PLAC Wadena Cemetery, Wadena, Wadena, Wadena, MN, US
2 SOUR http://www.findagrave.com/cgi-bin/fg.cg ... =111421065
2 SOUR @S101@
2 SOUR @S5@

to this:
1 BURI
2 DATE 1944
2 PLAC Wadena Cemetery, Wadena, Wadena, Wadena, MN, US
2 SOUR @S5@
2 SOUR http://www.findagrave.com/cgi-bin/fg.cg ... =111421065
2 SOUR @S101@
1 EVEN
2 Type Mortuary
3 PLAC Herman Munster and Sons, Wadena, , Wadena, MN, US

Throughout my file?

[tatewise]

On a technical point it should use capital 2 TYPE and 2 PLAC (not 3 PLAC):
1 EVEN
2 TYPE Mortuary
2 PLAC Herman Munster and Sons, Wadena, , Wadena, MN, US

In Tools > Fact Types for Mortuary I have its Normal Time Frame set to Post-Death and it always sits between Death and Burial once sorted into order by using Tools > Re-order Out-of-Sequence Data.

[Ron Melby]

I am quite sure it is as you say. I am doing from memory. But now I see that I need to go fix in tools and do the timeframes. So I have one question answered. We will mark that solved, thank you.

The other is more troubling, that it moves the findagrave source from where I want it.
from this:
1 BURI
2 DATE 1944
2 PLAC Wadena Cemetery, Wadena, Wadena, Wadena, MN, US
2 SOUR http://www.findagrave.com/cgi-bin/fg.cg ... =111421065
2 SOUR @S101@
2 SOUR @S5@

to this:
1 BURI
2 DATE 1944
2 PLAC Wadena Cemetery, Wadena, Wadena, Wadena, MN, US
2 SOUR @S5@
2 SOUR http://www.findagrave.com/cgi-bin/fg.cg ... =111421065
2 SOUR @S101@

[tatewise]

That findagrave SOURce is not a Gedcom Source Record Link, which must have the format SOUR @S123@
It is what is known as a Source Note with plain text, that FH always positions after Source Record Links.
I guess you are trying to edit the Gedcom file outside FH, which is NOT recommended unless you know EXACTLY what you are doing.

The two Source Record Links for SOUR @S101@ and SOUR @S5@ should be maintained in your desired order.

If you wish to cite the findagrave website then first create a Source record for it.
Then use the Add Media URL Shortcut Plugin to create a Media record and file for the website URL as advised in how_to:v4:adding_multimedia|> Adding Photographs and Other Multimedia and link that Media record to the Source record Media tab where it can be clicked to open the URL.
Finally, in that Burial Event add a Citation to that Source record.

[Ron Melby]

I saw that. My understanding of it is I would have to create a separate source for each findagrave url.
If that is incorrect, then I dont know how to do that thru a source of findagrave, each link to its own page.

I cant even find a way to delete a name from within the alternate name list, when both windows are focused on the person I want to remove names from. (a problem from the merge). I have to do a great deal of fixing of the gedcom by hand, there is no way to do it in FH. Nor can I find a way to automerge citations. its all click and paste. Easier to take into a text editor and scan and replace.

[LornaCraig]

To delete an alternate name, open the Property box for the individual. On the Main tab, just to the right of the Name, click on the word more...
This will open the Names & Titles window. Alternate names are listed in the lower section. Select a name to edit, delete, move up the list, down the list, or to make it the Primary name.

[tatewise]

"I would have to create a separate source for each findagrave url."
Yes, but that is no different to creating a Source for each Birth Certificate or each Death Certificate.
The only way to have active URL hyperlinks in FH is via Media records, but there are two ways to link to a Fact.
1) Directly to the Fact via its Show Media button and Add Media for Fact button.
2) Via a Citation of a Source record, either with one Media URL per Source, or all Media URL linked to the Media tab of one Source record, and the appropriate URL identified in the Citation field Where Within Source.

"I cant even find a way to delete a name from within the alternate name list"
From Property Box > Main tab, click more (+)..., select the Alternate Name and hit Delete button.
From Property Box > All tab, select the Name field on left to delete and hit Delete key or use Edit > Delete.

"Nor can I find a way to automerge citations."
Do you mean merge Source records, which can be done by opening the Records Window on Sources tab, select the two Source records, and use Edit > Merge/Compare Records.

Other changes not supported directly in FH can usually be handled with a Plugin.
If you choose to edit the GEDCOM file directly, then expect FH to complain or adjust it if it is not valid.
Remember that although there is only one GEDCOM formal Release 5.5, there is also Draft 5.5.1, and different products (mis)interpret GEDCOM in various ways, or add their own product specific user-defined extensions.

[Ron Melby]

I know about the merge sources, again, click and click and click. There is no merge citations as there is a merge files.

I will look at the other name thing, I must have been using another window, all that was available was add, in alternate names.

I wish I didnt have to hand code so much, but this file came from about 20 years worth of gedcom releases, and all sorts of monkey business Occupations in place names, events in occupations, and the like, and all on ancestry, and downloaded from there.

I have tried loading it many times and have actually done considerable work within Family Historian already.

[tatewise]

Ca you explain exactly what you mean by "merge Citations"?
I cannot see how it relates to Merge Files.
Taking your earlier example of two Citations on a Burial Event:
1 BURI
2 SOUR @S101@
2 SOUR @S5@
How would they be merged?
I can only imagine that would involve merging the two Source records S101 and S5.

If you can clarify what you mean, maybe I can write a Plugin to do it for you.

Ancestry is one of the worst offenders for misusing GEDCOM, but as they are such big players, they can get away with it.
Maybe they have done it deliberately to make it difficult to migrate away from Ancestry.

[Ron Melby]

yes, lets say I go to the sources merge:
@S55@ 1900 US Census
@S101@ 1900 US Census
@S1900@ 1900 US Census

rather than find and click, and click and click, it would be handy to have a utility that works exactly like the merge individual records utility.

I dont have the window handy, but it should be intuitively obvious what I mean.

Even if it did only two at a time and I needed to rerun it.

so I would have the *Merge* @S55@ 1900 US Census @S1900@ US Census
50% @S1127@ 1855 Minnesota Census @S2123@ Minnesota 1855 Census

[Ron Melby]

Regarding your comment about ancestry.....Yeah.....therein is my experience and problem.

Here is how my gedcom is, since I did not have FH a long time ago, and would like to combine sources wherever possible, for a go to war session on familysearch

1 CENS
2 DATE 10 Jan 1900
2 PLAC , Mazeppa, Wabasha, MN, US
2 SOUR @S1900@
2 PAGE, 15B, Roll T625_142, EnumDist 65
3 TEXT Sibley, Henry Howden 47, born NY, with wife Henrietta 45, Born NY and children yadda yadda and blah blah.
4 RELA relation to head of household:head.

I have 4 years in doing this by hand (and still have error after error left to fix (not all programmatical, just putting them in a form that will be read by FH correctly. A great number of "errors" come from not having things numbered correctly, and I wish there was a model of different types of records with "full bore" formats and situations to learn from, because there are not enough interpreters in the world to get the correct numberings from the standard. Its celerity is that of the Ancestry FTM files. And the sample project isnt very complex really.

for instance I get no complaint from FH at this:


1 CENS
2 DATE 10 Jan 1900
2 PLAC , Mazeppa, Wabasha, MN, US
2 SOUR @S1900@
2 PAGE, 15B, Roll T625_142, EnumDist 65
2 TEXT Sibley, Henry Howden 47, born NY, with wife Henrietta 45, Born NY and children yadda yadda and blah blah.
2 RELA relation to head of household:head.

it is unclear why and when a one up number is needed.

I am trying to punch this in the most standard way I can, and am not going to start over from scratch.
Why? Because every source in this file is suspect, and before I break them out I need to get real evidence by actual seeing it. (I have no images or documents or pictures attached at the moment)\
I need to share the final gedcom with several other family members with different software.
I have found numerous factual errors and file errors as I have worked on this.

Although getting the documents out of the .ftm file I am going to try. I cant see most of them.

[tatewise]

I still don't understand what it is you are combining. Your illustration is a simple single regular Source Citation.

To comprehend how tags and level digits go together you need to study the fhugdownloads:contents:gedcom_standard_release_5.5|> Utility ~ GEDCOM Standard Release 5.5 PDF document, and possibly the Draft 5.5.1 variations. Specific tags are only valid in certain hierarchies at certain levels. You cannot successfully mix any tags you fancy at any level you fancy.

You can use FH to obtain a full bore model of each type of record :-
Start by choosing your record type: INDIvidual, FAMily, NOTE, SOURce, REPOsitory, OBJEct, etc, etc.
In the Records Window on the appropriate tab, create an empty record, open its Property Box and select the All tab.
Right-click the record Name/Title and all the available level 1 options can be selected in turn.
Create at least one of each option, and where feasible enter some descriptive text.
Repeat right-clicking for each level 1 item to create level 2 items, and so on until all levels and items are exhausted.
Then repeat that whole process for the next type of record.
Save the results and you have a GEDCOM file with a model of all the tag options and levels.

Your example Source Citation has several structural errors, and although FH may not complain, it will not accept it as recognisable data, but will keep the erroneous tags as Uncategorised Data Fields (UDF), which on the All tab will appear as star bullet items. See how_to:handling_unrecognised_data_fields|> Handling Uncategorised Data Fields (UDF).
The correct structure should look like this:
1 CENS
2 DATE 10 JAN 1900
2 PLAC , Mazeppa, Wabasha, MN, US
2 SOUR @S1900@
3 PAGE , 15B, Roll T625_142, EnumDist 65
3 EVEN CENS
4 ROLE (relation to head of household:head.)
3 DATA
4 TEXT Sibley, Henry Howden 47, born NY, with wife Henrietta 45, Born NY and children yadda yadda and blah blah.

[Ron Melby]

Yeah, I have read the 5.5 standard, as I stated before, the celerity is that of Ancestry's FTM. I was a computer programmer by trade and have programmed assembly language and broken into the supposedly secure iSeries operating system. I have seen some useless documentation and that standard is at least the penultimate of useless. For example:

This is legal according to the standard.
1 DEAT
2 DATE Blah blah blah
3 PLAC blah blah blah
^^^ (p 60)
1 SSN (p30)
1 EDUC(p29)
1 EVEN (p31) <<< and that is not clear that must be done by the standard.
1 CAUS (p29) or if we pretend a lot...
1 EVEN
2 CAUS
and I would expect them to stay in that order, at that level.
or it can easily be interpreted to be:
1 DEAT
2 DATE
3 PLAC
2 CAUS which is what I have now.

Therein lies the problem. The full bore model make will help me greatly. Guess what I am doing tonight? I will make a model, and that is absolutely the bomb, I cant thank you enough. This will get me into the 21st century in no time, having the structured examples. Then I can actually work in the software consistently, and get me a grand genealogy.

[tatewise]

I agree the standard is a little difficult in places, and it it has a few contradictions, but I've seen worse.

Your example is NOT legal according to the standard, for the reasons given below.
1 DEAT
2 DATE Blah blah blah
2 PLAC blah blah blah (PLAC is NOT a valid subsidiary tag of DATE so must be level 2)
^^^ (p 60)
1 SSN (p30)
1 EDUC (p29)
1 EVEN (p31)
2 TYPE Election (p32 says 2 TYPE is mandatory for 'other' general/custom facts)
2 CAUS (p29) (EVENT_DETAIL and thus TYPE and CAUS are +1 level below the EVENT/ATTRIBUTE_STRUCTURE)

Tags at the same level can be in any order, but level 2 tags must remain under their parent level 1 tag, and level 3 tags must remain under their parent level 2 tag, and so on.
In the above example, it would be reasonable for the 1 DEAT tag (together with its 2 DATE & 2 PLAC tags) to be moved below the rest, because Death should follow Education and Election.
But all the facts have no definite order, even if they had 2 DATE tags, since it is up to the receiving system to interpret them as it sees fit.
FH allows them to be sorted into DATE order, but otherwise uses Default Time Frame order, or the file order.