GEDCOM/PLAC-Tag

Name und Bedeutung

Tag

PLAC

Formelle Bezeichnung

PLACE

Deutsche Bezeichnung

Ort

Verwendung

Das Kennzeichen PLAC dient dazu, den Ort anzugeben, an dem ein Ereignis stattfand.

Formale Beschreibung zulässiger Werte

Basis dieser Beschreibung: GEDCOM Standard Draft 5.5.1

Aussagen des GEDCOM Standards

Orte werden über das Kennzeichen PLAC beschrieben. Für Orte stehen keine eigenen Datensätze wie für NOTE oder SOUR im Standard zur Verfügung. Orte werden mit folgender Struktur beschrieben:

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}

Die NOTE_STRUCTURE ist in einem eigenen Kapitel zum Kennzeichen NOTE bereits abgehandelt. Die weiteren Größen in der PLACE_STRUCTURE sind im Standard wie folgt beschreiben:

PLACE_NAME:= {Size=1:120} [ <PLACE_TEXT> | <PLACE_TEXT>, <PLACE_NAME> ] (Ortsname) Der gesetzliche Name des Ortes, an dem das Ereignis stattfand. Die Bezeichnung der Gesetzesgebiete werden durch Kommata getrennt, beispielsweise "Cove, Cache, Utah, USA". Wenn die Namen der Gebietsstrukturebenen ermittelt wurden, können diese entweder durch eine PLAC.FORM Struktur im Dateikopf (HEADER) oder innerhalb des Ereignisses notiert werden. (siehe <PLACE_HIERARCHY>)

mit PLACE_TEXT:= {Size=1:120} <TEXT> ohne Kommata.

PLACE_HIERARCHY:= {Size=1:120} (Ortshierarchie) Dies zeigt die gesetzliche Gebietsstruktur (Gemeinde, Kreis, Bundesland etc.), in einer Reihe von der niedrigsten zur höchsten Gerichtsbarkeit. Die einzelnen Gebietsebenen werden dabei durch Kommata getrennt, fehlt dabei ein Name, so wird dennoch ein Komma notiert. Wenn PLAC.FORM im Dateikopf (HEADER) der GEDCOM-Datei vorkommt, bedeutet dies, dass alle folgenden Ortsnamen dieser Struktur folgen, und das jede Strukturebene durch ein Komma berücksichtigt wird, unabhängig davon, ob diese namentlich bekannt ist. Wenn PLAC.FORM einem Ereignis untergeordnet ist, so überschreibt es die Bedeutung des PLAC.FORM im Dateikopf für diesen Datensatz. Diese Nutzung ist nicht üblich, und wird daher nicht empfohlen. Es sollte nur genutzt werden, wenn ein System eine übergeordnete Struktur seiner Ortsnamen besitzt.

PLACE_PHONETIC_VARIATION:= {Size=1:120} (Ort, phonetische Umsetzung) Die phonetische Umsetzung einer Ortsbezeichnung wird im gleichen Format geschrieben wie der übergeordnete <PLACE_NAME>, jedoch phonetisch so umgesetzt, wie das untergeordnete <PHONETIC_TYPE> beschreibt. Wenn beispielsweise Hiragana benutzt wird, um die Aussprache eines Namens in Kanji zu notieren, so wäre der <PHONETIC_TYPE>-Wert „kana“. (siehe <PHONETIC_TYPE>)

PHONETIC_TYPE:= {Size=5:30} [<Benutzerdefiniert> | hangul | kana] (phonetischer Typ) bestimmt die Methode, die bei der phonetischen Umsetzung eines Textes angewandt wurde.

<Benutzerdefiniert> Andere Methode, die zur phonetischen Umsetzung genutzt wurde
hangul phonetische Methode zur Umsetzung aus dem Koreanischen
kana Hiragana und/oder Katakana Zeichen wurden benutzt, um den Klang von japanischen Kanji-Zeichen abzubilden.

