GEDCOM/ LOC-Tag

Name und Bedeutung

Tag

_LOC

Formelle Bezeichnung

LOCATION

Deutsche Bezeichnung

Ortsobjekt

Verwendung

Das Kennzeichen _LOC dient dazu, die Daten eines Ortes, an dem ein Ereignis stattfand, in einem eigenen Datensatz zusammenzufassen.

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. Dieses Kennzeichen ist im GEDCOM Standard nicht ausreichend, um die Daten einer hierarchischen Struktur, die historischen Zusammenhänge zwischen verschiedenen Orten und ihren übergeordneten Verwaltungseinheiten, geographischen Einheiten oder die Strukturen von Kirchenhierarchien darzustellen.

Daher haben die Mitglieder der Gedcom-L Arbeitsgruppe zunächst unter dem Kennzeichen PLAC die Einführung eines Nutzerdefinierten Kennzeichens _LOC vereinbart, welches auf der Ebene 0 zur Ausgabe eines Datensatzes für ein Ortsobjekt verwendet wird. Diese Datensätze werden als dem Kennzeichen PLAC untergeordnete Zeilen referenziert:

...
2 PLAC Musterort
3 _LOC @P1@
...
0 @P1@ _LOC
1 NAME Musterort
...

Die beiden Kennzeichen PLAC und _LOC sind eng miteinander verbunden. Die Verwendung von _LOC in anderen Datensätzen (unter dem Kennzeichen PLAC) wird weiter im Artikel zu PLAC beschrieben.

Dieser Artikel dient der Weiterentwicklung und Präzisierung der Vereinbarungen zu den Ortsdatensätzen.

Vereinbarungen zu _LOC

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 enthält bislang die im August 2013 vereinbarten Änderungen und Ergänzungen zu PLAC/P4, hier als_LOC/L1 geführt; sowie die Vereinbarung PLAC/P7, hier jetzt als L2 geführt. In 2019 sind die Vereinbarungen präzisiert und teilweise auch modifiziert worden. Diese Änderungen aus 2019 sind in L1 bis L3 eingearbeitet.

L1 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:M}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}
1 _POST <POSTAL_CODE> {0:M}
2 DATE <DATE_VALUE> {0:1}
2 <<SOURCE_CITATION>> {0:M}
1 _GOV <GOV_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_DESCRIPTOR>|<NULL>] {0:M}
2 <<EVENT_DETAIL>> {0:1}
1 _LOC @<XREF:_LOC>@ 0:M
2 TYPE <HIERARCHICAL_RELATIONSHIP> {0: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 <<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}

mit

