GEDCOM/ADDR-Tag

Name und Bedeutung

Tag

ADDR

Formelle Bezeichnung

ADDRESS

Deutsche Bezeichnung

Adresse

Verwendung

Mit dem Kennzeichen ADDR werden Adressdaten in GEDCOM-Dateien dargestellt. Diese Adressdaten können für Personen, Organisationen, Firmen etc gebildet werden. Die Adressdaten beinhalten sowohl Informationen, die für den Postversand erforderlich sind ( Straße, Hausnummer, Ort, PLZ, Staat ), als auch Angaben über Telefon, Fax, Email und Homepages.

Einsatzfälle laut GEDCOM-Standard

Die Adress-Struktur und damit das Kennzeichen ADDR darf in folgenden Kontexten eingesetzt werden:

• im Verfasser-Datensatz (SUBM, auf Steuerebene 1)
• im Archiv-Datensatz (REPO, auf Steuerebene 1)
• im Kopf der Datei (HEAD, unter 2 CORP auf Steuerebene 3)
• im EVENT_DETAIL und damit unter allen Ereignissen und Attributen in Personen- und Familiendatensätzen (jeweils auf Steuerebene 2)

Andere Verwendungen sind nicht zulässig.

Formale Beschreibung zulässiger Werte

Definitionen im GEDCOM-Standard

(aus deutscher Übersetzung von Jörn Daub)

Adressen können in einer GEDCOM-Datei mit folgender Struktur dargestellt werden:

ADDRESS_STRUCTURE:=
n ADDR <ADDRESS_LINE> {1:1}
+1 CONT <ADDRESS_LINE> {0:3}
+1 ADR1 <ADDRESS_LINE1> {0:1}
+1 ADR2 <ADDRESS_LINE2> {0:1}
+1 ADR3 <ADDRESS_LINE3> {0:1}
+1 CITY <ADDRESS_CITY> {0:1}
+1 STAE <ADDRESS_STATE> {0:1}
+1 POST <ADDRESS_POSTAL_CODE> {0:1}
+1 CTRY <ADDRESS_COUNTRY> {0:1}
n PHON <PHONE_NUMBER> {0:3}
n EMAIL <ADDRESS_EMAIL> {0:3}
n FAX <ADDRESS_FAX> {0:3}
n WWW <ADDRESS_WEB_PAGE> {0:3}

ADDR ist Pflichtfeld in der Adress-Struktur {1:1}, die anderen dürfen einmal {0:1} oder dreimal {0:3} auftauchen. Gemäß dieser Vorgabe ist es nicht zulässig, die Kennzeichen PHON, EMAIL, FAX oder WWW ohne das Kennzeichen ADDR zu verwenden, obwohl diese Kennzeichen nicht dem ADDR unterstellt sind.

Die Adresse wird als mehrzeiliges Adressfeld ( über ADDR mit den max. 3 CONT-Zeilen, oder über ADDR mit den Zeilen ADR1, ADR2, ADR3 ) dargestellt. Der Standard führt dazu aus:

<zitat> ADDRESS_LINE:= {Size=1:60} (Adresszeile) Wenn sie dem RESI-Kennzeichen untergeordnet ist, wird es typischerweise dazu genutzt, eine Postanschrift der Person zu verzeichnen. Wenn die Adresszeile einem Ereignis untergeordnet ist, so ist es die Adresse des Ortes, an dem das Ereignis stattfand. Die Adresszeilen beinhalten normalerweise den Adressaten und andere Straßen- und Ortsdaten, so dass sie zusammen eine Adresse formen, um die Voraussetzungen für den Postversand zu erfüllen. </zitat>

Die beiden Versionen ADDR + CONT und ADDR mit ADRi hängen eng zusammen:

<zitat>

• ADDRESS_LINE1:= {Size=1:60} (Adresszeile 1) Die erste Zeile der Adresse zur Indexierung. Dies ist der Wert der korrespondierenden Zeile aus dem ADDR-Kennzeichen der Adress-Struktur.
• ADDRESS_LINE2:= {Size=1:60} (Adresszeile 2) Die zweite Zeile der Adresse zur Indexierung. Dies ist der Wert der korrespondierenden Zeile aus dem ADDR-Kennzeichen der Adress-Struktur.
• ADDRESS_LINE3:= {Size=1:60} (Adresszeile 3) Die dritte *) Zeile der Adresse zur Indexierung. Dies ist der Wert der korrespondierenden Zeile aus dem ADDR-Kennzeichen der Adress-Struktur.

</zitat> Anmerkung: *) in der Übersetzung steht hier irrtümlich "erste"

Das englische Original des Standards ist hier präziser:

<zitat>