PLACE_ROMANIZED_VARIATION:= {Size=1:120} (Ort, in lateinischen Buchstaben) Der „romanisierte“ Name einer Ortsbezeichnung wird im gleichen Format geschrieben, wie der übergeordnete <PLACE_NAME>. Die Methode, die dabei Anwendung findet wird im untergeordneten <ROMANIZED_TYPE> notiert. Wenn beispielsweise Romaji genutzt wird, um eine Ortsbezeichnung in Kanji in lateinische Buchstaben umzusetzen, so wäre der Wert des dem ROMN-Kennzeichen untergeordneten <ROMANIZED_TYPE> „romaji“. (siehe <ROMANIZED_TYPE>)

ROMANIZED_TYPE:= {Size=5:30} [<user defined> | pinyin | romaji | wadegiles] (Methode der Umsetzung in lateinische Buchstaben) Zeigt an, welche Methode benutzt wurde, um einen Text in lateinische Buchstaben umzusetzen.

PLACE_LATITUDE:= {Size=5:8} (Ort, Breitengrad) Ein Wert, der den Breitengrad eines Ortes angibt. Der Breitengrad ist der Abstand in nördlicher oder südlicher Richtung vom Äquator, gemessen in Grad mit Nachkommastellen in der gewünschten Genauigkeit. Beispiel: 18 Grad, 9 Minuten und 3.4 Sekunden nördlicher Breite würde als N18.150944 formatiert werden. Minuten und Sekunden werden konvertiert, indem die Minuten durch 60 und die Sekunden durch 3600 geteilt werden, und die Ergebnisse addiert werden. Diese Summe wird dann zum Nachkommateil des Gradwertes.

PLACE_LONGITUDE:= {Size=5:8} (Ort, Längengrad) Ein Wert, der den Längengrad eines Ortes angibt. Der Längengrad ist in Grad mit Nachkommastellen östlich oder westlich des Nullmeridians (Greenwich). Beispiel: 168 Grad, 9 Minuten und 3.4 Sekunden östlicher Breite würde formatiert als E168.150944.

Entscheidungsvorschläge für Vereinbarungen zu PLAC

Die Entscheidungsvorschläge wurden aus der Diskussion in der Gedcom-L abgeleitet. Sie dienen nun der weiteren Abstimmung in dieser Liste, bevor sie per Abstimmung unter den beteiligten Progarmmautoren in Kraft gesetzt werden.

P1 Darstellungen von Ortsangaben gemäß Standard

Ortsangaben können nach GEDCOM-Standard auf folgende Weisen dargestellt werden:

n PLAC <PLACE_TEXT>

n PLAC <PLACE_NAME>

mit PLACE_NAME = [PLACE_TEXT, PLACE_NAME] und PLACE_TEXT = <TEXT> ohne Kommata.

Im zweiten Fall handelt es sich um eine durch Kommata plus folgendes Leerzeichen getrennte Aufzählung von Verwaltungsebenen, wobei die niedrigste zuerst genannt wird, die weiteren nach aufsteigenden Verwaltungsebenen folgen. Ihre Bedeutung wird im Kennzeichen FORM hinterlegt.

P2 Informationen im Kennzeichen FORM

Das Kennzeichen FORM kann an zwei Stellen in der GEDCOM-Datei eingesetzt werden, um die Informationen zu den Verwaltungsebenen für Ortsangaben zu beschreiben:

a) im Header

1 PLAC
2 FORM ebene1[, ebene2[ebene3, ...]]]

In diesem Fall gilt die Beschreibung der Verwaltungsebenen für die gesamte folgende GEDCOM-Datei, es sei denn sie wird bei einem einzelnen PLAC-Kennzeichen durch ein weiteres untergeordnetes FORM überschrieben

b) direkt einer PLAC-Zeile in einem Datensatz untergeordnet

In diesem Fall gilt die Beschreibung nur für das führende PLAC, eine evtl. im Header generell beschriebene Form wird dabei für dieses PLAC überschrieben.

