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 ersten untergeordneten CONT-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 zweiten untergeordneten CONT-Zeile aus dem ADDR-Kennzeichen der Adress-Struktur.

</zitat>

Das englische Original des Standards dazu:

<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 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 dürfen diese Zeilen *nicht an Stelle der* ADDR und CONT Struktur genutzt werden.

Vereinbarungen zu ADDR

Die Vereinbarungen zu ADDR sind aus der Diskussion auf der Gedcom-L hergeleitet. Sie wurden durch eine Abstimmung unter den an der Gedcom-L beteiligten Programmautoren entschieden.

A1 Export der Postadresse

Mit den Kennzeichen ADDR und den untergeordneten CONT wird die Postadresse in der Form exportiert, wie sie auf einem Brief stehen würde. Massgeblich hierfür ist, was der Anwender in ein entsprechendes mehrzeiliges Datenfeld eingetragen hat oder - bei Fehlen eines solchen Adressfeldes - das Programm aus untergeordneten Einzelelementen ersatzweise zusammengesetzt hat. Für dieses ersatzweise Zusammensetzen wird die gleiche Form wie in A2 empfohlen.

Die Beschränkung im GEDCOM-Standard auf max. 3 Folgezeilen mit CONT wird aufgehoben. Entsprechend der Vereinbarung E2 zu Feldlängen hat die Struktur des Datenfeldes im Programm Vorrang: Hat dieses Datenfeld mehr als 4 Zeilen und sind diese mit Daten belegt, so werden auch mehr als 3 CONT Zeilen unter ADDR exportiert.

A2 Import der Postadresse

Für Programme mit einem mehrzeiligen Adressfeld für die Postadresse werden folgende Empfehlungen zum Import gegeben: Findet ein Programm mit einer begrenzten Anzahl von Folgezeilen im Datenfeld für die Postadresse beim Import eine höhere Anzahl von Folgezeilen vor, so wird empfohlen, den Inhalt der weiteren Folgezeilen der Importdatei jeweils durch Komma abgetrennt an die letzte Folgezeile im Datenfeld anzuhängen. Hat die zu importierende Datei keine mit CONT dargestellten Folgezeilen, aber strukturierte Elemente zur Postadresse ADR1, ADR2, ADR3, CITY, POST, STAE oder CTRY, so wird empfohlen, diese Informationen in das mehrzeilige Feld der Postadresse mit aufzunehmen in der folgenden Form:

• 1 ADDR (ADDR)
• 2 CONT (ADR1)
• 2 CONT (ADR2), (ADR3)
• 2 CONT (POST), (CITY), (STAE), (CTRY)

Hierbei ist mit einem eingeklammerten Kennzeichen jeweils der Inhalt der Zeile hinter diesem Kennzeichen gemeint.

A3 Export von strukturierten Elementen zur Postadresse

Zusätzlich zum vorgeschriebenen Export der Postadresse nach A1 müssen Programme mit interner Adressdatenstruktur diese Struktur als Folgezeilen unter ADDR ebenfalls exportieren, dazu werden die im Standard vorgesehenen Kennzeichen ADR1, ADR2, ADR3, CITY, POST, STAE und CTRY verwendet. Enthält die Postadresse auch den Namen des Adressaten, so wird empfohlen, diesen Namen mittels eines Kennzeichen _NAME unter ADDR zu exportieren.

A4 Export weiterer strukturierter Adress-Elemente

Neben ADDR als Pflichtzeile dürfen weitere Elemente mit den dafür im GEDCOM Standard vorgesehenen Kennzeichen PHON, EMAIL, FAX und WWW exportiert werden. Zu den widersprüchlichen Angaben im Standard zur Email wird vereinbart, dass EMAIL (und nicht EMAI) eingesetzt wird. Hinweis: Die allgemeine Regel des Standards, dass explizit definierte Kennzeichen 3 oder 4 Zeichen lang sind, ist in diesem Fall in der expliziten Beschreibung des Kennzeichens im Standard nicht eingehalten.

A5 Zusammenfassung der Adress-Struktur im Export

Unter Beachtung der vorstehenden Vereinbarungen sieht somit ein Export einer Adresse insgesamt so aus:

ADDRESS_STRUCTURE:=
n ADDR <ADDRESS_LINE> {0:1}       *)
+1 CONT <ADDRESS_LINE> {0:M}
+1 _NAME <NAME_OF_ADRESSEE> {0:1}
+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}

