GEDCOM/PLAC-Tag

From GenWiki

Jump to: navigation, search

Contents


This page is an English extract of the German page GEDCOM/PLAC-Tag [1], for full details see the German page.

Name and Meaning

Tag

PLAC

Meaning

PLACE

Usage

A jurisdictional name to identify the place or location of an event.

Formal Description of Permissible Values

Base: GEDCOM Standard Draft 5.5.1

Locations are described by the tag PLAC. For places there are no separate records as for NOTE or SOUR defined by the standard. Locations will be described with the following structure:

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}

The NOTE_STRUCTURE is covered by the NOTE tag - see page <<NOTE_STRUCTURE>>. The further data of the PLACE_STRUCTURE are described by the standard as follows:

PLACE_NAME:= {Size=1:120}

[

<PLACE_TEXT>

|

<PLACE_TEXT>, <PLACE_NAME>

]

The jurisdictional name of the place where the event took place. Jurisdictions are separated by commas, for example, "Cove, Cache, Utah, USA." If the actual jurisdictional names of these places have been identified, they can be shown using a PLAC.FORM structure either in the HEADER or in the event structure ( see <PLACE_HIERARCHY> ).

PLACE_TEXT:= {Size=1:120} <TEXT> excluding commas.

PLACE_HIERARCHY:= {Size=1:120}

This shows the jurisdictional entities that are named in a sequence from the lowest to the highest jurisdiction. The jurisdictions are separated by commas, and any jurisdiction's name that is missing is still accounted for by a comma. When a PLAC.FORM structure is included in the HEADER of a GEDCOM transmission, it implies that all place names follow this jurisdictional format and each jurisdiction is accounted for by a comma, whether the name is known or not. When the PLAC.FORM is subordinate to an event, it temporarily overrides the implications made by the PLAC.FORM structure stated in the HEADER. This usage is not common and, therefore, not encouraged. It should only be used when a system has over-structured its place-names.

PLACE_PHONETIC_VARIATION:= {Size=1:120}

The phonetic variation of the place name is written in the same form as was the place name used in the superior <PLACE_NAME> primitive, but phonetically written using the method indicated by the subordinate <PHONETIC_TYPE> value, for example if hiragana was used to provide a reading of a name written in kanji, then the <PHONETIC_TYPE> value would indicate kana ( see <PHONETIC_TYPE> ).

PHONETIC_TYPE:= {Size=5:30}

[<user defined> | hangul | kana] 

Indicates the method used in transforming the text to the phonetic variation.

  • <user defined> method used to arrive at the phonetic variation of the name.
  • hangul Phonetic method for sounding Korean glifs.
  • kana Hiragana and/or Katakana characters were used in sounding the Kanji character used by japanese.

PLACE_ROMANIZED_VARIATION:= {Size=1:120}

The romanized variation of the place name is written in the same form prescribed for the place name used in the superior <PLACE_NAME> context. The method used to romanize the name is indicated by the line_value of the subordinate <ROMANIZED_TYPE>, for example if romaji was used to provide a reading of a place name written in kanji, then the <ROMANIZED_TYPE> subordinate to the ROMN tag would indicate ‘romaji’ ( see <ROMANIZED_TYPE> )

ROMANIZED_TYPE:= {Size=5:30}

[<user defined> | pinyin | romaji | wadegiles] 

Indicates the method used in transforming the text to a romanized variation.

PLACE_LATITUDE:= {Size=5:8}

The value specifying the latitudinal coordinate of the place name. The latitude coordinate is the direction North or South from the equator in degrees and fraction of degrees carried out to give the desired accuracy. For example: 18 degrees, 9 minutes, and 3.4 seconds North would be formatted as N18.150944. Minutes and seconds are converted by dividing the minutes value by 60 and the seconds value by 3600 and adding the results together. This sum becomes the fractional part of the degree’s value.

PLACE_LONGITUDE:= {Size=5:8}

The value specifying the longitudinal coordinate of the place name. The longitude coordinate is degrees and fraction of degrees east or west of the zero or base meridian coordinate. For example: 168 degrees, 9 minutes, and 3.4 seconds East would be formatted as E168.150944.

Agreements for PLAC

The agreements for PLAC are derived from the discussion on the Gedcom-L. They were decided by a vote of the program authors of the list.

General Items

P1 Presentations of Place Information according to Standard

Place names may be presented according to the GEDCOM standard in the following ways:

n PLAC <PLACE_TEXT>
n PLAC <PLACE_NAME>

with

PLACE_NAME = [PLACE_TEXT, PLACE_NAME]

and

PLACE_TEXT = <TEXT> without commas.

In the second case it is a comma separated list ( each comma may follow a space ) of administrative levels, where the lowest is first called, the other follow by rising levels of government. Their meaning is stored in the tag FORM.

P2 Informations by Tag FORM

The tag FORM can be used in two places in the GEDCOM file to describe the information about the levels of administration for place names:

a) At the Header

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

In this case the description of the administrative levels applies for the entire GEDCOM file, unless it is overridden for a single PLAC tag by another subordinated tag FORM.

b) Directly subordinate to a PLAC-line in a record

In this case, the description applies only to the leading PLAC, a definition in the header will be overwritten only for this PLAC.

