The Place Record in GEDCOM - Sat, 24 Dec 2011

Well, um, there is no Place record. But there should be.

Currently in GEDCOM, you normally specify the place where something happened with a PLAC tag that is subordinate to an event, e.g.:

1 BIRT
2 DATE 24 DEC 2011
3 PLAC Winnipeg, Manitoba, Canada

These events in GEDCOM are attached to individuals or families/couples.

So you may have a thousand references to the one place: Winnipeg, Manitoba, Canada. Behold will group these together in the Place Details section of its Everything Report and show you all the events pertaining to each place, with hyperlinks back to the individuals.

But what if you have information about the place itself? You may want to store events or notes pertaining to the place and may be of use to you in your research. e.g. That place may have had a battle in a war, it could have changed its name, or maybe there was a big fire on Main street that affected the town and the townsfolk. How about a simple history of the town? All these are important in your genealogy research as they would have affected the life of your relatives and could be important clues to determine why certain events in their life happened.

GEDCOM 5.5 allowed only a few items under the PLAC tag:

PLACE_STRUCTURE:=
n PLAC <PLACE_VALUE> {1:1}
+1 FORM <PLACE_HIERARCHY> {0:1}
+1 <<SOURCE_CITATION>> {0:M}
+1 <<NOTE_STRUCTURE>> {0:M}

GEDCOM 5.5.1 noted that more information about places was needed to be recorded. They changed the structure to this:

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

They removed the Source Citation, implying they now want the source attached to the event above the place rather than the place itself, but that is not of relevance in this discussion.

The key problem is that the information above pertains to the place, and not to the event. If I’ve got 1,000 references to Winnipeg, Manitoba, Canada as a place, then in GEDCOM, is this information put on one of them, or on all of them, or can I put different information on different occurrences? This is unclear and is subject to the way various programs process their GEDCOM input and output.

To me this is a real problem with GEDCOM and needs to be fixed in a BetterGEDCOM and any other improvements to the standard. Fortunately, I have not observed cases of programs exporting their place information subordinate to the PLAC tag. And I don’t know if there are any programs that would process this subordinate place information if it was there.

To me, the logical place this information should be is in a Place Record. It could be defined like this:

0 PLAC Winnipeg, Manitoba, Canada
1 MAP
2 LAT N49.9
2 LONG W97.1
1 NOTE … information about the place …
1 EVEN
2 TYPE Main Street Fire
2 DATE 11 OCT 1904
2 NOTE … information about the fire event …
2 SOUR @S44@

I would even want to allow Events in the Place Record and source references, as shown above. Behold would display this information in the Place Details section, and then follow it with all the events that reference the place. You would have all your place information conveniently together.

There are already several programs that export PLAC records similar to the above into their GEDCOMs. This is both good and bad. It is good because these programs allow you to add your information about your places. It can then export it and import it again. But it is bad because these programs make you feel that all is okay and other programs will be able to read this information as well.

RootsMagic creates a Place record using a custom _PLAC tag, but uses it almost trivially, usually just for the latitude and longitude, e.g.:

0 _PLAC 254 Elm St; Montpelier, Vt
1 MAP
2 LATI N44.2600000
2 LONG W72.5758300

I have seen some NOTEs under the _PLAC in RootsMagic GEDCOMs.

Legacy also exports its place information, but in yet a different way using a _PLAC_DEFN tag, e.g.:

0 _PLAC_DEFN
1 PLAC Bishopsgate, London, England
2 ABBR Bishopsgate, London, England

The idea’s there, but you have to use the subordinate PLAC line to figure out what the place is (that’s actually tough on programmers) and the information they export is pretty useless, if you ask me: an abbreviation that’s almost always the same as the place itself.

The biggest problem with RootsMagic and Legacy exporting these things for me is that if I want to have Behold display their data correctly, then I have to spend my time trying to support their custom structures and work it into Behold’s Everything Report. Once they (and other programs) add these non-standard structures, then data transfer between programs fails – not GEDCOMs fault, but the programmers fault. I’ve posted about this before.

The bottom line here is that I think a PLAC record is necessary. I am going to implement it in Behold Version 2.0 when I add editing. It will allow your information about places to be documented, allow you to include sources and will make your information usable and available to help you do your research. But, I’m afraid unless something becomes available soon, I’m going to have to use a custom PLAC record to store this information into GEDCOM. That means this information will not transfer to other programs, unless they custom code this PLAC record the way I have had to do for the RootsMagic and Legacy records.

It’s a real problem. Hopefully this post will trigger some ideas and will lead to a best solution that will work for Behold.

- - -

Followup: 25 Dec 2011. Tamura Jones in a tweet correctly pointed out that GEDCOM 5.5 EL created a _LOC structure for a number of genealogy programs that needed it. Dave Knight added that it was done right using an xref rather than having to match up on the place name.

I remember seeing this years ago. I only have one GEDCOM 5.5EL file among my 676 test files on my machine named pcahnen2004.ged which seems to be an example file built, that is indented for illustration. It seems the file identifies itself with an _EXTENDED_LOCATIONS tag following the GEDC VERS 5.5 tags in the header of the GEDCOM. Looking around, I was only able to find one other file with that format.

Currently, Behold’s “extended record” handling properly displays the _LOC records of those files in a “LOC Details” section, e.g.:

LOC1 Böblingen
   LOC ID is: P1
   Postal code: 71032
   FSTAE: BW
   FOKOID: BOBGENJN48MQ
   MAIDENHEAD: JN48MQ
   Birth: 01 APR 1870 in Böblingen –> Hans Georg Mustermann MUS-2
   Christening: 03 APR 1870 in Böblingen –> Hans Georg Mustermann MUS-2
   CIVIL: 01 APR 1900 in Böblingen –> Hans Georg Mustermann and Klara Elisabeth [Musterfrau] Mustermann MUS-2
   RELI: 03 APR 1900 in Böblingen –> Hans Georg Mustermann and Klara Elisabeth [Musterfrau] Mustermann MUS-2
   Residence: Hans Georg Mustermann MUS-2

In order to integrate it with the Place Details section of Behold, I would have to custom handle it like I do the RootsMagic _PLAC tag or the Legacy _PLAC_DEFN tag. But, as I tweeted back to Tamura and Dave, this is yet another variant of GEDCOM that Behold is going to have to support.

If I can figure a way to do it without that much work, I’ll squeeze full support GEDCOM 5.5EL into Version 1.0.x.