30 replies to this topic

[Vyger]

From my point of view this question has two answers, although neither is too good!

 

Firstly thank you KFN for a very informative post, I am no Gedcom expert but I do know RM uses the ADDR tag for Place Details and that they do travel back and forth to my second program. I have felt that I wanted to put some more meat on the bones of my ineptitude statement, I was really saying I don't hold back embracing the features of RM simply because I might have a useful little freeware program which does not yet understand or work well with Place Details or Shared Events, should we also avoid the Standardized and Abbreviated Place fields simply as they are lost on Gedcom transfer or should we trust Rootsmagic will find a way to overcome this problem and preserve our hard meticulous work? I still prefer the later approach. I don't know why USA keep moving there fence posts but it's a problem we have to live with in all Countries and from a research point of view I believe Proximity reporting calculated from the Latitude and Longitude to both txt reports and Mapping is the only answer to understanding cross border, State or County boundaries and changing divisions over time.

 

It has saddened me to see user after user back away from various such supposed enhancements simply because RM has not finished these features to a standard users expect but instead move on to something else. If users do not use these features and enhancements due to inbuilt limitations then they are not enhancements fit for the purpose and are not value added, I do hope RM8 development takes a different direction. Sadly due to these ongoing frustrations RM is now my secondary program but I will still watch RM8 evolution and feedback with great interest.

 

Out of interest I exported a family of 3 using Shared Events, Place Details and Media attachments to my other program to recheck for losses. There were no exceptions but several Info lines, I will post a copy of the repost at the end of this post for the information of others, proprietary information has been removed. The transfer back to RM created some exceptions regarding Place Details Media attachment, it's not something I'm going to worry about as my only tie to RM now is the management of my geographic and local histories database.

 

Received information from RM to second program;

 

 

Same information as above without edits received back from second program Gedcom to Rootsmagic;

 

 

 

 

Information file generated by second program from RM Gedcom import; (RM Fact definitions striped)

 

l.10 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "3  WWW www.RootsMagic.com"

Record Type=Individual. Gedcom Id=I1. Record Number=1.
l.34 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "3  MAP "
l.35 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "4  LATI N54.3280556"
l.36 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "4  LONG W6.3925000"
l.37 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "3  NOTE The Irish name for Mullaghglass is Mullach glas"
l.38 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "3  OBJE "
l.39 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "4  _FILE D:\My Documents\Genealogy\Places\Armagh\mullaghglass-townland-ballymore-parish-armagh.PNG"
l.40 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "4  FORM PNG"

Record Type=Individual. Gedcom Id=I2. Record Number=2.
l.63 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2  TYPE married"
l.64 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2  DATE BEF 1883"

Record Type=Place. Gedcom Id=<none>. Record Number=2.
l.187 - INFO ONLY: Converted invalid GEDCOM tag to valid GEDCOM extension by adding underscore: "1  _OBJE "
l.188 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2  _FILE D:\My Documents\Genealogy\Places\Armagh\ballymore-parish-armagh.PNG"
l.189 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2  FORM PNG"
l.193 - INFO ONLY: Converted invalid GEDCOM tag to valid GEDCOM extension by adding underscore: "1  _OBJE "
l.194 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2  _FILE D:\My Documents\Genealogy\Places\Armagh\ballymore-parish-armagh.PNG"
l.195 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2  FORM PNG"
l.199 - INFO ONLY: Converted invalid GEDCOM tag to valid GEDCOM extension by adding underscore: "1  _OBJE "
l.200 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2  _FILE D:\My Documents\Genealogy\Places\Armagh\ballymore-parish-armagh.PNG"
l.201 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2  FORM PNG"
l.205 - INFO ONLY: Converted invalid GEDCOM tag to valid GEDCOM extension by adding underscore: "1  _OBJE "
l.206 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2  _FILE D:\My Documents\Genealogy\Places\Armagh\ballymore-parish-armagh.PNG"
l.207 - INFO ONLY: Loaded uncategorised data (non-GEDCOM): "2  FORM PNG"

[KFN]

