Jump to content


Photo

Bug in Gedcom export


  • Please log in to reply
10 replies to this topic

#1 Chris te Raa

Chris te Raa

    New Member

  • Members
  • Pip
  • 2 posts

Posted 13 October 2014 - 12:15 PM

I'm using RootsMagic version 6.3.3.2. I found a bug. I imported in Rootsmagic a Gedcom file made by PAF with the lines:

1 NAME Jan /Olthaar/
2 SURN Olthaar
2 GIVN Jan
2 _AKA Jan Hemsinck
 

The tag _AKA is a alias from the person in "1 NAME Jan /Olthaar/".

 

After the export from RootsMagic to a Gedcom file I got:

1 NAME Jan /Olthaar/
2 GIVN Jan
2 SURN Olthaar
1 NAME Jan /Hemsinck/
2 GIVN Jan
2 SURN Hemsinck
 

The tagname _AKA is replaced bij NAME. It isn't no longer a sublevel but on the same level as the first NAME tag.

 

I use this Gedcom file for creating webpages. This error causes unwanted and unpleasant errors in my web-pages. I found a workaround but it would be nice if in a future version this problem has been solved.

 

 



#2 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6448 posts

Posted 13 October 2014 - 05:25 PM

_AKA is a custom GEDCOM tag. Custom tags do not transfer readily between different softwares. RootsMagic apparently recognized it as a name and imported it to its Alternate Name fact type. RootsMagic then exports Alternate Names as per the GEDCOM standard. While it is exported as a NAME tag and at level 1, GEDCOM also says that the first of these NAME values is the Primary name; the rest are secondary or alternate.

So, in effect, you are asking RootsMagic to go off-standard to match the proprietary behaviour of some other software on which your processing for web pages is dependent. Perhaps it is more realistic that the processing for web pages should be revised to support standard GEDCOM in addition to proprietary custom GEDCOM.

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.


#3 Chris te Raa

Chris te Raa

    New Member

  • Members
  • Pip
  • 2 posts

Posted 14 October 2014 - 12:51 PM

Thank you very much for the respons.

My problem is not my own written software to produce html-files, I can change that any time the way I want. I will change it the way you suggest: all used surnames on the same level. That means that all the person's surnames become the same weight.

I have a lot to do with dutch farmers between 1600 and 1800. There were no fixed surnames. Mostly they used as surname the name of the farm where they were living. That was the surname too they used when they baptized a child. So I have ancestors who used four or more surnames. I wrote them in the _AKA tag par example: Janna /Hemsink/te Raa/Reimelink/Hulshof. Also one given name and four surnames. That was at least one slash too much for RootsMagic to import. Rootsmagic interpreted the string as given name + surname + suffix, what was wrong in this case.

 

I must agree now it isn't a real bug. If RootsMagic should have asked me during the import: "Shall I interprete _AKA tags as names or as strings?", I had choosen for strings. Now I must inspect over 46,000 records for a wrong import of the _AKA tag.

 



#4 KenCRoy

KenCRoy

    Advanced Member

  • Members
  • PipPipPip
  • 316 posts

Posted 15 October 2014 - 05:36 AM


 

I must agree now it isn't a real bug. If RootsMagic should have asked me during the import: "Shall I interprete _AKA tags as names or as strings?", I had choosen for strings. Now I must inspect over 46,000 records for a wrong import of the _AKA tag.

 

 

If RootsMagic intends to replace PAF then it should adjust some of its Import behavior accordingly:

 

  • _AKA is one issue
  • births and deaths on the same date is another issue -  RM should set the sort descriminator on import.  It is not always easy to find every occurrence where Death displays before Birth when you are importing 25,000 persons
  • publication source citations is another issue, since RM imports it as free format source some of the publication information formatting is lost on a subsequent export to load the database into TNG


#5 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3982 posts

Posted 15 October 2014 - 06:57 AM

 

 

