* Number of Place elements in GEDCOM?

[BEJ]

I recently read in a 1999 publication that GEDCOM 5.5 accommodates a maximum of four (4) levels for Place. Is this true?

I’m concerned because I utilize seven (7) Place elements, separated by commas, in my FH7 database and would not want critical information lost in an export to GEDCOM.

I’ve searched FHUG for “place” and did not find anything about the max number of place elements, so thanks to anyone who may be able to provide insight on whether I should revamp my place entry procedures. It would be a chore, but preferred to creating a useless data export.

[AdrianBruce]

I recently read in a 1999 publication that GEDCOM 5.5 accommodates a maximum of four (4) levels for Place. Is this true?
...

No. I can't find anything in the GEDCOM 5.5 Standard that puts a limit on the number of elements in a placename (i.e. the number of comma separated bits).

I appear to have one place-name of 6 elements, namely "Ruhleben, , Potsdam Reg-Bez, Brandenburg, Prussia, Germany" (a WW1 internment camp). (Note the empty 2nd element). I also have 15 5-element place-names.

If you go to Tools / Work with places / Places... there is a facility there to define the number of columns (elements) displayed - the Columns button gives a screen that says "max 10".

Many people will be very pedantic with their column layout, aiming to get the same number of columns across all countries, putting in leading commas to ensure that the country is in the same column everywhere, etc. For once, my middle name is pragmatism and I do none of that.... (I do have empty middle columns as per the 2nd element of Ruhleben above, to gain alignment).

[tatewise]

BEJ:
GEDCOM 5.5 was published in 1995, GEDCOM 5.5.1 Draft was published in 1999 and GEDCOM 5.5.1 was fully published in 2019.
I agree with all that Adrian has said. FH v7 is based on GEDCOM 5.5.1 2019.

It would be useful to know what publication you read so we can entirely put your mind at rest.

All three GEDCOM specifications define the Place Name identically:

PLACE_NAME:= [
<PLACE_TEXT> |
<PLACE_TEXT>, <PLACE_NAME>
]
The jurisdictional name of the place where the event took place. Jurisdictions are separated by
commas, for example, "Cove, Cache, Utah, USA."

i.e.
It can consist of PLACE_TEXT which is any text without commas optionally followed by a comma and a PLACE_NAME, which is recursively defined as PLACE_TEXT followed by a comma and PLACE_NAME ad infinitum.
Maybe the example with four place parts has been misinterpreted as being definitive.

[BEJ]

Title: GEDCOM Data Transfer: Moving Your Family Tree
Author: Hawgood, David

Thank you. I like the way I am entering place and I’m glad not to change my system, as I conclude from your responses.

[tatewise]

That seems to be a book that we cannot refer to without buying it.
What exactly did he say?

[BEJ]

I am traveling for the holidays and will have to respond with the details in a few weeks.

Warm winter greetings and wishes for a safe 2022 to see you all!

[Mark1834]

Frustratingly, I had a copy of that book (a small paperback of the type popular for FH topics in the 1980s) until earlier this year, but it didn't survive my last clear out...

[brianlummis]

Amazingly in my bookcase I have a copy of the David Hawgood book!

There is a section 6. Special Types of Information: Place, Name, Date etc with Sub-section 6.1 Places. The only reference that I can see is in the 3rd paragraph which starts "In PAF 2.2 a place can have up to 4 levels" and there are further references to PAF and the third and fourth level. I can't see any reference to GEDCOM being limited in the same way.

[BEJ]

Thank you! I must have conflated PAF and GEDCOM.

But isn't PAF part of GECOM---well, guess that's a discussion for another time.

As always, thanks to you all for the responses.

[tatewise]

Thank you, Brian.
So that limit of 4 in PAF is rather like the limit of 10 in FH.
Although in FH, you can have more than 10, but they just won't display so neatly in Tools > Work with Data > Places.
GEDCOM has no limit at all.

BEJ: PAF is a commercial product just like FH and RootsMagic and Legacy, etc...
The connection you may be thinking of is that FamilySearch (Latter Day Saints) are the author of both PAF and GEDCOM.

[BEJ]

All clear! Out.

[AdrianBruce]

... The connection you may be thinking of is that FamilySearch (Latter Day Saints) are the author of both PAF and GEDCOM.

If I recall correctly, various commentators have alleged that ironically PAF was seldom up to speed with the latest version of GEDCOM - one of the reasons that I dropped PAF for FH was that PAF only had one of the date range constructions whereas GEDCOM has two - FROM/TO and BTW/AND - just don't ask me which one PAF did.

[tatewise]

Adrian, you are probably correct, but peversley PAF started using GEDCOM Draft 5.5.1 even though it stated it must not be used in programs!

[KFN]

PAF had a lot of trouble with following GEDCOM.

The most recent versions of PAF (version 4.0 and above) were not authored by LDS but by Ancestral Quest.

Many software programs had data entry fields for specific levels of “place” rather than one free-form field.

PAF never supported multiple NAME tags. Using _AKA and _MARNM tags.