Help talk:GEDCOM


Archive Created

See Help_talk:GEDCOM/Archive for older items.

Before You Upload Guidance [19 November 2008]

Over at the watercooler, we started talking about "before you upload" instructions. Dallan asked us to move it over here.

In order to diminish the amount of clean-up AFTER you upload your GEDCOM to WeRelate, here are some steps to take BEFORE you upload:

  • Make a "privatized" version of your GEDCOM first. This would remove all living people. Follow the instructions of your genealogy software for generating a "privatized" GEDCOM. (We might want to provide instructions for the most popular programs.)
  • Clean up your sources to rename or remove such sources as "SMITH.GED" or "JONES.FTM." Using the master source editing capability of your genealogy software, change each of these to be more descriptive, such as "Personal Research as shared by John Smith 12 October 2008" and then put appropriate contact information in the information fields about that source.
  • Review the WeRelate Naming Convention for Sources, and rename your master sources appropriately.

(We should add real examples to all of these.)

suggested topic [20 July 2009]

How should I prepare my data before uploading to WeRelate? OR Things I need to know before I upload to WeRelate.
What do I do about locations that I have that look like this:

Ravenswood, Mason (now Jackson) Co., VA (now West Virginia) This is very typical!

Jackson County has now been cut out of the early Mason County and after 1863 that area of Virginia became part of the new West Virginia.

I would list the place as "Ravenswood, Mason, Virginia" in the GEDCOM, since that's where the event took place and I think that's where it should be listed. If you do this, the system won't be able to link it to a Place page because the system doesn't know that Ravenswood used to be in Mason county, and that Mason county used to be in Virginia. To correct this problem, you need to tell the system about these place changes: Edit Place:Mason, West Virginia, United States and add Virginia as an "also-located-in" place. Also edit Place:Ravenswood, Jackson, West Virginia, United States and add "Mason, West Virginia, United States" as an also-located-in place. If you do this a few hours before uploading your GEDCOM, then when you upload your GEDCOM, "Ravenswood, Mason, Virginia" will be linked to "Ravenswood, Jackson, West Virginia, United States", which is what we want to happen. If you've already uploaded your GEDCOM and see this problem, then you can create a new Place page for "Ravenswood, Mason, Virginia" and redirect it to Place:Ravenswood, Jackson, West Virginia, United States so that it links to the right Place page, but you should also edit the Ravenswood and Mason place pages to add the also-located-in places so that future GEDCOM uploads will link to the correct places.--Dallan 12:51, 29 November 2008 (EST)

Also none of my locations have 'United States' indicated.

US locations don't need the country; just the state.--Dallan 12:51, 29 November 2008 (EST)

Should all state information before the Revolution (or some specified date) be changed to 'Colony of XXXXX' to be more technically correct?

I don't think this is necessary. If you do have it though, be sure to add "Colony of XXXXX" as an alternate name on the Place pages for the colonies so that the place matcher can find the right places.--Dallan 12:51, 29 November 2008 (EST)

If I upload a person without death date or location,

will WeRelate assume the person is living?
People with birth dates in the last 110 years without a death or burial date or place are assumed living. People without birth or death dates are generally assumed to be dead.
What does WeRelate do with living persons?
Or should I tell my software to not upload living persons?
WeRelate removes all information from living people except the gender and surname, so you end up with a page titled "Living Smith," with nothing on it except for a name, gender, and the families that he/she belongs to.
Many of my individuals have 'unknown' as a date of death. Will that let WeRelate know the person is deceased?
Yes. Anything at all in the death or burial date or place fields causes WeRelate to assume the person is dead.
Should I tell my program to change all surnames to Mixed Case or Upper Case?
Your preference. Most people seem to use mixed case here.
A lot of 'mysources' have names and email addresses of persons who have sent me their family info - too many to contact and anyway I don't want to lose the email addresses. But I am concerned about making their email addresses so public. Any recommendations? Can email addresses in sources be harvested by spammers?
That's a good point. They could be. I'll have to think about how to remove things that look like email addresses so they don't get uploaded.
A recommendation that the author run a report of duplicates and/or possible problems and correct them before uploading.
I'm thinking of making a "review" step part of the upload process, and having the system show a list of possible duplicates and data problems, along with unmatched places and maybe MySource's with email addresses, so that people can review their GEDCOM and make any necessary changes before the pages get created. Showing possible duplicates would also happen here.--Dallan 12:51, 29 November 2008 (EST)

I think these are questions that could be addressed in a forum if or when one is set up, but until then; perhaps something in the help pages. Or did I miss them somewhere? I'm sure other folks will think of other questions too. --Janiejac 22:42, 27 November 2008 (EST)

