 | Place Class |
Applicable for: 5.5.5
Extends the base PlaceStructure class with properties specific to the applicable GEDCOM standards.
Inheritance HierarchyPatagames.GedcomNetSdk.PrimitivesContext
Patagames.GedcomNetSdk.StructuresGedcomStructure
Patagames.GedcomNetSdk.StructuresPlaceStructure
Patagames.GedcomNetSdk.Structures.Ver555Place
Namespace: Patagames.GedcomNetSdk.Structures.Ver555
Assembly: Patagames.Gedcom.Net.Sdk (in Patagames.Gedcom.Net.Sdk.dll) Version: 1.0.8
SyntaxThe Place type exposes the following members.
ConstructorsProperties| Name | Description | |
|---|---|---|
 | CustomTags |
Gets the collection of сгыещь tags encountered in this context.
(Inherited from Context) |
| Map | Gets or sets the value specifying the latitudinal and longitudinal coordinates of the place name. |
| Name |
Gets or sets the jurisdictional name of the place where the event took place. Jurisdictions are separated by commas, for example, "Cove, Cache, Utah, USA."
(Inherited from PlaceStructure) |
| Notes |
Gets or sets the collection of notes.
(Inherited from PlaceStructure) |
| PhoneticVariation | Gets or sets the phonetic variation of the place name is written in the same form as was the Name, but phonetically written using the method indicated by the Type value |
| RomanizedVariation | Gets or sets the romanized variation of the place name is written in the same form prescribed for the Name. |
| UnknownTags |
Gets the collection of unknown tags encountered in this context.
(Inherited from Context) |
Methods| Name | Description | |
|---|---|---|
 | ContextClosed |
Called when the context is closed. The default implementation does nothing.
(Inherited from Context) |
| ContextOpened |
Called when a context is opened. The default implementation does nothing.
(Inherited from Context) |
 | Deserialize |
Read data from the parser and deserialize it into the Gedcom.Net SDK class library.
(Inherited from Context) |
| Equals | Determines whether the specified object is equal to the current object. (Inherited from Object) |
| Finalize | Allows an object to try to free resources and perform other cleanup operations before it is reclaimed by garbage collection. (Inherited from Object) |
| GetHashCode | Serves as the default hash function. (Inherited from Object) |
| GetType | Gets the Type of the current instance. (Inherited from Object) |
| GetValueT |
Hets the value and main tags of the specified propName.
(Inherited from Context) |
| MemberwiseClone | Creates a shallow copy of the current Object. (Inherited from Object) |
| PreporcessTag |
Called before tag processing begins. The default implementation does nothing.
(Inherited from Context) |
| ProcessCustomTag |
Add the custom tag into the CustomTags collection.
(Inherited from Context) |
| ProcessUnknownTag |
When overridden, tries to process a tag that cannot be processed by the GEDCOM mechanism, because the tag is unknown or encountered in an unexpected context.
(Inherited from Context) |
| Serialize |
Seserialize the Gedcom.Net SDK class library and write data to the composer.
(Inherited from Context) |
| ToString | Returns a string that represents the current object. (Inherited from Object) |
RemarksThe PhoneticVariation of the place name is written in the same form as was the Name, but phonetically written using the method indicated by the subordinate Type value, for example if hiragana was used to provide a reading of a a name written in kanji, then the Type value would indicate kana.
The RomanizedVariation of the place name is written in the same form prescribed for the Name. The method used to romanize the name is indicated by the subordinate Type, for example if romaji was used to provide a reading of a place name written in kanji, then the Type would indicate ‘romaji’.
Place Record Design Error
The FamilySearch GEDCOM 5.5.1 specification added the place coordinates, the Latitude and Longitude, as subrecords of the Place. That sounds reasonable and logical, there is no better place(pun intended) to put these. However, the Place is itself a subrecord, and a typical GEDCOM file contains the same place names over and over again.
The GEDCOM 5.5.1 design seems to expect that GEDCOM writers, when place coordinates are known, include those coordinates with each occurrence of each place name, thus bloating GEDCOM files even more than frequently repeated place names already do. Worse than that, GEDCOM readers that come across the same place name more than once, may come across conflicting coordinates, and cannot resolve that by keeping all the different ones; the Place allows just one set of coordinates.
Top-Level Place Record
Genealogy applications developers have long desired the introduction of a top-level place record, and the introduction of place coordinates in GEDCOM 5.5.1 made a top-level place record a practical necessity, yet it was still not included.
Top-Level _PLAC Record
Several developers have addressed this design error by introducing a top-level _PLAC custom tag, and do not record place coordinates within Place, but only within _PLAC records. Different genealogy software developers use different top-level _PLAC records, but still match Place with those _PLAC records the same way: a Place and _PLAC record match each other if they contain exactly the same place name string.
Top-Level _LOC Record
Several German software developers created a collective set of extensions called GEDCOM EL(Extended Locations). The GEDCOM EL extension were originally created for GEDCOM 5.5, but are also used with GEDCOM 5.5.1. GEDCOM EL uses a top-level _LOC record.
See Also