PLAC in header or with the place itself.

[mother10]

I have a bit of a disagreement with some software, say ProgA.
Their developers state a legal GEDCOM can be without any PLAC. Not in the header, nor with a place in the file itself.

The wording in the place-structure says:

The payload contains a comma-separated list of region names, ordered from smallest to largest. The specific meaning of each element is given by the FORM (p.73) substructure, or in the HEAD. PLAC. FORM (p.73) if there is no FORM substructure. If neither FORM exists, the meaning of the elements are not defined in this specification beyond being names of jurisdictions of some kind, ordered from smallest to largest.

They say that nowhere is mentioned that it is obligatory to have a PLAC.
My other program (ProgB) gives a warning when inputting that file, saying there is no PLAC in the header,
The places in the GEDCOM of ProgA are given as:
2 PLAC Alkmaar, NH, NLD
But that is done by me, knowing jurisdictions are necessary.
Unfortunately ProgA has just 1 textfield to give the placename, and does not do anything with jurisdictions.
But knowing juridsdictions are meant to be there, I enter places in that 1 field as: Alkmaar, NH, NLD.

Now I understand in GEDCOM before Version 7, that probably was the way to go.
But we have version 7.0 now, should not a PLAC.FORM, either in the heading or with all PLAC's in the file itself, be obligatory?

Or will that problem be dealt with in Version 7.1 or 8.0?
I must admit, a program outputting GEDCOM7 but not having the necessary fields for dealing with place jurisdictions, looks very oldfashioned to me.

[Norwegian-Sardines]

As far as I’m concerned a PLAC tag is not required anywhere in the transmission!

It is completely possible in a real life small study to not know the place of any fact occurrence. Is it probably that at some point a place becomes known, sure!

[Norwegian-Sardines]

But we have version 7.0 now, should not a PLAC.FORM, either in the heading or with all PLAC's in the file itself, be obligatory?

I personally believe that PLAC.FORM should be deprecated! Too many language and location possibilities to create a reasonable FORM set!

[dthaler]

Discussion in GEDCOM Steering Committee 25 FEB 2025:

• The use of PLAC.FORM is tracked in issue Add note about empty place levels #495, including the comments about it being obsolete. Discussion on that topic can continue there.
• The question about whether PLAC is obligatory or not somewhere in the file has been answered in that the specification makes it explicitly optional in all cases. So programs should accept GEDCOM files without any PLAC tag.

[GeneoTree]

Hi everyone,

I'm sharing my observations with you.

2 PLAC 3 FORM (page 73 v7.0.8)
They are never used. I just ran a check on the 300 gedcom files in my test database: no results.
Same observation as Norwegian-Sardines, in my opinion, 3 FORM being below 2 PLAC => too many identical lines to generate, unnecessary duplication. We can safely say that this tag pair is unused.

0 HEAD 1 PLAC 2 FORM (page 34 v7.0.8)
Rarely used, only two editors in my database: Webtrees (formerly Phpgedview) and Heredis (France).
Yet, in my opinion, this is the right approach (I agree with mother10).

Importance of Place Coding
With the success of Google Maps, software programs have an interest in being able to offer geographic maps representing the places where ancestors originate. This contributes to the emotions genealogists are looking for.
Furthermore, during import, the absence of a FORM PLAC tag forces most software programs to ask users for the shape of places.
Users are unaware of this, which often leads to abandonment of their attempts and a loss of confidence in genealogy software tools.

Summary

1. FamilySearch should make the creation of the "0 HEAD 1 PLAC 2 FORM" tags obligatory, as soon as there is at least one place in the GEDCOM file, of course.
2. Communication campaigns should be launched with publishers to force them to create the "0 HEAD 1 PLAC 2 FORM" tags.
3. Poor quality of places imports is a major obstacle to the success of Gedcom files.

Best regards,
Damien Poulain
https://www.geneotree.com

[Norwegian-Sardines]

FamilySearch should make the creation of the "0 HEAD 1 PLAC 2 FORM" tags obligatory, as soon as there is at least one place in the GEDCOM file, of course.

Communication campaigns should be launched with publishers to force them to create the "0 HEAD 1 PLAC 2 FORM" tags.

I disagree completely. I have places in several countries with very different Place formats that can't be captured as a single "format" for the entire transmission. For example in Norway the modern format could be "Country, Fylke, Kommune, Town, Farm", but in past times the divisions have other name/labels. In the USA it could be "Country, State, County, Township, Town/City", but some people were born/died/lived before a place became a state (a territory) or before the town existed. Germany, France, England, China all have different formats and they may change over time. This is why the PLAC.FORM has no value anyplace in a GEDCOM.

Poor quality of places imports is a major obstacle to the success of Gedcom files.

In many cases all we have in the record is a Farm Name, a County, or City without evidence of the higher order place names, we can guess at these values but they may not be correct. The success of a GEDCOM is not based on place import but on the evidence provided in the transmission.

Places can participate in multiple higher level places, for example a town my be in multiple townships or counties in the USA.

Furthermore, during import, the absence of a FORM PLAC tag forces most software programs to ask users for the shape of places.
Users are unaware of this, which often leads to abandonment of their attempts and a loss of confidence in genealogy software tools.

I'm not sure I understand this statement! If by "shape" you mean the hierarchy labels, If a software program takes the approach of asking the data entry person for each level (designated by a label) in the place hierarchy this could be a hard approach to implement. Many times in my research I don't know all of the higher levels. The place found in the evidence may just be a town name, county name, township name, or farm name. The place hierarchy may be different today than it was at the time of the event, i.e. Different country, or other subdivision. Forcing the user to enter a Formatted Place definition may not be the right approach!

[GeneoTree]

Hello,

Place formats vary over time and across countries.
The Gedcom format can manage all scenarios: default header formats (modern, for example), and specific formats for specific locations (past times for example)
The problem is that no software generates this level of detail in Gedcom files. The FORM tag is almost always missing.

By making the "0 HEAD 1 PLAC 2 FORM" tags obligatory, we could initially force software to generate at least one location format.
This would be a significant step forward compared to today, don't you think?

[mother10]

Even in the new proposed SPLAC, a placename is described by "levels" (jurisdictions) of information that together describe the location.
In case we only know the name of the place, we put that at the right level, if we only know the state, we put that statename at tho correct level and leave out the other levels.
But the fact that the info we found is put at the level it belongs (for as far as we know it when we process that info) helps to identify the place.
But if we just mention the "name" we found, and the GEDCOM is processed by other software, that software has no way of determining if its a place or a state or a country or whatever. As the "level" of that name is missing.

So the fact that even in the new SPLAC a way to determine the "level" is still present, to me proves it is important.

And if it is possible to have places in 1 GEDCOM that have a different number of "levels", I create a HEAD.PLAC.FORM, with the max number of levels used in that GEDCOM. So all places can fit. And I choose the most likely names for the "levels".
You can always add a NOTE somewhere central, explaining, that for certain places the real name of a level might vary.

But as GeneoTree stated it gives real trouble if you have to import a GEDCOM that has no PLAC.FORM anywhere.

I know, because I have dealt with that, and many users of the most used Dutch software will. As that software knows nothing about PLAC.FORM, and users just "fill in something", unaware of the problems.

[mother10]

Also see my answer here: https://github.com/FamilySearch/GEDCOM/issues/495#issuecomment-2817212388