Good questions, Janie. Regarding living people, I noticed someone's pages the other day that included living people. I did not make a note of the user name; so now I cannot locate those pages. This person evidently uploaded a gedcom with the word living typed in the death field. WeRelate uploaded the "living" people.
Looks like I should change the uploader to not mark someone as dead if the death date contains the word "living"--Dallan 12:51, 29 November 2008 (EST)
Regarding email addresses; it might be a good idea to substitute the word at spelled out, for the @ in the email address. I believe that this will prevent the spamming of those email addresses. --Beth 08:02, 28 November 2008 (EST)

I just found out that there is a place for questions like this at [Help talk:GEDCOM]. Perhaps someone could move this over there. I am unsure if I should/could copy and paste this esp since there is a response. I'm hoping someone will post some answers! --Janiejac 11:14, 28 November 2008 (EST)

What else?

-- jillaine 15:16, 19 November 2008 (EST)

Sources that use "Free-Form Text" [24 July 2009]

Well, I've just encountered a doozie situation, and I fear it's not unique.

Reunion is probably the most popular genie program for Mac owners. I use it.

When one is creating/editing sources, you have the option to enter your data in one of two ways (or use both together):

  1. Through Source Fields
  2. Through Free-form Text

The first (Source Fields) is as you might expect and includes:

  • Title
  • Date
  • Locality
  • File #
  • Media Type
  • Location of source
  • Library/Archive

And a number of other fields. The end user can select the fields they're most often likely to use. And then use them.

The second (Free-Form Text) can be used in a couple of ways:

a) as a place to enter the narrative-- i.e., as the "text box" for your citation; i.e., Marriages 1650: Ulrich Jauch, son of Veit, married Maria, single daughter of Johannes Vosseler. b) as an alternative to the Source Fields. In this latter case, instead of entering things in defined fields, you simply type the title, author, etc. into a text box.

The recent frustrated user (User:FactFinder) has been using Reunion for years, and she uses approach (b) above. (I just spent 40 minutes on the phone with her.)

When she imported her GEDCOM to Werelate, Werelate looked for the source fields. They're all empty because she doesn't use them. Because they're all empty, WeRelate named each of her sources "Source (##)". Look:

FactFinder's Sources

And all of the other fields-- except text-- are empty, too. Needless to say, there was no way for the merge-upon-upload feature to work on her sources.

But now she wants them to "look right" and her first conclusion was to convert her MySources to Sources. This will obviously take way too long.

I've advised her, for now, to leave her MySources alone while I brought this challenge back to the Powers That Be.

The irony: her work is really really well sourced. Nicely so. She's also of the "share freely in order to improve the quality of work out there" philosophy.

She just uses her software program in a way that WeRelate may not know what to do with.

And here's the other thing: She's probably not alone. Reunion offers this feature; probably others use it.

How should we advise her?


-- jillaine 19:21, 20 July 2009 (EDT)

I have seen this too. You can spot a Reunion import because of all the unnamed sources. It similar to the problem others have where we used a collective sources in our databases (i.e. 1980 US Federal Census) rather than one broken out to whatever level of detail is decided upon here. (such as year/county level for census)
The new gedcom import process is the ideal place for doing the fixes for people who want things to "look right". But there are some hang-ups. I spent hours linking all of the sources on the Person pages on an import of about 150 people, only to have them changed back to MySources when they were processed. Dallan says this shouldn't happen and will look at it. If he can get this to work it will give us a chance to get things done systematically before letting them loose.
The other alternative is for her to "fix them" in Reunion, naming the sources before exporting. I've had to take this approach a lot with my TMG database.
The problem is that we genealogists are hobbyiests and despite our best intentions lack a certain amount of rigor in our data entry. This is compounded by the wacky gedcom standard that practically allows every developer to do whatever he feels like in interpreting it. We can't blame it on WeRelate. People dump junky looking gedcoms onto RootsWeb and other sites every day. It's only on WeRelate where we see how nice a page can look that we tend to care about appearances. She has my sympathy. I'm trying to clean up a Reunion dump that a collaborator uploaded. I've resorted to creating all new citations and deleting the old ones. It's tedious. --Judy (jlanoux) 20:04, 20 July 2009 (EDT)

