* Rootsmagic->Family Historian

[BakerJL75]

I know there are at least two of us moving from Rootsmagic to Family Historian. I thought I would start this thread to make it easier to communicate about those types of problems. Perhaps we can help each other. And of course, if any other forum member wants to jump in with comments, that would be great too.

Jackie

[tatewise]

I have moved this posting to the Importing and Exporting forum that is more appropriate.

Remember there is Knowledge Base Importing to Family Historian advice for Import from RootsMagic (RM) that would benefit from your experiences.

Don't overlook Handling Uncategorised Data Fields and Compendium of Conversion Plugins.

[BakerJL75]

Thank you. Should have thought of that.

[Robert Jacobs]

I too am moving from RootsMagic. The import went smoothly with one exception: FH7 successfully handled all of my RM facts except for Residence(fam). That data comes in as undefined, but when I attempt to define the fact, the new definition does not associate to the data. Instead, a new undefined fact (which is associated to the data) is generated by Family Historian. I've filed a support ticket for that. If I recollect correctly, Mike Tate told me that the problem is a bug in FH7 which will eventually be resolved.

Other than that, a lot of work remains. I have to adjust the FH7 sentence templates to reflect my sometimes idiosyncratic RootsMagic data entries.

My preferred output is to GedSite as I maintain a family web site. The Export GEDCOM File plug-in allows me to output GEDCOMs from FH7 which GedSite can accept.

Robert
Web site at https://genarchives.com/NineGenerations/up/index.htm

[LeslieP]

I also will be converting from RM to FH and very much appreciate all of the work already done here in the FHUG to help, and anything people discover now.

I'd already been gradually converting my Res (fam) facts to regular Res facts, but will make sure to do so completely before I do the conversion. I remember when I converted from TMG to RM that the time spent in TMG cleaning things up with an eye towards the RM import process was time very well spent

[tatewise]

Leslie, it may not be necessary to convert each Family Residence to a pair of Individual Residence facts by hand.
FH should eventually support Family Residence and it is likely a Plugin will get written to perform that conversion, so that exporting to GEDCOM 5.5 based products will work.

[Robert Jacobs]

Thank you, Mike. That will be a great help — I think I have more than 400 Residence(fam) facts. To convert them manually, even in the age of the coronavirus, is not an inviting prospect.

[BakerJL75]

I'd already been gradually converting my Res (fam) facts to regular Res facts, but will make sure to do so completely before I do the conversion. I remember when I converted from TMG to RM that the time spent in TMG cleaning things up with an eye towards the RM import process was time very well spent

If you are not familiar with it, Tom Holden has a little program, RMTRIX that will help with that. You will have to decide if your technical skills are a good fit for it. Make absolutely sure you have a backup in case you don't like it. Make sure you read the instructions. https://sqlitetoolsforrootsmagic.com/bu ... es-rmtrix/. Also make sure you read about RMNOCASE at https://sqlitetoolsforrootsmagic.com/?s=rmnocase And finally, this article is quite helpful: https://sqlitetoolsforrootsmagic.com/?s=rmnocase

[tatewise]

I read somewhere that the latest RM8 uses a different database structure from RM7 and so maybe RMTRIX won't work.
Does anyone know for sure?

[BakerJL75]

I read somewhere that the latest RM8 uses a different database structure from RM7 and so maybe RMTRIX won't work.
Does anyone know for sure?

Tom recently talked about it and it sounds like many queries are not going to work. I assumed she was using RM7, but assuming is rarely a good thing to do.

[Jim Byram]

What I did with the RM family Residence tags was to change them from 1 RESI to 1 EVEN 2 TYPE Residence (fam) in the GEDCOM before import.

I extracted the family records section from the GEDCOM, did a global search and replace in LibreOffice Writer, and then added the family records section back into the GEDCOM.

You also need to edit the hidden fact definition in FH so that the data will display.

[tatewise]

Jim, I am not sure that is the best way forward.
What will you do when FH supports the genuine Family Residence facts, which it must do to be GEDCOM 5.5.1 compliant.
What will you do when the Plugin to migrate genuine Family Residence facts to Individual Residence facts is available?
For many, editing the GEDCOM file is fraught with risks if unsure of what they are doing

[Jim Byram]

Mike,

I understand that FH7 should support 1 RESI tags in the family records section. This was just a fix for now while I'm working through the other issues in the RM GEDCOM regarding the FH import.

I would prefer to retain the family Residence tags as family tags.

At the moment, the RM8 GEDCOM doesn't appear to have changed in any significant way from the RM7 GEDCOM although I haven't done a DIFF. RM8 has dropped the RM version number for the moment.