Zur Vereinheitlichung der Vorgehensweise in den Programmen wird empfohlen, folgende Version für FORM einzusetzen:

n FORM place, county/district, state, country[,...[,...]]

d.h. die ersten vier Ebenen werden einheitlich verwendet. Danach könenn sich beliebig viele, programmspezifische Angaben anschließen. Die englischen Begriffe bedeuten für deutsche Verhältnisse: Ort,Kreis,Bundesland,Staat.

P3 Ergänzende Informationen zu PLAC

Dem Kennzeichen PLAC können gemäß GEDCOM Standard weitere Kennzeichen untergeordnet werden:

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}

Diese explizit im Standard festgelegten Informationen dürfen wie folgt ergänzt werden, wobei die Benutzung der hier gezeigten Nutzerdefinierten Kennzeichen empfohlen wird:

+1 _POST <POSTAL_CODE> {0:M}
+2 DATE <DATE_VALUE> {0:1}
+1 _FPOST <FOKO_POSTCODE> {0:M}
+1 _MAIDENHEAD <MAIDENHEAD_LOCATOR> {0:1}
+1 _GOV <GOV_IDENTIFIER> {0:1}
+1 _FSTAE <FOKO_TERRITORY_IDENTIFIER> {0:1}
+1 _FCTRY <FOKO_STATE_IDENTIFIER> {0:1}

P4 Ortsdatensätze

Zur Beschreibung einer umfangreichen Ortsverwaltung wird in Anlehnung an GEDCOM 5.5 EL die Verwendung von Ortsdatensätzen zugelassen:

Auf den Ortsdatensatz wird verwiesen durch folgende, unter PLAC angeordnete Zeile:

+1 _LOC @<XREF:_LOC>@

wobei für <XREF:_LOC> die Form @Pnnn@ empfohlen wird mit nnn als einer positiven, ganzen Zahl.

Der Ortsdatensatz selbst wird wie folgt strukturiert:

0 @<XREF:_LOC>@ _LOC
1 NAME <PLACE_NAME> {1:M}
2 DATE <DATE_VALUE> {0:1}
2 _NAMC <PLACE_NAME_ADDITION> {0:1}
2 ABBR <ABBREVIATION_OF_NAME> {0:M}
3 TYPE <TYPE_OF_ABBREVIATION> {0:1}
2 LANG <LANGUAGE_ID> {0:1}
2 <<SOURCE_CITATION>> {0:M}
1 TYPE <TYPE_OF_LOCATION> {0:1}
1 _FPOST <FOKO_POSTCODE> {0:M}
2 DATE <DATE_VALUE> {0:1}
1 POST <POSTAL_CODE> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}
1 _GOV <GOV_IDENTIFIER> {0:1}
1 _FPOST <FOKO_POST_CODE> {0:1}
1 _FSTAE <FOKO_TERRITORY_IDENTIFIER> {0:1}
1 _FCTRY <FOKO_STATE_IDENTIFIER> {0:1}
1 MAP {0:1}
2 LATI <PLACE_LATITUDE> {1:1}
2 LONG <PLACE_LONGITUDE> {1:1}
1 _MAIDENHEAD <MAIDENHEAD_LOCATOR> {0:1}
1 EVEN <EVENT_DETAIL> {0:M}
1 _LOC @<XREF:_LOC>@ 0:M
2 TYPE <HIERARCHICAL_RELATIONSHIP> {1:1}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}
1 _DMGD <DEMOGRAPHICAL_DATA> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 SOUR <SOURCE_CITATION> {0:M}
2 TYPE <TYPE_OF_DEMOGRAPICAL_DATA> 1:1
1 _AIDN <ADMINISTRATIVE_IDENTIFIER> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}
2 TYPE <TYPE_OF_ADMINISTRATIVE_IDENTIFIER> {1:1}
1 <<MULTIMEDIA_LINK>> {0:M}
1 <<NOTE_STRUCTURE>> {0:M}
1 <<SOURCE_CITATION>> {0:M}
1 <<CHANGE_DATE>> {0:1}

