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.

Vereinbarungen zu PLAC

Die folgenden Vereinbarungen wurden aus der Diskussion in der Gedcom-L abgeleitet und durch Abstimmung unter den an der Diskussion beteiligten Programmautoren der Gedcom-L verabschiedet. Der hier dokumentierte Stand berücksichtigt die im August 2013 vereinbarten Änderungen und Ergänzungen zu P4 sowie die neu eingefügten P7 und P8.

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 (denen jeweils ein Leerzeichen folgen kann) 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 _MAIDENHEAD <MAIDENHEAD_LOCATOR> {0:1}
+1 _GOV <GOV_IDENTIFIER> {0:1}

P4 Ortsdatensätze

Diese Vereinbarung wurde in den neu aufgemachten Artikel zum _LOC-Tag verschoben: L1 Ortsdatensätze

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.

P7 Formalisierung: Aufnahme LOCATION_RECORD in die Definition von RECORD

Diese Vereinbarung wurde in den neu aufgemachten Artikel zum _LOC-Tag verschoben: L1 Formalisierung: Aufnahme LOCATION_RECORD in die Definition von RECORD

P8 Bürgerort

Für den in der Schweiz wichtigen "Bürgerort" wird zum Export folgende Variante empfohlen:

1 EVEN
2 TYPE Bürgerort
2 PLAC <Anwendereingabe für Bürgerort>

Die Anwendereingabe zum Bürgerort (z.B. Gemeindename plus zweistellige Abkürzung des Kantons aus den offiziellen Dokumenten) wird nicht verändert. Weitere im Standard für EVEN definierte Unter-Kennzeichen dürfen mit exportiert werden, z.B. DATE, SOUR usw.

Beim Import sollten bereits vorkommende, anders aufgebaute Versionen ebenfalls unterstützt werden, sie dürfen in die für den Export vorgeschlagene Version überführt werden:

1 _BUERGERORT <Anwendereingabe für Bürgerort>

oder

1 _HEIM <Anwendereingabe für Bürgerort>

oder

1 FACT
2 TYPE Bürgerort
2 PLAC <Anwendereingabe für Bürgerort>

Entscheidungsvorschläge zu PLAC / _LOC (3. Runde 2019)

Hinweis: Der Entscheidungsvorschlag zu Detailangaben zum Ortsdatensatz wurde in den Artikel zum GEDCOM/_LOC-Tag verschoben.

Änderungsumfang zu PLAC P4 vom August 2013

Es wurden folgende Änderungen an der ursprünglichen Version von P4 vereinbart. Die Änderungen sind in P4 eingearbeitet, die Darstellung hier dient nur der Nachvollziehbarkeit der Änderungen.

P4korr Ergänzungen und Korrekturen zu P4

An der in Runde 1 verabschiedeten Vereinbarung P4 werden folgende Änderungen vorgenommen:

Der Ortsdatensatz erhält die Bezeichnung LOCATION_RECORD, damit wird der Definition in P4 vorangestellt: LOCATION_RECORD :=

Entfernen der Doppelnennung _FPOST:

1 _FPOST <FOKO_POSTCODE> {0:1}

stand neben

1 _FPOST <FOKO_POSTCODE> {0:M}

im Umfang des Ortsdatensatzes. Die erste Nennung soll gelöscht werden (ist in der Doku zu P4 bereits umgesetzt!).

Korrektur Quellenaufruf unter _DMGD:

1 _DMGD <DEMOGRAPHICAL_DATA> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}
2 TYPE <TYPE_OF_DEMOGRAPICAL_DATA> 1:1

Korrektur EVEN:

1 EVEN [<EVENT_DESCRIPTOR>|<NULL>] {0:M}
2 <<EVENT_DETAIL>> {0:1}

Postleitzahl als Nutzerdefiniertes Kennzeichen (statt POST):

1 _POST <POSTAL_CODE> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}

Ergänzung untergeordneter Kennzeichen zu 1 TYPE sowie Zulassen mehrerer Vorkommen {1:M}:

1 TYPE <TYPE_OF_LOCATION> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}

Verwendung des TYPE unterhalb des datensatzinternen _LOC mit folgenden Ausprägungen: [POLI|RELI|GEOG|CULT] um damit politische (verwaltungsmäßige), kirchliche, geografische oder kulturelle Zuordnungen zu differenzieren. Näheres zum TYPE des zitierten übergeordneten Objektes regelt dann die 1 TYPE im aufgerufenen Datensatz.

Behandlung/Darstellung schwieriger Situationen

Diskussionsstand in der Arbeitsgruppe der Programmautoren (Runde 3, 2019)

Bei der Umsetzung der Ortsdatensätze in Programmen aus der Gedcom-L, aber auch weiterer Programme, kommen Fragen zu Konkretisierungen unserer Vereinbarung P4 hoch. Insbesondere die nähere Beschreibung der dort verwendeten Elemente wird nachgefragt.