IF   <= That is a big "if"  

IF a family historian thinks that they will stay with the software they are currently using 'forever', then I'm happy for them.  They are either a short term "Historian", probably leaving after they copy other people's work from A.com and adding a little of their own, or unknowingly a passenger on the Titanic on its maiden voyage.  All programs reach a point where they are no longer relevant or the company looses interest and stops producing the program.  And, continuing the Titanic metaphor, they are on a ship with not enough life boats or life jackets and the waters can be very cold!  It was not too many years ago that FTM almost ended distribution and so many people were worried about where they would end up and how much they would lose, other software is also having the same issue with potential or real 'end of life'.

At present the only life boat is GEDCOM for most software, yet I've talk to representatives of other software programs that will tell me that family historians just don't care about GEDCOM so why should we do better.  This attitude from this company tells me that they are happy to lock their customers into their software without a worry about them needing to get to a different platform.  This same company has also locked down their database so no-one can even get at the underlying data to bridge to another program.

I worked in the software industry for 30 plus years and in that time have seen a lot of programs, large and small, on the mainframe, AS/400, IBM-PC and other platforms come and go.  I've written bridge programs to convert flat files to database and other programs to move data from one database architecture to another database architecture.  I seen a lot and this will continue into the future as innovation continues.  GEDCOM is trying to innovate, I'll be the first to say that GEDCOM does need revision, but I reject the notion that it is old (like I've had people tell me here and on other forums) it is misunderstood by the masses and the software companies.  But as I said above some software companies are happy to lock their customers into their UI without thought about interoperability.
 

 

Vyger said: "I have felt that I wanted to put some more meat on the bones of my ineptitude statement, I was really saying I don't hold back embracing the features of RM simply because I might have a useful little freeware program which does not yet understand or work well with Place Details or Shared Events, should we also avoid the Standardized and Abbreviated Place fields simply as they are lost on Gedcom transfer or should we trust Rootsmagic will find a way to overcome this problem and preserve our hard meticulous work?"

"useful little freeware program" not all programs fit into this remark, besides why should that "freeware" or a paid program follow the whims of a single program when there is a standard that if followed can solve many issues that Genealogists have, and if those same programs/companies got together and updated the GEDCOM standard to include mutually beneficial tags then everyone can win.  But these companies are very happy to lock in their user base (who does not even know GEDCOM exists, let alone care what software supports GEDCOM correctly).  You are lucky that you have found a program that at present can read a GEDCOM generated by RM without data loss, but that may not be true in the future, you new program may not provide a life boat when you find some other program that you like better, or when they lose interest in producing software.
 

 

"should we also avoid the Standardized and Abbreviated Place fields"

I've enter this data into my copy of RM7 and don't see it put into the GEDCOM produced.  I would love to see the GEDCOM that is produced to support Shared Events and the previously mentioned place fields! 

The real kick in the head with RM7 is that they totally messed up the GEDCOM they did produce.

This is the output from my test.
1 BIRT
2 DATE 29 MAR 1909
2 PLAC Some Hospital, Happy Town, Some County, Some State, USA
2 ADDR 666 N. Raven Eye Happy Town, Some State, USA
3 MAP
4 LATI N41.9199722
4 LONG E87.7932222
3 NOTE This is another place note
2 NOTE A birth note
2 SOUR @S171@
3 PAGE page #99
 

1) The MAP tag is under the ADDR tag.  This is wrong and bad GEDCOM.  The MAP tag is not under of the ADDR tag it is under of the PLAC tag.
2) The ADDR tag is incorrectly formated which was produced by the Place Detail.  It should be:
    2 ADDR 666 N. Raven Eye
    3 CONT Happy Town, NC
    3 CONT USA    
3) The note entered as a "place note" under the ADDR tag. This is wrong and bad GEDCOM.

The correct and valid GEDCOM v5.5.1 output should be:

1 BIRT
2 DATE 29 MAR 1959
2 PLAC Mary Thompson Hospital, Chicago, Cook County, Illinois, USA
3 MAP
4 LATI N41.9199722
4 LONG E87.7932222
3 NOTE This is another place note
2 ADDR 666 N. Raven Eye
3 CONT Happy Town, NC
3 CONT USA    
2 NOTE A birth note
2 SOUR @S171@
3 PAGE page #99

RM7 claims to be GECOM 5.5.1 but the above proves they are not!
0 HEAD
1 SOUR RootsMagic
2 NAME RootsMagic
2 VERS 7.6.5.0
2 CORP RootsMagic, Inc.
3 ADDR PO Box 495
4 CONT Springville, UT 84663
4 CONT USA
3 PHON 1-800-ROOTSMAGIC
3 WWW www.RootsMagic.com
1 DEST RootsMagic
1 DATE 6 DEC 2020
1 GEDC
2 VERS 5.5.1

 

[Vyger]

You are lucky that you have found a program that at present can read a GEDCOM generated by RM without data loss, but that may not be true in the future, you new program may not provide a life boat when you find some other program that you like better, or when they lose interest in producing software.

 

Thank you again for your informed opinion, I fully understand the advantage of the proprietary traps and wish it wasn't so, one should be able to win a race on ones own merits rather than employing underhand methods, if intentional. However below is what the other company advertises, RM transfer to it seems to be well catered for so I will wait and see what the future brings.

 

"...designed from the ground up to be 100% GEDCOM-compatible and 100% GEDCOM-complete – that is, it can load all GEDCOM 5.5 fields and can save all of its data to the GEDCOM format..."

[KFN]

 

 

that is, it can load all GEDCOM 5.5 fields

GEDCOM 5.5 is not the most current version that some software tries to use.  So this statement makes me laugh.

[lighthouse]

GEDCOM 5.5 is not the most current version that some software tries to use.  So this statement makes me laugh.

So are we talking 5.5.1

And that is a year old

[KFN]

Yes v5.5.1 is the last version that The Church of Jesus Christ of Latter-day Saints released in 1999 (NOTE: it has been claimed that v5.5.1 was released in Nov 2019).  Some consider v5.5.1 only a draft, since that is what it says, but many programs (including RM7) indicate they use the standard and even export GEDCOM with the version set as 5.5.1 in the HEADer.  These same programs don’t actually support the v5.5.1 Standard correctly or in its entirety.

 

Various groups over the last 10 years have made attempts to update the specification with varying degrees of success. With none of them being accepted by the industry as a whole, which I would expect since the industry never accepted any other version of the standard even if their propaganda says the have.

 

So as I indicated above, most serious genealogists are left without a life boat if their software reaches “end of life” or a better product comes along, while casual family historians must be satisfied that they can generate a document that they can present to their relatives at the family reunion.

[Vyger]

GEDCOM 5.5 is not the most current version that some software tries to use.  So this statement makes me laugh.

 

A recent genealogy vendor update stated the following, firstly the export options are very welcome and hopefully beneficial to anyone wishing to switch programs in the future, pity more vendors would not embrace such attempts to allow freedom of data transfer, it remains one big objection to many.

 

 

• New export options. These have been added to accommodate all the new features, so that other applications which do not support xxxxxxxx features, can still import the essential data – especially in relation to word processing features and source template field values.

 

• Version X now supports GEDCOM 5.5.1. GEDCOM is the global standard for shared genealogy data. 5.5.1 was announced in November 2019.

[KFN]

Vyger,

 

While I’m glad to see that they say they support GEDCOM v5.5.1, multiple other programs say they support it as well, but fail when tested.  But it is very possible that this new version does support all of v5.5.1 of the GEDCOM Standard.

 

Since this is a brand new version it has not been tested yet by outside users.  If they had a free version that did not expire I might test it against my GEDCOM file and see if the data not only is imported but used by the software to build trees and generate proper reports with the data. Proper display and report generation are the most important function of true support.  

 

It could however be on my wish list at gift giving time!

[Vyger]

Proper display and report generation are the most important function of true support. 

[cvernons]

Keith,

 

Lots of good feedback from various users here, however I am not sure there is one clear answer to your question.

 

