Wednesday, January 26, 2011

Test Results page

In case you haven't noticed, Genea-Blogger Randy Seaver has been doing some testing between Genealogy Programs. He details his observations on his blog www.geneamusings.com

As his test results are similar to what has been posted here, there are now links on our Data Tests page at the top of this Blog page. Please stop by and see what Randy has posted.

Thank you.

Thursday, January 13, 2011

Test 21: End Notes - Family Tree Maker to Roots Magic

I have been following Randy Seaver's Blog for a while now. Of late, Randy has been moving is Version 16 Source-Citations, into the Version 2011 Source Templates. In this Blog Entry: http://www.geneamusings.com/2011/01/creating-source-citations-in-family_12.html. He was struggling with how to get this specific record, into the Template. As I also have been cleaning up my Source and Citations in my own file, I thought I would take his example and see how I would approach this record type. I have not run into this type of record (yet), but know that I haven't gotten down to this type of record.

I did a follow up on his blog on the Family Tree Maker User Blog were the steps I used in the Family Tree Maker Template was chosen.:

This Family Tree Maker Version 2011 file was exported into Roots Magic 4, and a Family Group Sheet was generated.


Here is the Endnotes from Family Tree Maker Version 2011.


You will see that the Marriage Citations are very different. In fact, the information that is in the Roots Magic 4 Citations are not even in the Family Tree Maker 2011 Citation. Upper Snake River is not in the Family Tree Maker citation.

The answer is in the GEDCOM file.

0 @S2@ SOUR
1 AUTH Upper Snake River Family History Center and Ricks College (Rexburg,
2 CONC Idaho)

1 TITL "Idaho Marriages, 1842-1996"
1 PUBL Name: Ancestry.com Operations Inc; Location: Provo, UT, USA; Date:
2 CONC 2005;
1 REPO @R1@
1 NOTE
2 CONC "Idaho Marriages, 1842-1996".  Datatbase.  The Generations Network. 
2 CONC Ancestry.com.  http://www.ancestry.com : 2011.
0 @R1@ REPO
1 NAME www.ancestry.com
1 ADDR
1 EMAIL
1 PHON
0 TRLR


That AUTH tag information was in the non-template Citation. Moving that Citation into the Family Tree Maker template, appears to have kept that AUTH information and sent in the GEDCOM file.

Friday, January 7, 2011

Test 20: End Notes - Family Tree Maker to Roots Magic

Please note that this in an intentional Test Number, there are test numbers that are not being used as of this posting.

Test 20 was a One Person file, created in Family Tree Maker with four (4) Sources and One Citation from each source. This test was to see what happens when a controlled, simple, GEDCOM file was created in one program and opened in another. The focus of this file is Source or End Notes.

This test file was created in Family Tree Maker Version 2011. A Family Group Sheet was generated, and the FGS included Sources. For Family Tree Maker, these are reported as Sources:

This image is the End Notes from Family Tree Maker:


This file was then opened by Roots Magic 4, and a Family Group Sheet was generated in Roots Magic. The End Notes in Roots Magic is:


There was no editing, nor reformatting of the information was done in Roots Magic 4. The biggest difference here was how Private Correspondence was reports. The other 3 have some differences as well.

Wednesday, January 5, 2011

A few Zotero screen shots

Zotero was referenced on the BetterGEDCOM wiki tonight ; posting a few screen shots here to support the wiki posting.

 

Monday, January 3, 2011

Test 12: Address and Phone Number

In our continuing effort so show some of the issues in using a GEDCOM file to share information. the Address and Phone Number issue will be addressed here. They have appeared in previous tests,but not investigated.

For this test, and address was added to Family Tree Maker Version 2011.


This is an Address Fact entry. As has been discussed earlier, each Fact in Family Tree Maker can have a Date / Place, Date / Place / Description or Description Only. Since the street address should be in the Description Field (bottom field), the address was entered.

Adding the phone number, as only a Description entry:



The full Fact screen for this test individual is:


A GEDCOM file is then created:

