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>.)
 

12 comments:

GeneJ said...

Russ,

Thank you for posting this information.

Believe what I'm seeing is that FTM and RM both use a place-string-within-a-template for the information TMG considers in the template that populates it's Master Place List.

In other words, the FTM template consists of
(1) a particular string of place parts, which can be related to particular (2) "lat/long" details (it's unclear to me if these details are stored in the program in order to be shared via GEDCOM), and a (3) a "Description field" (I've been jumping around the indexed items in FTM Mac book for 30 minutes and I've yet to find a good description about that field)

In RM4, there is a template, too. My quick observation is that the RM template has yet another field, "Place Details (address, hospital, cemetery, etc.)

RootsMagic appears to store phone numbers in a different field; I don't know where FTM stores phone numbers.

In the book for FTM for Mac, discussions about "places" are indexed under the heading "locations." There are lots of references--I didn't review all of them.

I did tinker with the FTM template for "Fact Properties" to note that FTM for Mac provides users three options called "Fact Elements" described as (a) Date/Place, (b) Date / Place / Description, (c) Description Only.

I further tinkered with the different entry for "place string." When I input information with a county designator (ie, input not Grafton, but Grafton County) FTM considered those to be irregular entries (in the same way my entries that include place detail, like cemetery name, are considered irregular).

At least as of October 2010, The _Register_ continues to recognize the county/parish designator in reporting place locations. Just as TMG does, the Register would seem to recognize that "element" within the recognition of a place. For example, when baptism is considered the best evidence of birth, I'd probably see the place recorded in Register with the name of the church (ala, "First Church").

See _Genealogical Writing in the 21st Century (2006), p. 20 for the discussion about presenting place information; in part, "Place and date of marriage should follow, with an indication of fist or later marriage. For example ... "Married first, at the Bozrah Congregational Church, Norwich ....."

TMG uses a template for its places. The same template is used to record place information for both events and repositories.

GeneJ said...

That 9th para in my comment is still missing a part. Should read

At least as of October 2010, The _Register_ continues to recognize the county/parish designator in reporting place locations. Just as my personal TMG output to GEDCOM does.

The Register would seems to recognize the "detail" field in the recognition of a place. For example, when baptism is considered the best evidence of birth, I'd probably see the place recorded in Register with the name of the church (ala, "First Church").

GeneJ said...

Correction

A little more tinkering in FTM for Mac.

In the "Manage Places" screen, there are three fields showing up, (1) Name, (2) Short, (3) Location [GPS...]

Russ said...

GeneJ,

You said:

"Believe what I'm seeing is that FTM and RM both use a place-string-within-a-template for the information TMG considers in the template that populates it's Master Place List."

Not sure what you are calling a Template.

Each FACT had three attributes, or in Family Tree Maker terms, Properties. Each FACT had three elements.

Date / Place
Date / Place / Description
Description Only

If that is what you are calling a 'template' OK. To me, as a simple user, they are three fields for me to fill in.

Russ

Russ said...

As a Follow up on the the Family Tree Maker "preferred" Fact. Roots Magic 4 has the SAME capability, that is a Check Mark in a field call Primary.

Russ

GeneJ said...

Ate another reply. Will comment again later.

GeneJ said...

Does preferred have a bearing on this?

TMG does have another export screen for handling "preferred" events. I usually export all where that is possible.

TMG does have a "primary" designator for tags.

GeneJ said...

P.S. Except for the names/events/place in the genealogical summary paragraph and child list, preferred facts seems antiquated to me.

If I'm generating a family group sheet, I want to report all the census, all the occupations, all the education, not just the preferred census.

I'm sure some folks use that designator in very smart ways.

Russ said...

GeneJ,

Preferred has nothing to do with the point I am trying to make and the results show.

Russ

Russ said...

GeneJ,

You PS has nothing to do with a GEDCOM. It's the User's application's output that what you are talking about.

Russ

GeneJ said...

I was only commenting on preferred because that was emphasized in your comment before my post.

My PS only pertains to the term "preferred," which, as above, I only mentioned because it was in your comment.

However, "preferred" isn't just a program term, its also one of the decisions a TMG user makes when creating a GEDCOM.

Russ said...

This same test file has been brought into Legacy 7.4. The Cemetery Name did no come into Legacy, as it did in Roots Magic 4. The City name was there, but the Cemetery Name was not. There are several options on the import about this, but none would resolve this problem.

From what I heard earlier today, Legacy will have an update later this month. The tests that have been run and reported here, will be done with Legacy.