In order to standardize the procedure in the programs it is recommended to use the following version of FORM:

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

That means, the first four levels are used consistently. After that, any number of program-specific information may follow.

P3 Additional Informations to PLAC

According to the GEDCOM standard further optional tags are subordinated to the tag PLAC:

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}

This, in the standard explicitly defined information, may be supplemented as follows, where the use of user-defined tags listed here is recommended:

+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 Location Records

For a comprehensive location management the use of location records in accordance with GEDCOM 5.5EL is permitted:

The location record is referenced by the following line, subordinated to PLAC:

+1 _LOC @<XREF:_LOC>@

It is recommended to use for <XREF:_LOC> the form @Pnnn@ with nnn as a positive integer.

The location record itself is structured as follows:

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 _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 _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_DESCRIPTOR>|<NULL>] {0:M}
2 <<EVENT_DETAIL>> {0:1}
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 <<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}

with

<ADMINISTRATIVE_IDENTIFIER>:=

Identifier for a location with the intention of an administrative authority, e.g. community identifier.

<DEMOGRAPHICAL_DATA>:=

A number of objects, during an ascertainment, e.g. the count of households.

<FOKO_POSTCODE>:=

Sometimes FOKO (German data base Forscherkontakte = Researcher Contacts) uses other ZIP codes as the official post codes are, that´s why this special tag different to "POST".

<FOKO_STATE_IDENTIFIER>:=

Affiliation of a location to a "state" in FOKO.

<FOKO_TERRITORY_IDENTIFIER>:=

Affiliation of a location to a "territory" in FOKO.

<GOV_IDENTIFIER>:=

The official GOV code.

<HIERARCHICAL_RELATIONSHIP>:=

[POLI|RELI|GEOG|CULT]

in order to differentiate political ( administrative ), religious, geographical or cultural associations. For details on the TYPE of the quoted superior object the <TYPE_OF_LOCATION> regulates in the called record.

<MAIDENHEAD_LOCATOR>:=

The maidenhead code.

<PLACE_NAME_ADDITION>:=

Add-on to describe the location exactly, e.g. "an der Oder" or "am Main" (in Germany there are "Frankfurt an der Oder" /at river Oder/ and "Frankfurt am Main" /at river Main/)

<POSTAL_CODE>:=

The official ZIP code.

<TYPE_OF_ADMINISTRATIVE_IDENTIFIER>:=

TBD

<TYPE_OF_DEMOGRAPICAL_DATA>:=

[ HSHO | CITI ] means: household | resident

Type the demographic data for a place.

<TYPE_OF_LOCATION>:=

House, District, Borough, Village, Town, City, County, Street, Cemetry, Estate, Settlement, ...

P5 Geographical Coordinates

It is agreed to follow the requirements of the GEDCOM standard:

PLACE_LATITUDE must be represented as [Ngg.nnnnnn | Sgg.nnnnnn]

PLACE_LONGITUDE must be represented as [Wgg.nnnnnn | Egg.nnnnnn]

wherein prior to the point gg represent the degree (one to three digits), after the point nnnnnn represent the sum of the minutes divided by 60 plus seconds divided by 3600.

Example:

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

P6 Precedence of exports with explicitly defined structures by the standard

Precedence over the user-defined location records according to P4 have explicitly defined tags subordinated to tag PLAC according GEDCOM standard as well as the by FORM defined superior units. Whenever the data fields are available in the program, these tags must be exported directly subordinated to PLAC. In addition, it is recommended to provide as far as the program provides these data field the GOV code also to subordinate to PLAC to allow a receiving program without location record during import to get the GOV code. By this the calling of a place with location record is as follows:

n PLAC place, county/district, state, country
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>@

Unless FORM is already defined in the header of the file ( according to P2 ), the line with the tag FORM subordinated to PLAC is omitted. Since these calls recurring for multiple occurrence of the place, for the <<NOTE_STRUCTUREs>> the use of NOTE records is recommended.

It is permissible, in an optional export, to deviate from the standard export by waiving the output of the information for every call of PLAC, or perform this export only at the first occurrence of the location. The user should be informed, if he selects that option, that this setting leads to increased information loss in receiving programs that do not operate with location records.

P7 Formalization: Admittance of LOCATION_RECORD in the Definition of RECORD

In the definition of RECORD in GEDCOM Standard 5.5.1 the location record <<LOCATION_RECORD>> is added as follows:

   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}
   ]

P8 Bürgerort ( Place of Citizenship )

For the important place "Place of Citizenship" in Switzerland it is recommended to export the following variant:

1 EVEN
2 TYPE Buergerort
2 PLAC <User input for Buergerort>

The user input for place of citizenship ( e.g. community name plus two-letter abbreviation of the canton out of the official documents ) may not be changed. Further in the standard defined sub-tags to EVEN may be exported too, e.g. DATE, SOUR etc.

During import already existing, different versions should also be supported. They may be transferred to the proposed export version:

1 _BUERGERORT <User input for Buergerort>

or

1 _HEIM <User input for Buergerort>

or

1 FACT
2 TYPE Buergerort
2 PLAC <User input for Buergerort>
Personal tools
GenWiki-internal
In other languages