*) nach Vereinbarung A8 auf {0:1} geändert, im GEDCOM 5.5.1 steht hier {1:1}

A6 Einsatzmöglichkeiten der Adress-Struktur

Dem GEDCOM-Standard folgend, darf die Adress-Struktur aus A5 ausschließlich in folgenden Fällen 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)

A7 Adressen in Personen- und Familiendatensätzen

Wird beim Import einer Datei die Adressen-Struktur entgegen der Vorgaben des GEDCOM-Standards in Personen- oder Familiendatensätzen auf der Steuerebene 1 gefunden, so wird für einen ggfs folgenden Re-Export empfohlen, die Adress-Struktur unter das Kennzeichen RESI zu stellen, z.B.:

0 @I1@ INDI
1 NAME Max /Mustermann/
1 RESI
2 ADDR Musterstr. 3
3 CONT 12345 Musterstadt
...

A8 Telefon, Fax, Email und WWW ohne Adressangaben

Zu den widersprüchlichen Angaben des GEDCOM Standards zwischen der ADDRESS_STRUCTURE und der generellen Regel, dass eine Zeile ohne Zeilen_Wert und ohne Folgezeile nicht erlaubt ist, wird vereinbart: Die Kennzeichen PHON, FAX, WWW und EMAIL dürfen auch ohne die Zeile n ADDR exportiert werden, wenn keine Adressangaben des Anwenders vorliegen. Das bedeutet, dass in der Vereinbarung A5 die vorgeschriebene Häufigkeit für n ADDR von {1:1} in {0:1} verändert wird.

Behandlung/Darstellung schwieriger Situationen

Darstellung von Telefonnummern etc ohne Adressangaben

Der GEDCOM-Standard 5.5.1 schreibt vor, dass eine Zeile ohne Zeilenwert und ohne untergeordnete Zeile (mit um 1 höherer Ebenennummer) nicht vorkommen darf. Offensichtliche Ausnahmen sind CONT und TRLR. Aber auch bei ADDR ergibt sich hier ein Problem. Da das Kennzeichen ADDR in der ADDRESS_STRUCTURE mit {1:1} steht, müsste eine Telefonnummer (analog eine Email, WWW oder Fax) so ausgegeben werden:

2 ADDR
2 PHON 0049 ...

im klaren Widerspruch zu der Vorgabe, dass ADDR ohne Inhalt und ohne Folgezeile nicht zulässig ist. Der GEDCOM-Standard löst diesen Widerspruch nicht auf. Die Programme setzen das ggfs. unterschiedlich um, einige lassen hier 2 ADDR weg und exportieren nur die Angabe zu PHON.

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 Verwendung 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. Da der ganz überwiegende Anteil bereits existierender GEDCOM-Dateien EMAIL (und nicht EMAI) verwendet, wurde vorgeschlagen, abweichend von der übergeordneten Regel das Kennzeichen EMAIL wie explizit beschrieben (und nicht EMAI) einzusetzen.

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).

Nach Standard nicht 1:1 darstellbar sind dabei Postanschriften, die mehr als 4 Zeilen beinhalten. Die Diskussion in der Liste führt aber in die Richtung, diese Begrenzung auf nur 3 max. erlaubte CONT Zeilen unter ADDR aufzuheben, wie es auch schon aus der bereits verabschiedeten Vereinbarung E2 zu Feldlängen generell folgt.

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 10247, Berlin, 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 12345 Musterstadt
3 CONT 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 12345 Musterstadt
3 CONT Musterland, Musterstaat
3 _NAME Max Mustermann
3 ADR1 Musterstr. 3
3 CITY Musterstadt
3 POST 12345
3 STAE Musterland
3 CTRY Musterstaat

Und es gibt 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 (Beispiel hat zusätzlich Telefon, Fax, Email und Homepage):

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 12345 Musterstadt
3 CONT Musterland, Musterstaat
3 _NAME Max Mustermann
3 ADR1 Musterstr. 3
3 CITY Musterstadt
3 POST 12345
3 STAE Musterland
3 CTRY Musterstaat
2 PHON 01234-56789
2 EMAIL max.mustermann@@muster.de
2 WWW www.mustermann@@muster.de
2 FAX 01234-56780

???

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 nur erforderlich, um PHON, EMAIL, WWW und FAX zu begleiten, wenn ansonsten 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. Ebenfalls kommt vor, dass PHON, FAX, EMAIL und/oder WWW unter ADDR gestellt werden - diese Kennzeichen müssen aber auf derselben Ebene wie ADDR exportiert werden.