Aus Runde 2 sind weitere Themen offen, da sie nicht bis zu einer Entscheidung diskutiert wurden. Diese Punkte sind jetzt hier aus dem Umfang der Runde 2 in den Umfang der Runde 3 verschoben worden.

Übersicht Themen in Runde 3

Themen in Bearbeitung:

Konkretisierungen zur Vereinbarung P4 Ortsdatensätze
Vereinheitlichung der FORM (aus Vereinbarung P1) versus Reihenfolge nach Hierarchie-Ebenen
Transfer in Programme ohne hierarchische Ortsdatensätze
Nutzerdefinierte Ortsnamen versus Strukturvorgabe in P6 (Vorschlag: PLAC._NAMR)
Verweise auf andere Ortsdatenbanken als GOV
Ergänzungen und Korrekturen an der Musterdatei

Konkretisierungen zur Vereinbarung P4 Ortsdatensätze

Dieses Thema ist im Kapitel zu Ortsdatensätzen GEDCOM/_LOC-Tag aufgegangen.

Vereinheitlichung der FORM (aus Vereinbarung P1) versus Reihenfolge nach Hierarchie-Ebenen

In P1 wurde die Empfehlung ausgesprochen, FORM immer wie folgt starten zu lassen:

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

und weitere Informationen ab Stelle 5 einzubringen. Dies kollidiert mit der Aussage im Standard, dass die Ebenen immer von der niedrigsten bis zur höchsten Ebene sortiert sein sollen. Wenn jetzt also z.B. Ortsteile oder Bezirke aufgenommen werden sollen, müßten diese nach dem Ebenenprinzip in die ersten Ebenen eingegliedert werden. Nach Vereinbarung P1 wurde eingebracht, vielleicht doch der Sortierung nach Ebenen Vorrang zu geben. Problem wird es, wenn dann weitere Informationen, wie z.B. die Postleitzahl, aufgenommen wird. Diese Information paßt nicht in eine hierarchische Reihenfolge und wird in der Praxis bislang eher am Ende der FORM-Elemente eingestellt.

Transfer in/aus Programmen ohne hierarchische Ortsdatensätze

Wird von einem Programm, welches selber keine hierarchisch aufgebauten Ortsdatensätze (also solche, in denen mit _LOC aus dem Ortsdatensatz auf die nächsthöhere Ebene in getrenntem Ortsdatensatz verwiesen wird) unterstützt, eine Datei mit solchen hierarchisch strukturierten Ortsdatensätzen importiert, so stehen einige Fragen zur Klärung an:

Import zu variablen, insbesondere historischen Ortstypen wie Pfarrdorf, Amt, Provinz, Herzogtum, Königreich
Verlust der zeitabhängig definierten Verwaltungszuordnungen
Umgang mit Ortsdatensätzen, die ausschließlich aus anderen Ortsdatensätzen aufgerufen werden
Parallele Darstellung aller (bzw der konkreten Ebenen Kreis, Land, Staat) Hierarchieebenen oberhalb eines Ortes im Ortsdatensatz
Einsatz eines zusätzlichen Nutzerdefinierten Kennzeichens _FB_ADM, um die Namen der der Hierarchie-Objekte im Ortsdatensatz aufzunehmen, alternativ die Hierarchie mit NAME und NAME.FORM exportieren, weitere Alternative: Auch Klartext unter _LOC eingeben (direkt den Namen der übergeordneten Objektes)

Nutzerdefinierte Ortsnamen versus Strukturvorgabe in P6

Über P6 wird auch bei Verwendung von Ortsdatensätzen vorgeschrieben, die Verwaltungsstruktur zu einem Ort in der mit Kommata getrennten Form zu exportieren und diese Struktur über FORM zu definieren. Damit aber steht unter PLAC nicht mehr der Ortsname, wie ihn der Anwender eingegeben hat. Diskutiert wird, wie der Vorrang der Eingabe des Anwenders sichergestellt werden kann. Derzeitig werden folgende Ersatzlösungen verwendet:

Option, den Ortsnamen in Berichten / Masken ab dem ersten Komma abzuschneiden (Nachteil: Eindeutigkeit geht oft verloren, oder der Anwender muss vor dem Komma bereits so viel Information plazieren, dass der Ort auch bei abgeschnittenen Verwaltungsebenen eindeutig bleibt).
Nutzung des Kennzeichens ABBR im Ortsdatensatz
Anwender gibt keine Hierarchie ein, sondern ausschließlich die von ihm gewünschte Version des Ortsnamens (Inhalt hinter PLAC ohne Komma)
optionale Exporte (ohne die nach P6 für den Standardexport empfohlene Version mit Verwaltungsebenen in PLAC / PLAC.FORM. Problem: Die damit in den Ortsdatensatz verlagerten Verwaltungszuordnungen gehen verloren, wenn das empfangende Programm die Ortsdatensätze nicht auswerten kann.)