If RootsMagic intends to replace PAF then it should adjust some of its Import behavior accordingly:

 

  •  
  • births and deaths on the same date is another issue -  RM should set the sort descriminator on import.  It is not always easy to find every occurrence where Death displays before Birth when you are importing 25,000 persons
  •  

 

 

As has been discussed over and over and over again on these forums, many RM users (including myself) have argued that a sort discriminator should not even be necessary for same date birth/death. Rather, the fact type should be used as a tie breaker, automatically placing birth in front of death when the dates are the same. The RM developers apparently don't agree, suggesting that this approach would limit the flexibility of RM. It's hard to understand this viewpoint, given that users could still set death dates in front of birth dates if they wanted to, and given that users could still apply sort dates if they wanted to.

 

This problem is already in the tracking system as a sorting issue. It shouldn't have to become an import issue.

 

Jerry



#6 KenCRoy

KenCRoy

    Advanced Member

  • Members
  • PipPipPip
  • 316 posts

Posted 17 October 2014 - 05:57 AM

 

As has been discussed over and over and over again on these forums, many RM users (including myself) have argued that a sort discriminator should not even be necessary for same date birth/death. Rather, the fact type should be used as a tie breaker, automatically placing birth in front of death when the dates are the same. The RM developers apparently don't agree, suggesting that this approach would limit the flexibility of RM. It's hard to understand this viewpoint, given that users could still set death dates in front of birth dates if they wanted to, and given that users could still apply sort dates if they wanted to.

 

This problem is already in the tracking system as a sorting issue. It shouldn't have to become an import issue.

 

Jerry

 

But it is an Import issue when RootsMagic imports the PAF data and does not provide what the PAF users have long been accustomed to -- having standard events displayed in specific order.  As a result, I continue to use PAF for my database since it is still the quickest and easiest data entry program.   :)



#7 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 17 October 2014 - 07:51 AM

RootsMagic has no obligation to become a clone of PAF, TMG, Legacy, Fwmily Tree Maker or any other program whatever users coming from other programs expectations are.

Just like no other program has the obligation to become a clone of Rootsamagic.

#8 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6448 posts

Posted 17 October 2014 - 11:08 AM

A program that combined the best features of all of those would be a winner!

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.


#9 RonB

RonB

    Advanced Member

  • Members
  • PipPipPip
  • 63 posts

Posted 17 October 2014 - 07:47 PM

RootsMagic has no obligation to become a clone of PAF, TMG, Legacy, Fwmily Tree Maker or any other program whatever users coming from other programs expectations are.

Just like no other program has the obligation to become a clone of Rootsamagic.

Laura,

 

I could not agree with you more.  I don't understand the reasoning behind why folks want to transfer from another program (TMG has been discontinued, but can still be used) to RM, then, they "lobby" to have RootsMagic start adding all the features they liked in their original program.  As I had previously stated, if I wanted RM to be just like TMG, then I would have been using TMG.  



#10 hlein

hlein

    Member

  • Members
  • PipPip
  • 24 posts

Posted 18 October 2014 - 12:56 AM

RonB,

 

it is not making RM a clone of TMG. It is about adding similar features (that TMG users do use often) that can be used by RM users, too, and give them an added value. This would be "extensions" and nobody would be forced to use them.


Regards

Helmut


#11 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3557 posts

Posted 18 October 2014 - 03:53 AM

The tagname _AKA is replaced bij NAME. It isn't no longer a sublevel but on the same level as the first NAME tag.

 

 

 

 

I am not quite sure of the issue here, the AKA is preserved in Rootsmagic under the AKA alternate name tag.

 

The line the original posted left of his RM gedcom export was the next line which read "2 TYPE aka"

 

1 NAME Jan /Hemsinck/
2 GIVN Jan
2 SURN Hemsinck
2 TYPE aka

 

That can also say Married, Other etc so defining the Alternate name Type.


Keeping ones customers and their important views at a distance is never a good approach

 

User of Family Historian 7.0.3, Rootsmagic 7.6.5

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root