16,736
edits
Changes
From Gramps
no edit summary
Related Bugs
* {{Bug|688}} (support GedcomELGEDCOM 5.5EL) <== The big one
* {{Bug|10160}} (export of Place with ADDR)
* {{Bug|8699}} (Blank Place when only ADDR is present)
References:
* The Gedcom GEDCOM L PLAC/_LOC agreements ( http://wiki-en.genealogy.net/GEDCOM/PLAC-Tag )
* A list of place types we might want to consider incorporating ( http://gov.genealogy.net/type/list )
Goal: avoid data loss
== Gedcom GEDCOM Import ==
=== Current situation ===
Place Name and Title fields are always stored the same unless otherwise noted.
=== Proposals ===
#) Support Gedcom GEDCOM EL extensions for PLAC._LOC, and a few others related to places.
#) Use only one mechanism for ADDR records. Do away with Place, type 'Details' and, Location Object.
#* It has been suggested that Gramps developers want to deprecate the Location (Alt Location) structure of our place object. In this case the proposal is to convert stand-alone event ADDR to places with Type 'Address'. Events that also have the PLAC tag would create the place from PLAC data, and add an alternate name with the ADDR data. In either case, the ADDR data would be converted to a single line of comma separated elements (if not already available). This could result in some data loss if the ADDR record is not consistent. Also, if both the PLAC and ADDR records had postal codes, the PLAC code would end up in the Gramps place 'code' field, and the ADDR postal code would be on the end of the alt-name.
#) Don't force fit PLAC.FORM records to Location objects, just make appropriate places with type as value from the FORM. Enclosed by hierarchy defined by Gedcom GEDCOM L FORM. Any place types in FORM list after 'country' would not be part of hierarchy. Gedcom GEDCOM L actually says to use first 4 levels, { place, county/district, state, country} but I've got a few files where leading levels are {address, street, city,…}. Postal codes are expected after 'country' level and don't participate in enclosed by hierarchy, but should be recognized if at another position. Have another file with {2 FORM Town, Area code, County, Region, Country, Subdivision} for example, which needs to work.
#: The following Example would create a Gramps place, Named '123 Main', type 'Street' with code '77375' enclosed by
#: another Gramps place, Named 'Houston', type 'City' enclosed by
* Gramps does not support Event references from Place objects. These are proposed to be stored as xrefs in a StyledText Note.
* The potential exists for place names defined in ADDR, PLAC, and _LOC records to be different. If this occurs, then multiple Gramps alt place names will be set for the place. The primary name will be set from the _LOC record.
* The potential exists for certain items to be defined both in the PLAC and _LOC records (where the Gedcom GEDCOM L specification says they should be in the _LOC record). If this occurs, the _LOC versions will take priority.
=== Details ===
In embedded PLAC records the following is in the Gedcom GEDCOM L standard. This proposal suggests that items labeled 'new' be imported by Gramps.
<nowiki>n PLAC <PLACE_NAME> {1:1}
+1 FORM <PLACE_HIERARCHY> {0:1}
+1 _FCTRY <FOKO_STATE_IDENTIFIER> {0:1} New (1,2) Note</nowiki>
1) Since Gramps Places don't have Attributes, I propose that these items be placed in a single Gramps note (one per place (or place reference in the Event)). The note will have the various Gedcom GEDCOM fields and the contents included.
2) If the _LOC is present, these are expected in the _LOC structure, and will be ignored here.
The cross referenced _LOC record is defined below and is entirely new. While these are expected at the end of the Gedcom GEDCOM file per the EL agreement, Gramps can support them at any position.
<nowiki>0 @<XREF:_LOC>@ _LOC
1 NAME <PLACE_NAME> {1:M} Place Name
1 <<CHANGE_DATE>> {0:1}</nowiki>
1) Since Gramps Places don't have Attributes, I propose that these items be placed in a single Gramps note (one per place). The note will have the various Gedcom GEDCOM fields and the contents included. When there are multiple possible similar notes (place name notes, enclosed by notes) the associated place Name or enclosed Gramps_ID (as a styledtext xref) will be included in the local heading.
2)Gramps does not support multiple place types. If more than one type is found, the TYPE and TYPE.DATE will be put in the Note.
6) If more than one Postal code is encountered only the first is stored in the Gramps place code field. Additional encounters are stored in Note.
== Gedcom GEDCOM Export ==
=== Current situation ===
Addresses attached to submitter, persons, repos, etc. are exported as ADDR record.
=== Issues ===
* ADDR structure is not legal GedcomGEDCOM. No first line.
* PLAC.NAME etc. should not depend on automatic title generation setting.
* While exporting ADDR and PLAC is arguably legal, it is redundant.
=== Proposal ===
# Support PLAC.FORM. Use the Gramps enclosure information to create full comma separated PLAC.NAME and PLAC.FORM filled out from the Gramps place type. Postal Code from place code field at end of list when present. PLAC.FORM will be included with each PLAC, NOT in header, since Gramps is not guaranteed to have consistent place types.
# Support PLAC._LOC and _LOC xref. This, while not standard Gedcom GEDCOM is defined by Gedcom GEDCOM L and is legal under standard GedcomGEDCOM. So it should be safe for other programs to import, even if they don't support it. This can encode several Gramps structures as detailed below.
# Drop export of ADDR record.
=== Details ===
=== Questions ===
# Gedcom GEDCOM L recommends that when 'user defined tags' (those that are preceded by an '_') are present, that an explanation of these tags is placed in the header of the exported Gedcom GEDCOM file as a Schema. I was unable to find any example Gedcom GEDCOM files that included this feature for _LOC tag, although I did find some very old Gedcom GEDCOM files with the _SCHEMA tag, mostly exported by FTW vers 2.
#: Do we want to include it for export?
#: Author recommends NOT to include.
#: Gedcom GEDCOM L Schema for the _LOC tag is included below.
#: <nowiki> 0 HEAD
...
#: Could be developed in Gramps master, for release at 5.1 timeframe, or developed as an Addon which would replace current libgedcom.py for 5.0 branch. Or even as a 'bug' for gramps50 branch.
=== Comments ===
Round trip Gedcom GEDCOM in to Gedcom GEDCOM out will not be transparent for all the fields in the Gedcom GEDCOM L _LOC record. Data should not be lost, but some data will get converted to Notes, which would be inconvenient for users.
==See also==