Die meisten Programme können verschiedene Bezeichnungen hinter PLAC für denselben Ort (historische Namen, unterschiedliche Schreibweisen, z.B. exakte Übernahme aus der dem Ereignis zugeordneten Quelle) nicht mit einem einzigen Ortsdatensatz verbinden. Das führt dazu, dass für denselben Ort bei Verwendung der verschiedenen Schreibweisen / historischen Namen in der Ortsverwaltung mehrere Ortsdatensätze angelegt werden.

Die Diskussion zu diesem Punkt ist noch zu keinem Ergebnis gekommen, welches einen Entscheidungsvorschlag ermöglichen würde.

Verweise auf andere Ortsdatenbanken als GOV

Bereits vereinbart ist, mit dem Nutzerdefinierten Kennzeichen _GOV auf das Geschichtliches OrtsVerzeichnis des Vereins für Computergenealogie zu verweisen. Die besondere Rolle des GOV für die Genealogie, auch mit der zur Verfügung stehenden Möglichkeit, das GOV direkt aus Genealogieprogrammen heraus abzufragen bzw zu verlinken, rechtfertigt diesen Sonderstatus. Es gibt aber weitere Ortsdatensammlungen / Ortsdatenbanken, wie z.B. Geonames oder OpenGeoDb. Vorgeschlagen wurde daher, für entsprechende Verweise ein Nutzerdefiniertes Kennzeichen einzuführen:

n _GEOS <ID der Ortsdatenbank, die durch TYPE spezifiziert ist> {0:M}
n+1 TYPE <Ortsdatenbank> {1:1}

Diese Konstruktion könnte auch für GOV verwendet werden, jedoch ist aufgrund der bereits vereinbarten Version mit dem Kennzeichen _GOV eine Vielzahl von Dateien mit diesem Kennzeichen entstanden. Dieses sollte daher beibehalten werden.

Musterdatei, Teil PLAC und _LOC

Änderungen und Ergänzungen sind in der Arbeitsliste vorgeschlagen zu: - Aufname von ABBR, ABBR.TYPE, LANG in den _LOC Datensatz - Zitat geonames im _LOC Datensatz - Korrektur zwischen dargestellter Verwaltungsstruktur in PLAC und FORM

Diskussionsstand in der Arbeitsgruppe der Programmautoren (Runde 2, 2014)

Übersicht Themen in Runde 2

erledigte Themen:

Formalisierung: Aufnahme LOCATION_RECORD in die Definition von RECORD
Korrekturen/Ergänzungen zu Vereinbarung P4 (Ortsdatensätze)
Bürgerort

Bürgerort

Entscheidung getroffen und in P8 dokumentiert.

In der Vereinbarung P8 werden neben der zum Export empfohlenen Version auch die Varianten genannt, die auch in bereits existierenden GEDCOM-Dateien vorgefunden wurden, und deren Import ermöglicht werden soll. Darüberhinaus war folgende neue Variante diskutiert worden:

1 EVEN <Anwendereingabe für Bürgerort>
2 TYPE Bürgerort
2 PLAC Ort,Kreis,Land,Staat

Die getroffenen Vereinbarung P8 beruht auf folgendem Diskussionsergebnis: Alle bereits in GEDCOM-Dateien vorgefundenen Versionen sollten beim Import berücksichtigt werden. Die Versionen mit nutzerdefinierten Kennzeichen _BUERGERORT bzw. _HEIM sollte nicht exportiert werden, weil sie wenig Verbreitung haben und sehr oft beim Import verloren gehen. Gegenüber EVEN hat FACT zwar den Vorteil, semantisch die Aussage besser zu treffen (der Bürgerort ist ein der Person über längere Zeit zugeordnetes Attribut und kein Ereignis zu einem bestimmten Zeitpunkt), aber auch hier setzt die geringe Verbreitung von FACT der Übertragungssicherheit sehr enge Grenzen.

Erweiterung GEDCOM 5.5. EL

Der GEDCOM-Standard 5.5 wurde gemeinsam von 6 Programmautoren mit Compgen im Rahmen des GEDCOM_5.5EL - Projektes u.a. um eine detailliertere Beschreibung von Orten mit Ortsdatensätzen _LOC erweitert.

Diese Vorgehensweise erlaubte 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. Die Vorgehensweise wurde grundsätzlich von der Gedcom-L übernommen, jedoch in einigen Details geändert. Damit wurde neben Erweiterungen vor allem eine Kompatibilität zum GEDCOM-Standard 5.5.1 erreicht. Statt der früheren GEDCOM5.5EL Erweiterung werden jetzt die in diesem Artikel beschriebenen und von dem erweiterten Programmautorenkreis verabschiedeten Vereinbarungen zu Ortsdatensätzen _LOC zur Umsetzung empfohlen.

Diskussionsstand in der Arbeitsgruppe der Programmautoren (beendete Runde 1)

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.

Die Programmautoren haben sich für Variante A entschieden, siehe Vereinbarung P5.

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.