Jump to content


Photo

"Y" in Death Location


  • Please log in to reply
7 replies to this topic

#1 Fred H Held

Fred H Held

    New Member

  • Members
  • Pip
  • 2 posts

Posted 09 February 2014 - 12:37 PM

Why does RootsMagic add an "Y" to the death location of GEDCOM exports, when there is no death date. How can I stop this (stupid) practice.

#2 Alfred

Alfred

    Advanced Member

  • Members
  • PipPipPip
  • 5734 posts

Posted 09 February 2014 - 01:39 PM

Death --- Yes

The importing program must interpret that it is a location rather than an indicaton that the person is no longer living.
Alfred

#3 Fred H Held

Fred H Held

    New Member

  • Members
  • Pip
  • 2 posts

Posted 09 February 2014 - 05:45 PM

In any case, whether it is a Dead = yes or otherwise it is stupid. The absence of the death date and the year of birth is enough to know whether a person is dead or not. How do I get rid of it, short of manually editing the GEDCOM.

#4 Alfred

Alfred

    Advanced Member

  • Members
  • PipPipPip
  • 5734 posts

Posted 09 February 2014 - 07:55 PM

I would do a backup first, just in case my idea is all wet.

Try Search - Search and replace - Field to search = Places.
Search for -- Y
Replace with --

That is a Y in the search for field and leave the replace with field blank.

It might work. :rolleyes:

I would check the Match Case box and go through one at a time to be sure it doesn't nock out the Y in names like New York.

------------ adeded ---------

YES, you will have to click the SKIP button on most of the finds.
Alfred

#5 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6429 posts

Posted 09 February 2014 - 10:01 PM

Is it possible that you are misreading the GEDCOM file. When RM export includes "Extra details (RM specific)" (checkbox in GEDCOM Export settings), it outputs Event Definitions like this one for the Death fact type:
0 _EVDEF DEAT
1 TYPE P
1 TITL Death
1 ABBR Death
1 SENT [person] died< [Desc]>< [Date]>< [person:Age]>< [PlaceDetails]>< [Place
2 CONC ]>.
1 ROLE Witness
2 SENT [ThisPerson] witnessed the death of [person]< [Date]>< [PlaceDetails]>< [
3 CONC Place]>.
1 PLAC Y
1 DATE Y
1 DESC Y
This is not the Death event for a person; rather, it is the definition of the Death fact type recognizable pretty well only by RootsMagic software. The Y beside PLAC, DATE, DESC signifies that these fields are enabled for this fact type. "N" would signify the field is disabled.

Try an export with that checkbox unchecked and see if you can find any lines like "2 PLAC Y" within a block starting "1 DEAT" (the block ends with a line beginning with 0 or 1).

Tom user of RM7630 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#6 Alfred

Alfred

    Advanced Member

  • Members
  • PipPipPip
  • 5734 posts

Posted 09 February 2014 - 11:11 PM

For individuals:

The GEDCOM file exports: "1 DEAT Y"
If the living flag is unchecked and there is no death fact.

It exports just: "1 DEAT"
If there is a death fact.
If there are dates and/of places there are other tags: "2 CAUS", "2 _SENT", "2 DATE", "2 _SDAT", "2 PLAC" and "2 ADDR"

The two with the leading underline are ommotted if you do not include the RM specific things in the exported GEDCOM.

Otherwise the death area is about the same.
Alfred

#7 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6429 posts

Posted 10 February 2014 - 09:44 AM

That clarifies it, Alfred, and a quick check of the GEDCOM 5.5.1 draft spec confirms that RootsMagic is exporting the Death fact correctly when the Living flag is unset and there is no Death or Burial event entered. Therefore, the importing program is misinterpreting it and is at fault.

The occurrence of an event is asserted by the presence of either a DATE tag and value or a PLACe
tag and value in the event structure. When neither the date value nor the place value are known then
a Y(es) value on the parent event tag line is required to assert that the event happened. For example
each of the following GEDCOM structures assert that a death happened:
1 DEAT Y
1 DEAT
2 DATE 2 OCT 1937
1 DEAT
2 PLAC Cove, Cache, Utah

! All GEDCOM lines have either a value or a pointer unless the line contains subordinate
GEDCOM lines. In other words the presence of a level number and a tag alone should not be
used to assert data (i.e. 1 DEAT Y should be used to imply a death known to have happened but
date and place are unknown, not 1 DEAT ). The Lineage-linked form does not allow a
GEDCOM line with both a value and a pointer on the same line.

http://wiki.webtrees...en/Ged551-5.pdf

While 5.5.1 was never elevated to a standard, the 5.5 GEDCOM Standard included the same specifications:

The presence of a DATE tag and/or PLACe tag makes the assertion of when and/or where the event
took place, and therefore that the event did happen. The absence of both of these tags require a
Y(es) value on the parent TAG line to assert that the event happened. Using this convention protects
GEDCOM processors which may remove (prune) lines that have no value and no subordinate lines.
It also allows a note or source to be attached to the event context without implying that the event
occurred.

http://frank.vancaen...te/gedcom55.pdf pg 32

Tom user of RM7630 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#8 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6429 posts

Posted 23 August 2014 - 09:15 AM

That clarifies it, Alfred, and a quick check of the GEDCOM 5.5.1 draft spec confirms that RootsMagic is exporting the Death fact correctly when the Living flag is unset and there is no Death or Burial event entered. Therefore, the importing program is misinterpreting it and is at fault.

The reciprocal conclusion, based on recent investigation of importing TMG9 GEDCOM, is that RootsMagic dishonours the GEDCOM specification in that it does not import a Citation or Note for a parent DEATh tag having a Y(es) value. It ignores all child tags of n DEAT Y and merely lists them without line number or explanation in the .LST file. All it does is clear its Living flag. When there is a child tag of 1 DEAT Y, RootsMagic should not only clear the Living flag but also add the Death fact with the values from the child tags. 

 

Until this issue is cleared, anyone importing a GEDCOM from TMG and likely other programs would be wise to inspect it for the presence of "1 DEAT Y" lines immediately followed by 1 or more lines beginning with 2 and replace it with "1 DEAT". 


Tom user of RM7630 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.