I won't do a final import until FH7 stabilizes a bit.

Jim

[BakerJL75]

In general, my import from RM didn't go too badly. But almost every fact and source I use is custom, so I have a lot of work to do.

Facts won't take an enormous about of time as I've gotten pretty decent at writing sentences in FH7.

I'm debating about my sources. They were templated in RM and I love templates so I would like to convert them, but it's going to have to be a slow process. And in general, I'm a lumper, but debating the merits of lumping vs. spliting in FH7. Currently the citations print in an individual report fairly well, but like Robert, I use GedSite. I need to wait and see how they do with GedSite after John Cardinal is able to work on it. He has stated he hopes that will be this month. If/when Calico Pie addresses the <para> and <br> issue in their reports I'll take a look at their website generator. But if I can't break up paragraphs, then I'll definitely stick with GedSite.

I also need to clean up my place list. After some reading, I have decided to use a 6 column place arrangement without the ADDRESS field, but I need to go through and add some commas here and there. Mike, you mentioned working on your places plugin to convert it for FH7, so I'll definitely wait until that is done.

Many (many) moons ago I coded, but not sure how long it would take me to learn to write a custom plugin for some of my more common source templates. They are consistent, so I envision using string functions to break up the data and then write it into a template (or citation maybe, not even sure at this point). I'm sure if I look into it, it won't be nearly that simple, not to mention learning lua and how to write plugins. And I expect every RM source template would need a different plugin arrangement.

Anyway, I'm about 95% sure I'm going to switch and I'm glad to 'meet' all of you.

[LeslieP]

I've wanted my Residence (fam) to be Residence (individual) facts on the HOH with everyone else as witnesses for quite some time, so this is necessary cleanup, really. It's not that I want to change from shared to individual, it's that I want to change from "family" to individual. I'm 100% addicted to shared facts, have been so ever since my TMG days!

Really just based on the way TNG displays individual and family sections and facts on the web I decided to move away from any and all "Family" type facts other than marriage and divorce. Just a personal preference.

I did look at using the sqlitetools for this and have used it for a few things in the past, but it's so very cumbersome, convoluted, and not at all user friendly, it's not something I want to spend my time on any more.

Also, yes, the RM8 database structure IS different from current RM7, but RM8 is only now at "public beta" and no one should be using it for their real data. It was the public beta release of RM8 that finally confirmed to me that I will need to convert from RM to FH.

Thanks for all the great replies and assistance - great and helpful community here!

[BakerJL75]

It's that I want to change from "family" to individual.

Sorry. It seems my brain went on a holiday when I read this.

[LeslieP]

I am finding that a GEDCOM that includes the RM specific details is superior to one without. Just at the beginning of my testing, but I very much want my places to have the notes, images, and lat/long from RM to import into FH. That is only possible via GEDCOM that includes the RM specific information, and it seems to work just fine, putting all the data in the right spots.

Is there some reason for the recommendation in the knowledge base that says we should exclude the RM specific data?

[tatewise]

Thank you for the insight, Leslie.

The advice in the Knowledge Base is based largely on user feedback, and may become obsolete when the product (RM in this case) is updated or FH is updated.

I have performed a similar GEDCOM export from RM and import to both FH V6 and FH V7 with & without Extra details.

Both did import Place records and details including Lat/Longitude.
However, the Lat/Longitude could probably mostly be automatically recreated by using the FH Map Window.
FH V6 did NOT import linked Media unscathed and would need further work to fix that.
FH V7 did import the linked Media although it lost the Title en-route.

On the downside, a Project of only 122 Individuals had 2,300 UDF in FH V6 and 2,000 in FH V7 that need clearing up.
Whereas without RM Extra details the number of UDF drop to 400 and 130 respectively, the reduction of nearly 300 in FH V7 versus FH V6 is mostly due to Sort Dates being accepted.

So it becomes a value judgement of whether the benefit of Place details outweighs the UDF clear up effort.
If you have few Notes and Media attached to Place records then including RM Extra details may not be worth it.

The benefits of including RM Extra details have improved with FH V7 and the UDF reduced, so the KB advice may need updating, but the impact of UDF also needs to be mentioned.

[LeslieP]

Thanks for that insight Mike, that gave me other things to look at, and for. I am using FH7 trial version (cash flow issues), and trying multiple export/import things so I can clean up on RM as much as possible before doing "the real one" once I purchase the program.

A GEDCOM without RM specifics won't include the Family Search ID numbers that I really need, so I'm going to have to use the RM specific options and deal with whatever UDF situation I end up with. Fortunately, it seems that FH7 handles the RM place information perfectly well, no UDF issues whatsoever.

