General operational question

Anonymous
2009-10-19
2013-05-30
  • Anonymous - 2009-10-19

    Thought I posted this last night but can't find my posting.

    1.  is it best to merge GED files with some other program, or import the files into PGV and deal with duplicates there?  If I want to keep my main GED file on my PC, what is the best program for merging GED files and dealing with duplicates?

    2.  Do you keep the master GED file on your PC and do all the work there and then upload updates?  This method would keep people from changing the online version as you wouldn't get those updates into your master PC-based copy?  Would you instead as people who are contributing to send you a copy of the GED file or changes?

    3. I have located several family trees that are from different parts of our greater family which may or may not have common ancestors.  Is it best to add all the pieces into one GED or to have multiple GED files and then try at some point to find a link?  I have had a lot of people give me partial trees or maybe just a few generations, but don't know where they link into the tree I have.  I thought it would be best to have all the pieces in one place so people can search that one dB for their family and hopefully at some point a link will occur between the pieces.  Make sense?

    Thanks!

     
  • Anonymous - 2009-10-19

    How weird.  I numbered my questions and the numbers appeared in the preview, but dissapeared when saving the post??

     
  • Anonymous - 2009-10-19

    "How weird. I numbered my questions and the numbers appeared in the preview, but dissapeared when saving the post??" - yup, great forum software isn't it !!!!!!

    Taking your queries one at a time (manually numbering them, 'cos the outline numbering option here doesn't work!):

    1 - Merging in PGV. It only has the ability merge individual entries (INDI, FAM, SOUR etc. You can't "import" whole trees to your exiting GEDCOM file.

    2 - Linking. PGV does allow you to have multiple GEDCOM files on the same DB, and link them through common people. It has limitations, and I certainly wouldn't recommend it if you have more than a couple of connections between the two trees. A few of the charts won't function across liked files, most notably (when I last checked) the Relationship chart.  My personal view is that such linking was a good idea when first introduced, when PGV was getting pretty slow with large files. That's no longer the case, so I don't need it now. Some people use it for its original intention, to link GEDCOM files on totally different web sites.

    3 - Master GEDCOM files. This is personal preference. But I ONLY use PGV. It is my master file. I see no purpose in having any other, and to do so only complicates life. The greatest point of risking damage to your data is during the import process (IMHO) so the fewer times you need to do that the better. You also have to contend with the fact that NO two pieces of software are 100% GEDCOM compatible. It shouldn't be that way, but it certainly is. PGV was designed to foster shared contributions to your tree - so why keep people out of it?

    4 - Merging GEDCOMs off-line. That, in my view, is the best alternative when you need to add large numbers of people/families to your tree. Unfortunately it is NEVER straightforward. There is no software that does it either perfectly or easily, but there are a couple that make a reasonable attempt. For MAC users (or anyone who knows a MAC user) try GEDITCOM. For PC users GENMERGE.com is pretty good. They both have their own web sites. Then there's Daniel Kionka's GDBI (here on Sorce Forge). Unfortunately, I think, its not currently compatible with PGV 4.2.2. Another method I've used for moderate sized additions is to renumber it, starting from something greater than your highest numbering in PGV, append it to your existing GEDCOM file, import into PGV and merge any individuals etc as required.

    5 - Unlinked branches.  This again is entirely personal. Miy preference is to ALWAYS insist that every individual on my tree is linked somehow. So if I have a branch I "think" might link later, I either don't add them at all, or I create a temporary new GEDCOM file. However, some people prefer to add them as a unique, un-connected branch to the same file. Both work, and have pro's and con's.

     
  • Anonymous - 2009-10-20

    Got it…without having tried, I thought I could keep merging in new GED files to the master GED file.  Glad to find that out now.  I am trying to get people to provide their trees to me in GED format as I thought trying to get them to add 500 people or more to my tree would be easier for them that way then hand typing in 500 people to PGV. 

    I did file genmerge and actually did use it.  How screwed up the data is, I don't know, but on the surface it seems to have merged the two databases I had on hand.

    I don't know how I would ever link separate GED files through individuals if I don't have them all in one file?  How would you ever know you had a common person otherwise?

    Anyway, if it wasn't for the other people with their huge trees to add, I could force people to do their input via PGV, but I find that the easier I make things for people, the more likely they are to do it.

    Thanks!

     
  • Anonymous - 2009-10-20

    If you've used GenMerge, your data should be fine. Its worth spending time experimenting with their settings, which can be quite complex to understand, but it does a good job. It certainly doesn't do any harm to your data.

        I don't know how I would ever link separate GED files through individuals if I don't have them all in one file? How would you ever know you had a common person otherwise?

    Presumably when someone sends you a new GEDCOM file its for a reason, and that must surely include information about who on that tree links to your family?  Thats the "common person".

    You will always need to do both; accept and either merge or link your users past work, plus encourage them to do all new work on your PGV site. You're right that it helps to make things easy for people, up to a point. I stop making it easy when they make it too hard for me. Main issue is usually a refusal to follow reasonable "standards" for data entry. if you've looked at peoples off-line (personal) trees you'll know what I mean. When no-one but you looks at the data, it really doesn't matter how poorly formatted and messy it is. But once you open it up to public scrutiny on a WWW page (IMHO) it needs to look at least half-decent. Little things like consistent use of capitals, proper spelling of place naes, full source references etc etc.

     
  • Wes Groleau

    Wes Groleau - 2009-10-20

    "If you've used GenMerge, your data should be fine"

    I 'm **very** skeptical.  I tested it by merging two subsets of the same GEDCOM.  Overlapping individuals-NO differences-were not detected as duplicates.  Huge SOURces and NOTEscommon to both files were also duplicated.  And the identifiers it generated were ridiculous.

    Would have taken me longer to clean up the mess than to paste in records by hand.

    What would PGV do if I were to
    1 - export GEDCOM
    2 - paste in a new set of records with xref IDs altered to ensure uniqueness (maybe use odd initial letters)
    3 - re-import
    4 - use PGV to merge records

     
  • Anonymous - 2009-10-20

    Wes, re Gen Merge, the issue you describe is not one I've experienced. My only issue was their tendency to not re-number, as such, but to append "GM" in front of existing numbers, which works fine in PGV, but I don't like it. That may not even happen now, as I haven't used it for a year or more. Overall I stll recommend the product.

    On your other question, that was my alternative mentioned above. I said:

    "Another method I've used for moderate sized additions is to renumber it, starting from something greater than your highest numbering in PGV, append it to your existing GEDCOM file, import into PGV and merge any individuals etc as required."

    Thats a very easy solution. Its fiddly, but I've even been successful in creating an Excel spreadsheet that calculates all the new numbering/Xref IDs (INDI,FAM,SOUR,OBJE,NOTE, REPO) required. The biggest issue comes if you have to merge a LOT of INDIs as a result. Still possible, but can be time consuming. But, as I mentioned above, there is NO easy solution to merging.

     
  • Anonymous - 2009-10-20

    I did the merger, or at least one so far…  I don't know if it mangled my data or not…haven't encountered any problems yet, but when you have 14K+ individuals in the database there can be a lot of undiscovered errors.

     

Log in to post a comment.