P5 geografische Koordinaten

Den Vorgaben des GEDCOM-Standards wird gefolgt:

PLACE_LATITUDE muss dargestellt werden als [Ngg.nnnnnn|Sgg.nnnnnn],

PLACE_LONGITUDE muss dargestellt werden als [Wgg.nnnnnn|Egg.nnnnnn],

wobei vor dem Punkt die Stellen gg den Grad darstellen (ein bis drei Ziffern), nach dem Punkt werden zunächst die Minuten geteilt durch 60 plus die Sekunden geteilt durch 3600 dargestellt.

Beispiel:

3 MAP
4 LATI N50.05000
4 LONG E8.88333

P6 Vorrang des Exportes mit explizit im Standard definierten Strukturen

Vorrang vor dem nutzerdefinierten Ortsdatensatz nach P4 haben die nach GEDCOM-Standard explizit definierten Kennzeichen unter PLAC sowie die Darstellung der durch FORM definierten übergeordneten Einheiten. Soweit die Datenfelder im Programm vorhanden sind, müssen diese Kennzeichen im Standard-Export des Programmes direkt unter PLAC mit exportiert werden. Zusätzlich wird empfohlen, soweit im Programm als Datenfeld vorhanden auch die GOV-Kennzahl mit unter PLAC zu stellen, um empfangenden Programmen ohne Ortsdatensatz-Import diese Identifikationsgröße übergeben zu können. Damit sieht der Aufruf eines Ortes mit Ortsdatensatz wie folgt aus:

n PLAC Ortsname, Kreisname, Landname, Staatsname
n+1 FORM <PLACE_HIERARCHY> {0:1}
n+1 FONE <PLACE_PHONETIC_VARIATION> {0:M}
n+2 TYPE <PHONETIC_TYPE> {1:1}
n+1 ROMN <PLACE_ROMANIZED_VARIATION> {0:M}
n+2 TYPE <ROMANIZED_TYPE> {1:1}
n+1 MAP {0:1}
n+2 LATI <PLACE_LATITUDE> {1:1}
n+2 LONG <PLACE_LONGITUDE> {1:1}
n+1 <<NOTE_STRUCTURE>> {0:M}
n+1 _GOV <GOV_IDENTIFIER> {0:1}
n+1 _LOC @<XREF:_LOC>@

Soweit FORM bereits im Header der Datei (gemäß P2) definiert ist, entfällt die Zeile mit dem Kennzeichen FORM unter PLAC. Da diese Aufrufe bei vielfachem Vorkommen des Ortes entsprechend häufig auftreten, wird für die <<NOTE_STRUCTURE>> der Einsatz von NOTE-Datensätzen empfohlen.

Es ist zulässig, in einem optionalen Export abweichend von der Vorgabe für den Standard-Export auf die Ausgabe der Informationen bei jedem Aufruf von PLAC zu verzichten, oder diesen Export nur beim ersten Auftreten des Ortes vorzunehmen. Der Anwender ist bei Anwahl dieser Option geeignet darauf hinzuwiesen, dass diese Einstellung zu verstärkten Informationsverlusten in empfangenden Programmen führt, die nicht mit Ortsdatensätzen operieren.

Behandlung/Darstellung schwieriger Situationen

Erweiterung GEDCOM 5.5. EL

Der GEDCOM-Standard 5.5 wurde gemeinsam von 6 Programmautoren mit Compgen um eine detailliertere Beschreibung von Orten erweitert. Hierzu wurde ein nutzer-definierter Datensatz _LOC eingeführt mit folgender Unterstruktur:

0 @P65@ _LOC
1 NAME <PLACE_NAME> 1:M
2 DATE <DATE_VALUE> 0:1
2 SOUR <SOURCE_CITATION>
2 NAMC <PLACE_NAME_ADDITION> 0:1
2 _LANG <LANGUAGE> 0:1
1 _FPOST <FOKO_POSTCODE> 0:M 
2 DATE <DATE_VALUE> 0:1
1 POST <POSTCODE> 0:M
2 DATE <DATE_VALUE> 0:1
2 SOUR <SOURCE_CITATION> 0:M
1 _FSTAE <FOKO_TERRITORY_IDENTIFIER> 0:1
1 _FCTRY <FOKO_STATE_IDENTIFIER> 0:1
1 _FOKOID <FOKO_IDENTIFIER> 0:1
1 MAP <GEOGRAPHICAL_COORDINATES> 0:M
2 TYPE <GEOGRAPHICAL_COORDINATE_TYPE> 1:1
1 EVEN <EVENT_DETAIL> 0:M
1 _LOC @<XREF:_LOC>@ 0:M
2 TYPE <HIERARCHICAL_RELATIONSHIP> 1:1
2 DATE <DATE_VALUE> 0:1
2 SOUR <SOURCE_CITATION> 0:M
1 _DMGD <DEMOGRAPHICAL_DATA> 0:M
2 DATE <DATE_VALUE> 0:1
2 SOUR <SOURCE_CITATION> 0:M
2 TYPE <TYPE_OF_DEMOGRAPICAL_DATA> 1:1
1 _AIDN <ADMINISTRATIVE_IDENTIFIER> 0:M
2 DATE <DATE_VALUE> 0:1
2 <SOURCE_CITATION> 0:M
2 TYPE <TYPE_OF_ADMINISTRATIVE_IDENTIFIER> 1:1
1 <<MULTIMEDIA_LINK>> 0:M

Diese Vorgehensweise erlaubt sowohl eine hierarchische Darstellung von Orts- bzw. Gebietsbezeichnungen sowie eine umfangreiche Dokumentation des jeweiligen Gebietsteiles. Über den Datensatz erfolgt dies jeweils an einer Stelle innerhalb der GEDCOM-Datei und braucht nicht bei jedem Aufruf eines Ortes wiederholt zu werden.

Nachteil ist aufgrund der bisher recht geringen Verbreitung der Vorgehensweise, dass die Informationen bei sehr vielen Datentransfers zwischen Programmen verloren gehen.

Diskussionsstand in der Arbeitsgruppe der Programmautoren

3 Arten für den Export von PLAC

Die Autoren haben im Rahmen der Diskussion zu PLAC festgestellt, dass es drei verschiedene Stufen gibt, in welcher Tiefe Informationen zu PLAC nach GEDCOM exportiert werden:

I:

PLAC klartext

(keine weitere Struktur)

II:

PLAC strukturierter Text

FORM (gibt die Struktur an, normalerweise pauschal im Header erledigt)

III:

PLAC strukturierter Text

FORM (gibt die Struktur an, normalerweise pauschal im Header erledigt)

_LOC @Pnn@

mit Datensatz @Pnn@.

In allen drei Varianten können die Kennzeichen, die laut GEDCOM-Standard 5.5.1 unter PLAC stehen, eingebracht werden. Variante III ist eine Erweiterung des GEDCOM-Standards mit nutzerdefinierten Kennzeichen, oft den Vereinbarungen der GEDCOM 5.5 EL folgend.

Variante III wird hier mit betrachtet, weil der Standard für eine umfangreiche Ortsverwaltung nicht ausreichend Möglichkeiten bietet.

Format geografischer Koordinaten

In der Liste wurde kontrovers diskutiert, in welchem Format die geografischen Koordinaten nach GEDCOM exportiert werden sollen:

Variante A:

3 MAP
4 LATI N50.05000
4 LONG E8.88333

Variante B:

3 MAP
4 LATI 50.05000
4 LONG 8.88333

Variante C:

1 MAP 50.05000N 8.88333E
2 TYPE DEGREE