<HIERARCHICAL_RELATIONSHIP>:= [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 <TYPE_OF_LOCATION> im aufgerufenen Datensatz.

L2 Formalisierung: Aufnahme LOCATION_RECORD in die Definition von RECORD

In die Definition des RECORD im GEDCOM-Standard 5.5.1 wird der Ortsdatensatz <<LOCATION_RECORD>> wie folgt aufgenommen:

   RECORD:= 
   [ 
   n <<FAM_RECORD>> {1:1} 
   | 
   n <<INDIVIDUAL_RECORD>> {1:1} 
   | 
   n <<MULTIMEDIA_RECORD>> {1:1} 
   | 
   n <<NOTE_RECORD>> {1:1} 
   | 
   n <<REPOSITORY_RECORD>> {1:1} 
   | 
   n <<SOURCE_RECORD>> {1:1} 
   | 
   n <<SUBMITTER_RECORD>> {1:1}
   |
   n <<LOCATION_RECORD>> {1:1}
   ]

Entscheidungsvorschläge zu _LOC (2019)

L1.1 Entfall des Kennzeichens _NAMC

Das in Anlehnung an GEDCOM 5.5 EL vereinbarte Kennzeichen _NAMC unter NAME entfällt ersatzlos. Mit diesem Kennzeichen wurde in einigen Programmen eine Trennung des Ortsnamens in zwei Bestandteile durchgeführt, die diese Programme aber auch beim Import aus einem komplett angelieferten Ortsnamen in NAME bilden können. Wegen der Interpretationsschwierigkeiten in anderen Programmen soll daher der Ortsname komplett unter NAME exportiert werden.

L1.2 Einführung des Kennzeichens RELI im Ortsdatensatz

In L1 und L2 wird zusätzlich eingefügt:

1 RELI <DENOMINATION> {0:1}

mit <DENOMINATION> := SIZE{1:30} Konfession des Ortsobjektes. Zu verwenden insbesondere bei Kirchen und Objekten der Kirchenorganisationen. Die Angabe kann Klartext sein wie vom Anwender eingegeben, oder aber zur Internationalisierung sprachunabhängig aus der Liste der Abkürzungen für Konfessionen gewählt werden ([1] oder konfession.csv auf [2]).

{Redaktioneller Hinweis: Die Datei konfession.csv soll in eine mehrsprachige Form überführt werden und dann an anderer Stelle neu angeboten werden. Der Link wird dann redaktionell geändert}

L1.3 Änderung zur TYPE unter 1 _LOC

Bislang wurde vereinbart, dass bei Einsatz der Verbindung zur nächsthöheren Ortsobjektebene über 1 _LOC zwingend eine Zeile 2 TYPE folgen muss:

1 _LOC @<XREF:_LOC>@ 0:M
2 TYPE <HIERARCHICAL_RELATIONSHIP> {1:1}

Da die Art dieser Verbindung aber aus der detaillierteren Beschreibung des zitierten Ortsobjekts auch hervorgeht und diese Information also redundant ist, wird sie in L1 auf eine optionale Ausgabe verändert:

1 _LOC @<XREF:_LOC>@ 0:M
2 TYPE <HIERARCHICAL_RELATIONSHIP> {0:1}

L1.4 Entfall der FOKO Kennzeichen _FPOST, _FSTAE, _FCTRY

Das FOKO System ist inzwischen abgeschaltet, zum Teil auch die Dokumentation der verwendeten Bezeichnungen nicht mehr verfügbar. Aus diesem Grunde werden in L1 und L3 sowie in PLAC/P3 die Kennzeichen _FPOST, _FSTAE und _FCTRY entfernt.

siehe PLAC/P3 http://wiki-de.genealogy.net/GEDCOM/PLAC-Tag#Vereinbarungen_zu_PLAC, P3

L1.5 Aufnahme der GOV Objekttyp-ID

Zur sprachunabhängigen Identifikation der Objekttypen <TYPE_OF_LOCATION> wird ein Kennzeichen _GOVTYPE eingeführt, welches den Export der ID eines Ortsobjekttyps im GOV System [3] erlaubt. Dieses Kennzeichen wird im _LOC Datensatz dem Kennzeichen TYPE wie folgt unterstellt:

...
1 TYPE <TYPE_OF_LOCATION> {0:M}
2 _GOVTYPE <GOVID_OF_TYPE> {0:1}
...

mit <GOVID_OF_TYPE>:= {Size=1:3} als einer ganzzahligen, positiven Zahl, wie sie im GOV System definiert ist. Die Definition im GOV System [4]ist verbindlich für die Interpretation dieser Zeile und erlaubt eine Interpretation der übergeordneten Zeile 1 TYPE für alle im GOV-System hinterlegten Sprachen. Hierfür steht auch die mehrsprachige RDF-Datei mit den Definitionen der Objekttypen des GOV-Systems zur Verfügung [5].

Bei Annahme dieses Entscheidungsvorschlages werden L1 und L3 entsprechend erweitert.

Änderungsumfang zu _LOC L1 (PLAC P4) vom August 2013

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

L1/P4korr Ergänzungen und Korrekturen zu L1/P4

An der in Runde 1 verabschiedeten Vereinbarung L1 (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 L1 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 L1 Ortsdatensätze
• Musterdatei, Teil PLAC und _LOC

Konkretisierungen zur Vereinbarung L1/P4 Ortsdatensätze

Die getroffene Vereinbarung zu Ortsdatensätzen L1 (P4) enthält neue Strukturelemente, die bislang nicht näher beschrieben sind. Außerdem enthält sie Stukturelemente, die zwar im GEDCOM-Standard definiert sind, die hier aber in anderem Kontext stehen und ggfs. eine andere Bedeutung haben. Somit betseht Bedarf, diese Elemente näher zu beschreiben.

Ein allererster Entwurf hierzu wurde zur Diskussion gestellt und als L2 als Entscheidungsvorschlag eingestellt.

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 L1 (Ortsdatensätze)

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.

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.