0 @I1@ INDI
1 NAME Place /Name/
1 SEX U
1 BIRT
2 PLAC Bristol, Sullivan, Tennessee, USA
1 BURI Round Hill Cemetery
2 PLAC Marion, Smyth, Virginia, USA
1 ADDR 1114 Windsor Avenue
2 PLAC Bristol, Sullivan, Tennessee, USA
1 PHON 888-555-1111
1 RESI 1114 Windsor Avenue
2 PLAC Bristol, Sullivan, Tennessee, USA
0 TRLR

That GEDCOM file was opened in Roots Magic 4. There were not errors indicated on the import. Here is the Persons screen in Roots Magic 4



The address is there but the Phone Number is NOT.

It should be noted that the Address information was in the Description field and NOT in the Address field that Roots Magic uses.

Understanding that a .LOG file is generated when a GEDCOM is imported into both Family Tree Maker and Roots Magic, an error was discovered.

Unknown info (line 26)
    2 PLAC Bristol, Sullivan, Tennessee, USA

Here is what Line 26 looks like:


1 PHON 888-555-1111

Looking at the GEDCOM 5.5 it appears that the format is correct. However, how and where this entry should be, may be the problem in the GEDCOM Standard.

Sunday, January 2, 2011

Further Place Names in a GEDCOM file - a Follow Up

This is a follow up to the the Burial Fact in the previous blog:

Further Place Names in a GEDCOM file 

This GEDCOM was generated as it was opened in Roots Magic 4 from the GEDCOM file generate by Family Tree Maker 2011.

The Burial Fact looks like this:

1 BURI Round Hill Cemetery
2 PLAC Marion, Smyth, Virginia, USA

In Family Tree Maker, the Cemetery Name was placed in the Description Field. There are no other fields available for a Burial Fact.
 

Trying to understand what was going on, I looked into Roots Magic 4, to see where the Burial Name was located. It was clear that on the edit Person screen, the cemetery name was seen in the Left half of the screen, but when the Burial Fact was seen, the right half of the screen only had the Place name. There is a field, that calls for an Address, Church, or Cemetery Name. But that field was blank.

Looking at the settings for the Burial Fact, there was an option to Add a Description field. Putting a check mark in the field, the Cemetery name now appears in the Description field in Roots Magic.


So, the Cemetery name is present. Exporting this file to a GEDCOM file shows this information in Family Tree Maker 2011.



OK, so far so good. Family Tree Maker and Roots Magic have the Cemetery Name in the Description field. However, the Cemetery Name, in Roots Magic should be in the Place Details. For this test, the Cemetery Name was Moved (Copied and Pasted) from the Description field to the Place Details field.

 


The GEDCOM file now looks like this:

1 BURI
2 PLAC Marion, Smyth, Virginia, USA
2 ADDR Round Hill Cemetery

In Family Tree Maker, there is no ADDR field for the Burial Fact, so the Cemetery Name is lost.

The data was entered into each program, in the format that the program wants the data entered, but when sharing information between Family Tree Maker and Roots Magic, the Cemetery Name is in the wrong field in Roots Magic, but the Cemetery Name is in the Description field in both.

When the Cemetery Name is moved to the Place Details for Roots Magic, the Cemetery Name is lost in Family Tree Maker users.

Not being understanding the GEDCOM standard, but trying to see what the problem might be, this is what is in the standard, as seen HERE:


INDIVIDUAL_EVENT_STRUCTURE: =

  n  [ DEAT | BURI | CREM ] [Y|<NULL>]   {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}


EVENT_DETAIL: =

  n  TYPE <EVENT_DESCRIPTOR>  {0:1}
  n  DATE <DATE_VALUE>  {0:1}
  n  <<PLACE_STRUCTURE>>  {0:1}
  n  <<ADDRESS_STRUCTURE>>  {0:1}

What I see in the first GEDCOM file, the one where the Cemetery Name is seen in both Family Tree Maker and Roots Magic, is that the BURI tag is followed by the Cemetery Name:

1 BURI Round Hill Cemetery
2 PLAC Marion, Smyth, Virginia, USA

But, when the Cemetery Name is moved to the Place Details, the BURI tag is blank, but has the additional ADDR Tag:

1 BURI
2 PLAC Marion, Smyth, Virginia, USA
2 ADDR Round Hill Cemetery

Is the possible problem here, is the lack of specific details about how a Cemetery Fact / Event is to be included in a GEDCOM file. 