From your question posting I am reading the following facts:

 

• You are cleaning up your Places list and merged multiple duplicate place records (eg. Any Place USA; Anyplace USA; Anyplace; Anyplace America) into a single valid 'Master' place - eg. Anyplace USA.
• In the process of doing this your new 'Master Place' listing of Anyplace USA contains 3 Place Detail records for a particular cemetery that vary in how the cemetery is recorded - Green Cemetery; Green Cemetery Bangor; Green Cemetery Bangor Maine for example. 
• The intent here is to make the Master Place record indicate a single cemetery Place Detail entry. In this example we desire to show the Place Detail as Green Cemetery
• You desire this to occur only for entries currently containing one of the three cited examples of Place Detail name descriptions.
• It is your desire to merge these 3 existing Place Detail records into a single Place Detail record attached to the consolidate Master Place entry - Anyplace USA in the examples shown previously.
• By merging all of the Place Detail records for the specific record of 'Anyplace USA' Master Place, all existing FACT entries using/referring to this 'Anyplace USA' place with the consolidated cemetery location would display a Place Detail of Green Cemetery. 

 

If I have interpreted your request correctly then the following process should accomplish your goal:

 

Using RootsMagic 7 on a Windows machine ( I cannot speak Apple OS and am unsure if the screens vary on those systems )

Click on LISTS entry in the Menu Bar near the top of the screen

In the resulting drop down men select "Place List"

In the resulting Place sub-menu, type in the desired Place name - Anyplace USA from my examples above.

Note the multiple existing cemetery Place Detail records will display to the right of the Place List box.

Once the Place name is highlighted select the "PLACE DETAILS" button near the upper right corner of the sub-menu screen. A Place Details sub-menu will open.

Select the desired Place Detail entry, or edit one of the existing ones to fulfill this need.

Click on the MERGE button inside the Place Detail sub-menu.  A Merge sub-menu will open.

Click on the selection box of the other Place Detail records to merge with the desired/edited record selected above.

Review your selections to be sure you have them selected correctly. 

Click on the button MERGE SELECTED PLACES found in the lower right corner of the Merge sub-menu.

After merging you should display only the desired/edited Green Cemetery Place Detail record in the list of Place Details for the Anyplace USA Place entry you have highlighted/selected.

You may edit this consolidated Place Detail record to adjust the name, add any Place Notes or attach Place media/image files as needed. 

 

 

If I have misinterpreted your original request my apologies.  Hope this helps!

 

Craig

[keithcstone]

Craig,

 

First off, in RM7 on Mac OS the menus are nearly identical to Windows since it's simply the Windows RM running in a wrapper. I merge places and place details after every session where I grab data from external sources. 

 

What have done already is merge all the city, county, state; county, state; and state into single entries. So I have three entries that each have multiple place details under them. So there is Green Cemetery, City, County, State, as well as Green Cemetery, County, State. Fixing that means:

 

a) Finding everyone using the place name / place detail referring to Green Cemetery, County, State and manually changing that reference to Green Cemetery, City, County, State, then deleting the place detail for Green Cemetery under County, State. 

 

Digging through the DB with SQL and finding the ID for Green Cemetery, County, State and changing it in all references to the ID for Green Cemetery, City, County, State, and then deleting the place detail for Green Cemetery under County, State. 

 

What I really want is a "move place detail" that would allow you move move a single place detail and attach it to another master place. I could probably fudge this by exporting the whole kit and caboodle to GEDCOM and editing it in text, then reimporting it into a new file so it would rebuild the place master and place detail tables. Most of your "unused places" disappear during a drag and drop, although ones that you have geocoded seem to live on.

 

While I will attempt (if known) to use the historical place name instead of the contemporary one, I make an exception for burial facts so I can create reports with all known people in a single cemetery. I do this as I'm leaving breadcrumbs for those coming after me and you're likely to look for a cemetery in it's contemporary location, but if you were married in county A in 1800, and now it's split to county A & B and that location is now in county B, odds are finding that marriage record will be searching for county A as opposed to B.