Der GEDCOM-Standard schreibt die Struktur der Kennzeichen explizit vor, und zwar in der Form der Variante A bzw Variante B. Variante C ( wie in GEDCOM 5.5. EL innerhalb eines Ortsdatensatzes definiert ) verstößt explizit gegen die Vorgaben des Standards und wurde daher nicht mehr weiterbetrachtet. Variante A ist weit verbreitet, lesbar und auch eindeutig zu identifizieren bei südlicher Halbkugel und westlichen Breitengraden (dann mit S statt N bzw. mit W statt E). Variante B hat Vorteile bei Rechenoperationen. S und W werden hier dargestellt als negative Zahlen. Damit ist der Inhalt zu LATI bzw LONG direkt in Rechenformeln einsetzbar.

Es wurde klargestellt, dass die Diskussion nichts zu tun hat mit der Darstellung der Längen- und Breitengrade auf der Benutzeroberfläche eines Programmes. Deren Gestaltung ist Sache des jeweiligen Programmautors. Eine Vereinbarung über das Format in GEDCOM sagt daher nichts über das in der Benutzeroberfläche verwendete Format.

Folgende Bewertungskriterien wurden für die Diskussion der Varianten A und B herangezogen: Aussagen im GEDCOM-Standard, Lesbarkeit für Nutzer, Datenaustausch mit anderen Programmen (nicht über GEDCOM), Datenaustausch mit Genealogie-Programmen (Drittprogrammen).

Da es hier um den Datenaustausch zwischen Genealogie-Programmen geht und eine Umformung zwischen den Varianten A und B sehr einfach zu erledigen ist, sind die Kriterien Lesbarkeit und Austausch mit anderen Programmen über andere Wege als GEDCOM-Dateien hier von untergeordneter Bedeutung.

Der GEDCOM-Standard selbst verwendet Variante A bei seinen Beispielen, schreibt diese aber im Text bzw Regeln nicht explizit vor.

Eine Entscheidung unter den Programmautoren ist noch nicht gefallen.

PLAC.FORM im Header der Datei

In der Diskussion der Liste wurde vorgeschlagen, beim Export in den ersten vier Ebenen der Orts/Gebietsstruktur bei Verwendung von FORM einheitlich die Gliederung:

Ort, Kreis, Land, Staat

zu verwenden, und dies im Header der Datei in englischer Sprache darzustellen:

0 HEAD
...
1 PLAC
2 FORM place, county, state, country

Es soll freigestellt werden, danach noch weitere Unterteilungen (mit Kommata jeweils getrennt) zu verwenden. Es wird empfohlen, diese dann ebenfalls im Header unter FORM zu definieren.

PLAC und FORM in den Datensätzen

Der GEDCOM-Standard läßt auch zu, dass bei einem einzelnen PLAC Aufruf innerhalb eines Datensatzes durch ein unter PLAC angeordnetes FORM die Information gegeben wird, wie die einzelnen, durch Kommata getrennten Teile von PLAC zu interpretieren sind.

Also wäre folgendes eine Standard-konforme Ausgabe:

0 INDI
...
1 BIRT
2 PLAC Cremlingen,Niedersachsen,Deutschland
3 FORM place,state,country

Weiter legt der Standard fest, dass die direkt dem PLAC-Kennzeichen untergeordnete Beschreibung in FORM für dieses Vorkommen von PLAC eine ggfs. im Header vorhandene allgemeine Beschreibung im dortigen FORM überschreibt, d.h. die Definition im Header gilt nur für solche Aufrufe von PLAC, unter die kein gesondertes Kennzeichen FORM unterstellt ist.

Anmerkungen zu GEDCOM 5.5. EL

Mit GEDCOM 5.5. EL wurde ein erster Anlauf gemacht, detaillierte und strukturierte Informationen zu Orten und deren Zuordnungen zu übergeordneten Verwaltungsstrukturen in GEDCOM darstellen zu können. Es besteht in der Gedcom-L weitgehende Einigkeit, für die strukturierte GEDCOM-Ausgabe solcher Ortsinformationen Ortsdatensätze einzuführen und sich dabei möglichst weitgehend an GEDCOM 5.5 EL anzulehnen, bei Abweichungen vom GEDCOM Standard 5.5.1 aber dem 5.5.1 Priorität einzuräumen.