I'll presume to offer an analysis and suggestion, since Dallan is on "vacation".... :)
Turning them into individual sources wouldn't just be time consuming, I think it would be inappropriate. These appear to be captions for document scans and photographs.
For document scans, I would instead upload them and associate them with the appropriate people. Then, attach them to the facts that they substantiate (I think this is pretty much what the "images" portion of our fact item records are for - at least, that's how I use it). For example, the death certificates for Person:Horace Mason (1) and his wife Person:Linnie Dennett (1) are uploaded jpeg images, that document the DODs. I also saw captions that appear to be scans of marriage certificates, an example of this would be found for Family:George Tuttle and Adelle Marden (1).
Other pictures, that don't document specific facts, I would think should be uploaded and associated as any picture would.
--Jrm03063 20:31, 20 July 2009 (EDT)

Wow. It seems like I should default the MySource title to the first line of the text when no other fields are present. That would give reasonable titles to the sources I looked at. The uploader could change this default title if they wanted during the GEDCOM review. I'll make this change either today or tomorrow - at the same time that I fix the Sources getting imported as MySources problem. I'll report on twitter when it's ready. I don't know if User:FactFinder would want to delete and re-upload their GEDCOM.--Dallan 11:19, 23 July 2009 (EDT)

Wow, Dallan, I didn't know you could do that. Totally cool. I'll tell her. I think she'll be willing to re-upload. Let me get back to you. (I've developed a rapport with her.) jillaine 11:28, 23 July 2009 (EDT)
Seeing as how this bug is the reason I stopped uploading gedcoms, it's nice to see it fixed... --Amelia 00:57, 24 July 2009 (EDT)
I'll be putting out a new version of the GEDCOM uploader later tonight that will fix this problem, exclude filename-only GEDCOM sources by default, exclude unreferenced sources by default, and will update people just once even if they're in several matched families. And matched sources are getting imported as Source citations, not MySources.--Dallan 21:51, 24 July 2009 (EDT)

You really know how to spend a Friday night, Dallan! ;-) [Thanks!] jillaine 21:54, 24 July 2009 (EDT)

What Happens When You Upload a GEDCOM? [27 October 2013]

I think it would be helpful to have a section in this Help article that tells what happens when your GEDCOM is accepted. What types of pages are created? Which fields are populated? What kinds of tag types are recognized, and if they are beyond BMDB, what happens to the data in them?

Or does this exist someplace and I've just missed it?

Treigel 13:45, 8 November 2009 (EST)

Terry, this is a great idea. We need some input from Dallan re: what exactly happens to which fields, etc. -- Jillaine 17:11, 8 November 2009 (EST)
I'll try to do my best to answer this question on the primary page.--Dallan 12:30, 29 November 2009 (EST)

Thanks, Dallan. That seems to answer all my questions on this topic. :-)


NICELY done, Dallan. Thanks! Jillaine 13:42, 29 November 2009 (EST)

Sorry to be a newbie pest, but I'd like to ask if there are yet any details about supported GEDCOM tags and destination fields. Supplementary questions are: - does editing the Wiki reflect changes back to the GEDCOM if downloaded? - when can we have a re-upload? (sorreee)--Pauldesmondwhite 23:26, 27 October 2013 (UTC)

Re Upload -- Can "info" be deleted? [9 July 2015]

Based on a discussion at the Water Cooler, the information regarding re-uploading a GedCom is probably out of date (it seems likely that adding a "re-upload" ability is very low on a list of changes that need to be made to WeRelate), and contrary to what we actually want (it advises people to delete their trees and upload a new GedCom.) Shouldn't we just delete this entry? Possibly it could be replaced with something about "up-dating" information, emphasizing editing existing information and using small GedComs to add new individuals? --GayelKnott 16:12, 9 July 2015 (UTC)

Edits. [4 September 2016]

I have just made a couple of edits to Section 1.2 (How should I prepare my data for GEDCOM upload?) The first was to change "It is also a good idea to check for common errors such as spouses being alive at the same time, children being born during the parents' life times, etc." to "It is also a good idea to check for common errors such as spouses being alive at the same time, children not being born during the parents' life times, etc." That balances the two phrases--though the first phrase as currently written denies divorce, and divorces do/did happen. The second was a typo in the spelling of "field".

I also wondered if the last part of the last sentence "the place field should only contain places in our database with the option of a more detailed display name." will be entirely clear to a user who as yet may not have inspected our person pages too carefully. The "option" is to fill in the Description field. It might be better if we said so.

And now I am about to upload a short gedcom lengthening a branch of my family tree with some new discoveries. This is the first gedcom I have offered to WR since I originally joined. Every other addition has been done manually. I am anxious to see how it goes. I know I shall have to alter all the sources and places. Legacy can only speak American. --Goldenoldie 05:48, 4 September 2016 (UTC)

First thank you for working on the help pages. They all need editing. I took a shot at addressing the place name issue. I think I said too much. Maybe you can edit it and make it clearer.