• ADDRESS_LINE1:= {Size=1:60}
• The first line of the address used for indexing. This is the value of the line corresponding to the ADDR tag line in the address structure.
• ADDRESS_LINE2:= {Size=1:60}
• The second line of the address used for indexing. This is the value of the first CONT line subordinate to the ADDR tag in the address structure.
• ADDRESS_LINE3:= {Size=1:60}
• The third line of the address used for indexing. This is the value of the second CONT line subordinate to the ADDR tag in the address structure.

</zitat>

Demnach gilt also folgende Zuordnung:

• 1 ADDR == 2 ADR1 (erste Zeile des Adressfeldes)
• 2 CONT == 2 ADR2 (zweite Zeile des Adressfeldes, erste CONT-Zeile)
• 2 CONT == 2 ADR3 (dritte Zeile des Adressfeldes, zweite CONT-Zeile)
• 2 CONT (vierte Zeile des Adressfeldes, nur über 3.CONT-Zeile

Mit den Kennzeichen CITY, POST, STAE und CTRY werden Teilelemente aus der der Postanschrift strukturiert wiederholt, so dass sie in Programmen mit einer detaillierten Adressverwaltung in entsprechende Datenfelder geschrieben werden können. Dabei schreibt der GEDCOM-Standard explizit vor, dass diese Kennzeichen nicht an Stelle der ADDR + CONT, sondern nur ergänzend eingesetzt werden dürfen:

<zitat> The ADDR and CONT lines are required for any address. The additional subordinate address tags such as STAE and CTRY are provided to be used by systems that have structured their addresses for indexing and sorting. For backward compatibility these lines are not to be used in lieu of the required ADDR.and CONT line structure. </zitat>

Die deutsche Übersetzung von Jörn Daub ist hier nicht korrekt:

<zitat> Die ADDR und CONT-Zeilen werden für jede Adresse benötigt. Die untergeordneten Kennzeichen wie etwa STAE und CTRY sind für Systeme, die ihre Adressdaten zur Indexierung oder Sortierung strukturiert haben. Aus Gründen der Rückwärtskompatibilität sollten diese Zeilen nicht zusammen mit ADDR und CONT genutzt werden. </zitat>

Statt dessen sollte es heißen: Die ADDR und CONT-Zeilen werden für jede Adresse benötigt. Die untergeordneten Kennzeichen wie etwa STAE und CTRY sind für Systeme, die ihre Adressdaten zur Indexierung oder Sortierung strukturiert haben. Aus Gründen der Rückwärtskompatibilität sollten diese Zeilen *an Stelle der* ADDR und CONT Struktur genutzt werden.

Behandlung/Darstellung schwieriger Situationen

strukturierte Darstellung versus Postanschrift

Wie bei anderen Themen kommt auch hier die Problematik, dass die Programme unterschiedliche Funktionstiefen haben:

• gar keine Unterstützung der Adressen
• nur eine einfache Zeile für die Adressen (z.B. als Ersatz für das frühere SITE Kennzeichen)
• ein mehrzeiliges Adressfeld für die Postadresse
• eine komplette Adressverwaltung mit detaillierten Einzelfeldern für die Adresselemente

Der Transfer zwischen diesen verschiedenen Programmen bietet einige Schwierigkeiten, da ein Programm ohne Einzelfelder natürlich die Struktur CITY, POST, STAE, CTRY nicht direkt aufnehmen kann. Diese Programme werden immer erst einmal die in ADDR mit den 3 CONT Zeilen hinterlegte Postadresse einlesen, die Einzelinformationen dagegen nicht strukturiert aufnehmen. Hat die importierte GEDCOM-Datei in Abweichung zu den Vorgaben des Standards keine CONT Zeilen nach ADDR, kann ein solches Programm höchstens noch versuchen, die Daten aus den CITY, POST, STAE, CTRY herauszuholen und in eine Zeile seines Adressfeldes zu schreiben.

Umgekehrt hat ein Programm mit expliziter Adress-Struktur ein Problem, wenn es eine Adress-Information importiert, die nur die mehrzeilige Postanschrift enthält, aber nicht einzelne Elemente strukturiert anbietet. Daraus die "richtige" Zuordnung der Einzelinformationen zu gewinnen, dürfte nicht immer ohne Nachfrage beim Anwender gelingen.

ADDR + CONT versus ADDR + ADRi

Die doppelte Darstellung der mehrzeiligen Postaddresse sowohl über die vorgeschriebene ADDR + CONT Struktur als auch über die zusätzlich zulässige ADR1, ADR2, ADR3 Struktur macht in der Praxis Probleme. Während der Standard eine Zuordnung zwischen diesen Ausgaben fest vorsieht, weichen konkrete Programme davon ab. So wird z.B. der Inhalt von ADDR statt mit ADR1 mit einem _NAME strukturiert, und dann die erste CONT Zeile nach ADDR statt mit ADR2 mit ADR1 gleichgesetzt. Viele Programme führen die ADR3 gar nicht, so dass diese Strukturinformation beim Transfer verloren geht. Wegen der unterschiedlichen Verwednung der ADRi Zeilen kommt es sowohl zu Doppelungen von Informationen als auch zu Informationsverlusten.

EMAIL versus EMAI

Der GEDCOM Standard ist mit dem Kennzeichen EMAIL in der Grammatik nicht konsequent, denn an anderer Stelle wird ausgeführt, dass explizit im Standard definierte Kennzeichen entweder drei oder vier Zeichen haben. Daher wird der Vorschlag gemacht, zur Einhaltung der übergeordneten Regel das Kennzeichen EMAIL in EMAI abzuändern.

Postanschrift versus strukturierte Einzeldaten

Eine längere Diskussion in der Gedcom-L läuft zu der Frage, ob bei Export der strukturierten Einzeldaten auch die Postadresse in ihrer jeweils länderspezifischen Form über ADDR mit den bis zu drei CONT Zeilen ausgegeben werden soll. Einerseits ist das zwar eine weitgehende Wiederholung, andererseits ist die Postadresse jedoch nicht eindeutig aus den Einzelelmenten zusammenzusetzen, da die Anordnung und Reihenfolge der Elemente länderspezifisch ist. Daher wird dafür plädiert, neben den Einzelelmenten auch die Vorschrift des Standards einzuhalten, die Postanschrift in ihrer korrekten Anordnung mit zu exportieren (über die ADDR mit bis zu 3 CONT Zeilen).

Nicht 1:1 darstellbar sind dabei Postanschriften, die mehr als 4 Zeilen beinhalten.

Einbindung strukturierter Daten in die letzte CONT-Zeile unter ADDR

Bei der Übernahme von strukturierten Daten gibt es von Drittprogrammen, z.B. Legacy, die Vorgehensweise, die Daten aus CITY, POST, STAE und CTRY in einer CONT-Zeile zusammenzufassen.

Beispiel:

Aus

3 CITY Berlin
3 POST 10247
3 STAE Berlin
3 CTRY Germany

würde z.B. als CONT-Zeile gebildet:

3 CONT Berlin, 10247, Berlin, Germany

Damit ist zwar strukturierter Inhalt in halbwegs nachvollziehbarer Weise in die CONT-Zeile gebracht, aber diese CONT Zeile hat dann nicht mehr die Form einer Postanschrift! Auch andere Reihenfolgen, z.B. Voranstellung der Postleitzahl vor den Ort (um mehr die europäische Anordnung zu reflektieren) wurden vorgeschlagen.

Name einer Adresse

Es gibt Programme, die in ihren Einzelelementen neben den explizit vorgesehenen Elementen auch den Namen des Adressaten aus der ADDRESS_STRUCTURE strukturiert herauslösen, indem sie diesen mit dem Kennzeichen _NAME dem Kennzeichen ADDR unterordnen. Es gibt den Vorschlag, diese Vorgehensweise zu übernehmen.

Dabei stellt sich die Frage, ob damit dann nicht auch die Zuordnung zu den ADRi wie folgt geändert werden sollte:

• 1 ADDR == 2 _NAME (erste Zeile des Adressfeldes)
• 2 CONT == 2 ADR1 (zweite Zeile des Adressfeldes)
• 2 CONT == 2 ADR2 (dritte Zeile des Adressfeldes, erste CONT-Zeile)
• 2 CONT == 2 ADR3 (vierte Zeile des Adressfeldes, zweite CONT-Zeile)

ADDR als Ersatz für SITE

Der GEDCOM-Standard hat das früher explizit zulässige Kennzeichen SITE inzwischen aus dem zulässigen Umfang herausgenommen. Begründung: SITE ist Teil einer Adresse, kann also über ADDR dargestellt werden.

Damit ist also eine Ausgabe wie

0 @I1@ INDI
1 NAME Max /Mustermann/
2 GIVN Max
2 SURN Mustermann
1 BURI
2 PLAC Musterstadt, Musterkreis, Musterland, Musterstaat
2 ADDR Musterfriedhof

oder

0 @F1@ FAM
1 HUSB @I1@
1 WIFE @I2@
1 MARR
2 PLAC Musterstadt, Musterkreis, Musterland, Musterstaat
2 ADDR Musterkirche

zu erwarten.

Selbstverständlich wäre auch GEDCOM-konform (für das Familienbeispiel):

0 @F1@ FAM
1 HUSB @I1@
1 WIFE @I2@
1 MARR
2 PLAC Musterkirche, Musterstadt, Musterkreis, Musterland, Musterstaat
3 FORM church, place, county/district, state, country

Die beiden vorstehenden GEDCOM-Ausschnitte transportieren den gleichen Inhalt, im zweiten Fall jedoch durch die explizite Strukturangabe „church“ unter FORM mehr strukturiert als im ersten Fall! Ähnlich könnte das erste Beispiel mit cemetery unter FORM auch strukturiert werden, um den Musterfriedhof als PLAC darzustellen…

Zusammenhang RESI und ADDR

Gemäß GEDCOM Standard werden unter RESI in einem Kennzeichen ADDR die Adressdaten dargestellt. Das birgt eine ganze Reihe von Unklarheiten, die in der Liste angesprochen wurden:

RESI {RESIDENCE}:= (Wohnort) Eine Adresse oder Wohnort, an dem eine Person oder Familie wohnhaft war.

ADDR {ADDRESS}:= (Adresse) Eine zeitgenössiche Ortsangabe zu einer Person, normalerweise benötigt für postalische Zwecke, einer Person, eines Einreichers von Informationen, eines Quellarchives, eines Unternehmens, Schule oder Firma.

Hinter RESI darf nach GEDCOM-Grammatik kein Inhalt in der Zeile stehen, RESI wird alleine über die Folgezeilen mit Inhalt bedacht. Und RESI hat (ähnlich wie ADDR) auch die Bedeutung einer Adresse, unter RESI darf ADDR angeordnet sein.

Also einfaches Beispiel, wie es aussehen kann:

0 @I1@ INDI
1 NAME Max /Mustermann/
2 GIVN Max
2 SURN Mustermann
1 RESI
2 PLAC Musterstadt, Musterkreis, Musterland, Musterstaat
2 ADDR Musterstr. 3
3 CONT Musterstadt, 12345, Musterland, Musterstaat

Damit werden aber viele Informationen zwischen PLAC und ADDR.CONT gedoppelt. Mit Ortsdetails und Adressdetails sieht es dann z.B. so aus (nun auch mit einem Quellenzitat):

0 @I1@ INDI
1 NAME Max /Mustermann/
2 GIVN Max
2 SURN Mustermann
1 RESI
2 PLAC Musterstadt, Musterkreis, Musterland, Musterstaat
3 _FPOST 12345
3 MAP
4 LATI N50.05000
4 LONG E8.88333
2 SOUR @S1@
3 PAGE Kap.III S.34
2 ADDR Musterstr. 3
3 CONT Musterstadt, 12345, Musterland, Musterstaat
3 _NAME Max Mustermann
3 ADR1 Musterstr. 3
3 CITY Musterstadt
3 POST 12345
3 STAE Musterland
3 CTRY Musterstaat

Und gibt es noch ein Problem: Unter RESI beziehen sich die MAP-Koordinaten nicht auf den Wohnsitz (also nicht auf das Haus), sondern auf PLAC, also den Wohnort. Programme wie Legacy packen daher auch unter ADDR noch einmal (abweichend vom GEDCOM-Standard) eine MAP mit LATI und LONG.

Mögliche Lösungen:

• Die Koordinaten des Wohnhauses unter ADDR mit einem _MAP anordnen.
• Das Wohnhaus direkt in PLAC hineinschreiben und dann die spezifischen Koordinaten des Hauses einfügen:

0 @I1@ INDI
1 NAME Max /Mustermann/
2 GIVN Max
2 SURN Mustermann
1 RESI
2 PLAC Musterstr. 3, Musterstadt, Musterkreis, Musterland, Musterstaat
3 FORM street and number of house, place, county/district, state, country 
3 _FPOST 12345
3 MAP
4 LATI N50.12000
4 LONG E8.90000
2 SOUR @S1@
3 PAGE Kap.III S.34
2 ADDR Musterstr. 3
3 CONT Musterstadt, 12345, Musterland, Musterstaat
3 _NAME Max Mustermann
3 ADR1 Musterstr. 3
3 CITY Musterstadt
3 POST 12345
3 STAE Musterland
3 CTRY Musterstaat

???

Warum dann aber überhaupt noch die ADDR? Wäre komplette Doppelung von Informationen, nur ohne geografische Koordinaten! Und ohne Möglichkeit, Quellen anzugeben, oder den Zeitraum, wann diese Adresse gültig war oder noch ist. Also ist eigentlich ADDR in Personendatensätzen überflüssig, wenn stattdessen die erweiterte FORM für PLAC benutzt wird!?

Abweichungen vom Standard bei der Verwendung

Es gibt Programme, die ADDR auf der Ebene 1 in Personendatensätzen oder Familiendatensätzen verwenden. Dies ist ein klarer Verstoß gegen die GEDCOM-Grammatik.