The GEDCOM section:

Code: Select all

0 _PLAC Arlington Memory Gardens, Oklahoma City, Oklahoma, Oklahoma, United States
1 NOTE Cemetery gates are open to visitors every day of the year from 8:00 a.m
2 CONC . until dusk.
1 MAP
2 LATI N35.5057972
2 LONG W97.3925028
1 OBJE
2 FILE P:\Genealogy\photos\gravestones\ZZ-Cem-Arlington Memory Gardens.jpg
2 FORM jpg
2 _TYPE PHOTO
2 _SCBK Y
2 _PRIM Y

The resulting Place Record, data isn't even marked as UDF - so great! And I checked and it maps perfectly as well.


The GEDCOM without RM specific information doesn't have "0 _PLAC" records, and at least for me, has no lat/long data at all, much less media or notes. That would be a really catastrophic loss to make up for, at least for me. As long as it's not gonna break anything, I'm moving forward with the RM specific flavor of GEDCOM.

I must confess, more than once I've nearly gotten a little tear in my eye at how wonderfully CAPABLE this software is. Truly outstanding.

[tatewise]

If you check the RM exported GEDCOM, each OBJE tag will typically have a subsidiary FILE, FORM & TITL tag.
They are known as Local Media Objects and FH converts them to Media Records but loses the TITL tag & value.
You could report that fault to Calico Pie via http://www.calico-pie.com/osticket/open.php.

Your example does not have a TITL tag. Is that because you don't add titles, or is that example an exception?

Which RM Extra data UDF fields do you believe hold the FamilySearch ID number?
Is it the _UID tags? If so, then they are included even when RM Extra data is excluded.
Their data value is a long hexadecimal number such as C2198EB34F83463C8C4203F9D523D9D7E202

However, I am impressed with the way FH V7 converts RM Place records into FH Place records that use a different format.

[LeslieP]

I don't have any captions, descriptions, dates, or reference numbers on any of my media in RM. (That's the name of the fields in the RM software), so the gedcom is accurate there.

On the individuals, the Family Search ID number is in the _FSFTID field. I assume the _AMTID is the Ancestry Member Tree ID.

Code: Select all

0 @I216@ INDI
1 NAME Samuel Scott /Riffle/
2 GIVN Samuel Scott
2 SURN Riffle
1 SEX M
1 _UID 31A61520FADC46E5B5D262D0E1B145BE5B26
1 _FSFTID LW8F-TS8
1 _AMTID 342020184130:1030:152337908

HOLY MOLY! Just discovered that the GEDCOM import from RM (with RM specifics enabled) also brings in my sort dates!

I've used sort dates from the very beginning of my genealogy life (thanks TMG!). FH7 with the combination of "Normal Time" and Sort Dates is truly the solution I've been looking for for ages. Did not expect that with this very first intro of sort dates that it would import them from RM. But it does. WOOHOO!!!!

Gedcom:

Code: Select all

1 BIRT
2 DATE 1882
2 _SDATE 1 JAN 1882

With NO effort on my part...


WOW!!!!

I'm making notes of all of these things as I discover them, perhaps in a week or two I'll summarize what I've discovered and post it in some rational fashion so that the KB can be updated for other RM to FH folks. This really is that most surprising of things - a software package that gets MORE amazing the more I learn.

[tatewise]

If you did have Captions on the RM Media then they would not get imported to FH as Titles.

I don't have _FSFTID or _AMTID fields in my RM data, so that is where users add value to the advice.

Yes, Sort Dates are a useful new feature in FH V7 once CP got them implemented correctly.

[BakerJL75]

I'm making notes of all of these things as I discover them, perhaps in a week or two I'll summarize what I've discovered and post it in some rational fashion so that the KB can be updated for other RM to FH folks. This really is that most surprising of things - a software package that gets MORE amazing the more I learn.

Thank you for taking the time to post your finds. I'm following along and learning too. And yes, I think FH7 is amazing too. Going to convert regardless of how much work it takes. And as I learn more and discover plugins, it seems it will be much less work.

[postalcae]

I am also going to make the move to FH from RM this year. I am going to take my time in doing the work.

First is to learn FH to understand how to do "daily work". I hope an update the the FH6 book is soon on the way.

Second is to determine what pre-work needs to be done in RM and what post work will be done in FH.

This discussion will help in that and I can share what I hope to find.

[Jim Byram]

v7.0.2.0 - Added a fact definition for the “Residence (family)” fact (new in GEDCOM 5.5.1).

This fixes the import of family resident tags from the RootsMagic GEDCOM.