I hope that a GEDCOM Technical Person can make a comment about this.

Saturday, January 1, 2011

Further Place Names in a GEDCOM file

In our continuing discussion on how various programs handle a Place Name, a sample test was done from Family Tree Maker Version 2011.

The Person's Name is Place Name, so please don't get confused.

Three Place types were selected for this test:

Birth, Residence, and Burial.

Family Tree Maker has three options for each "Fact". Date, Date and Place, and Date, Place and Description.

Family Tree Maker also has a Place Name Authority. The PNA is the 'expected' format for a Place field for any Fact. The normal format of the place name is:

City/Township, County, State, County

There is not text expected for these Jurisdiction titles. If the place name that is entered is not the way that the PNA expects it, it will offer a hint and a way to change it.

For this test, each of the above Facts were entered both ways. One the way that is expected, the other the way the user wanted.

The Birth Fact was entered as:

Bristol, Sullivan County, Tennessee





and



Bristol, Sullivan, Tennessee, USA


The Residence Fact was entered as:

1114 Windsor Avenue, Bristol, Sullivan County, Tennessee

and

Bristol, Sullivan, Tennessee, USA

In the Description field:

1114 Windsor Avenue


For the Burial Fact:

Round Hill Cemetery, Marion, Smyth County, Virginia



and




Marion, Smyth, Virginia, USA


and in the Description field


Round Hill Cemetery



The "Preferred" Fact is using the User Entered format for a Place:

another view:


The Cemetery Name and the Street Address follow, in are in a different field but using the Place Name Authority format.

From this information at GEDCOM file was generated. The important part of the GEDCOM file is:

1 BIRT
2 PLAC Bristol, Sullivan County, Tennessee
1 BURI
2 PLAC Round Hill Cemetery, Marion, Smyth County, Virginia
1 RESI
2 PLAC 1114 Windsor Avenue, Bristol, Sullivan County, Tennessee
1 BIRT
2 PLAC Bristol, Sullivan, Tennessee, USA
1 BURI Round Hill Cemetery
2 PLAC Marion, Smyth, Virginia, USA
1 RESI 1114 Windsor Avenue
2 PLAC Bristol, Sullivan, Tennessee, USA

This Test file (Test 11) was then imported into Roots Magic 4, with the following results.



The Residence Fact, in Roots Magic 4, shows up in the Place Field, but the screen calls for the Address to be in the Description field.

The Residence Fact shows up on Roots Magic 4, the say as it is displayed in Family Tree Maker.


The Burial Fact, for the entry that the User entered in Family Tree Maker shows like this. The Cemetery Name is in the Place Field. The screen clearly shows that the Cemetery belongs in the Next field.

The Cemetery did NOT show up as expected, but can be seen in the Left Side of this screen.

To help make the point, looking at the details for this individual.



The above information is from the User Entered Format. In looking into this issue, there was no way to control which of the "alternate" or multiple Facts are reports in Roots Magic 4. It appears that the first entry is what is recorded here.

Out of interest to this project, here is what the GEDCOM 5.5 indicates:

PLACE_HIERARCHY: = {Size=1:120}
This shows the jurisdictional entities that are named in a sequence from the lowest to the highest jurisdiction. The jurisdictions are separated by commas, and any jurisdiction's name that is missing is still accounted for by a comma. When a PLAC.FORM structure is included in the HEADER of a GEDCOM transmission, it implies that all place names follow this jurisdictional format and each jurisdiction is accounted for by a comma, whether the name is known or not. When the PLAC.FORM is subordinate to an event, it temporarily overrides the implications made by the PLAC.FORM structure stated in the HEADER. This usage is not common and, therefore, not encouraged. It should only be used when a system has over-structured its place-names.

PLACE_VALUE: = {Size=1:120}
[
<TEXT> |
<TEXT>, <PLACE_VALUE>
]
The jurisdictional name of the place where the event took place. Jurisdictions are separated by commas, for example, "Cove, Cache, Utah, USA." If the actual jurisdictional names of these places have been identified, they can be shown using a PLAC.FORM structure either in the HEADER or in the event structure. (See <PLACE_HIERARCHY>.)