Daher sind folgende Punkte diskutiert worden:

MAP: Die Verwendung von MAP muss den Vorgaben von 5.5.1 angepasst werden.

_FOKOID: Der Name FOKOID wird nicht mehr verwendet, er wurde durch GOV-Kennung ersetzt. Daher sollte _FOKOID in _GOV umbenannt werden

In GEDCOM 5.5 EL fehlt die Möglichkeit, neben den verschiedenen Namen auch Abkürzungen darzustellen

Ein Bespiel mit einer Darstellung als Ortsdatensatz (Entwurf)

Als Beispiel wird hier Weiskirchen, heute Ortsteil von Rodgau bei Offenbach/Main dargestellt.

Zunächst die Informationen aus GOV:

   WEIHEN_W6051
   gehört zu RODGAUJO40KA,
   hat ab 1993-07-01 PLZ 63110,
   hat bis 1993-06-30 PLZ W6051,
   heißt  (auf deu) Weiskirchen,
   ist (auf deu) Ort;

Das ist eine Beschreibung aus der "alten" GOV Zeit, ohne Koordinaten, mit 4-stelliger Postleitzahl. Die Koordinaten und der Locator sind also noch hinzuzufügen.

Für Rodgau liefert GOV:

   RODGAUJO40KA
   gehört zu adm_136438,
   hat ab 1993-07-01 PLZ 63110,
   hat bis 1993-06-30 PLZ W6054,
   hat externe Kennung  opengeodb:23189,
   heißt  (auf deu) Rodgau,
   ist (auf deu) Stadt (Siedlung),
   liegt bei 50.03°N 8.88°O;

Rodgau gehört zu Offenbach, und Offenbach zu Darmstadt (seit 1945) bzw zu Starkenburg (vor 1937), Details siehe GOV.

Damit sieht das Beispiel im Entwurf eines Ortsdatensatzes in GEDCOM in 2 Ebenen ( Ortsteil und Staft ) so aus:

0 @P1@ _LOC
1 NAME Weiskirchen
1 TYPE Ortsteil
1 POST 63110
2 DATE FROM 01 JUL 1993
1 POST W6051
2 DATE TO 30 JUN 1993
1 _GOV WEIHEN_W6051
1 MAP
2 LATI N50.050000
2 LONG E8.883333
1 _MAIDENHEAD JO40KB
1 _LOC @P2@
2 _TYPE Ort in Stadt
...
0 @P2@ _LOC
1 NAME Rodgau
1 TYPE Stadt
1 POST 63110
2 DATE FROM 01 JUL 1993
1 POST W6054
2 DATE TO 30 JUN 1993
1 _GOV RODGAUJO40KA
... usw

Bei der Postleitzahl POST ist schon mal die in GEDCOM 5.5. EL vorgesehene Möglichkeit genutzt, "alt" und "neu" durch das Datum genauer zu spezifizieren. Das geht mit vielen anderen Eigenschaften auch, insbesondere auch mit der verwaltungsmäßigen Zuordnung. Daher wurden auf der Ebene des Datensatzes für einen Ortsteil bewusst _FSTAE ( Hessen ) und _FCTRY ( Deutschland ) nicht verwendet, weil das über die Zuordnungskette mit _LOC @P2@ und weiteren übergeordneten Ebenen "automatisch" zu Hessen und Deutschland zugeordnet wird - mit dem großen Vorteil, dass frühere Zuordnungen vor der Zeit des Staates Deutschland ebenfalls richtig im System abgebildet sind, wenn die Aufrufe 1 _LOC @Pnnn@ mit einem 2 DATE <DATE_VALUE> richtig mit Zeiträumen jeweils belegt werden.

Abweichungen vom Standard bei der Verwendung

derzeit nicht belegt

en:GEDCOM/PLAC-Tag