It is particularly frustrating trying to locate an ancestor in online records when we know exactly where and when to look—like the US Census records for the county we know they lived in—only, they are nowhere to be found.

We look again. And again. We pour another cup of coffee, and look again.

Nothing!

We invent a story in our head—maybe they were not at home when the census taker came by. We are never going to find them in this record.

There has to be an explanation. Maybe the county lines were redrawn, maybe the county gave up land to form a new county, maybe …

We talk ourselves into checking the nearby counties.

Nothing!

William of Ockham whispers in our ear …

Rule 2: Spell Like a 9-Year-Old

Our ancestors were not necessarily the most literate bunch—public schooling beyond the 8th grade was not widely available until the mid-1900’s. And the DMV was not issuing driver’s licenses yet.

When records were created, the person writing the record (also often with limited spelling skills) wrote down phonetically what they heard. Throw in accents, poor handwriting, older handwriting styles, poor record transcriptions, and, yes, even honest mistakes.

So get creative. Think like a 9-year-old. How could our ancestor’s name be spelled.

To demonstrate our point, and with thanks to the Weatherbee Round-Up: A Newsletter for Weatherbee Descendents, here is a short list of the ways the last name Wetherbee is correctly spelled (and this is before we throw in totally mangled misspelling of these) …

• Watharby
• Watherbe
• Watherbee
• Watherby
• Weathabee
• Weatharbey
• Weather
• Weatherbe
• Weatherbee
• Weatherbei
• Weatherbey
• Weatherby
• Weattherby
• Weetherbee
• Weetherby
• Wethebee
• Wetheby
• Wetheirbee
• Wether
• Wetherbe
• Wetherbee
• Wetherbei
• Wetherbey
• Wetherby
• Wheatherbee
• Wheatherby
• Wherby
• Whetherbe
• Whetherbee
• Whetherby
• Whitherbey
• Witherbe
• Witherbee
• Witherbey
• Witherby
• Witterbee

“Marco.” “Polo.”

Where (location, place, position) is obviously important in genealogy. It literally defines where we came from, where life events occurred, where we will die, and, most importantly, it determines where we look for family records—and, without records, genealogy is a fool’s errand.

But where can be confusing. Is Cavalier, North Dakota, in Cavalier County? No, it is in Pembina County. Hannah is in Cavalier County. And is it really a one hour drive from Macon, Georgia to Macon County, Georgia? Yes, it really is.

There are over 2,300 distinct places in our family tree today. And that is before we misspelled most of them, creating more places in the family tree than there are family members.

How does Google (or Bing, or Apple) know where to drop those pins? And does a place exist, or did it exist, if Google Maps does not say it does, or did?

Meet geocoding. Geocoding, according to the Google Developers website, “is the process of converting addresses (like a street address) into geographic coordinates (like latitude and longitude), which you can use to place markers on a map, or position the map. Reverse geocoding is the process of converting geographic coordinates into a human-readable address.”

Sounds easy enough.

Where is Manvers?

If we want to research the Hannah family from the Watne branch of the family tree, we have to spend a lot of time crawling through the 1851 Census for Manvers in Canada. Where in Canada is Manvers?

Well, that is a trick question, as Canada did not yet exist in 1851. Canada was formed in 1867. Manvers was a township in Durham County in Canada West (think Ontario) in the Province of Canada, a British colony. Detail matters when we are talking where.

Where is Manvers, according to Google Maps, typing in exactly the place name from the 1851 Census?

Well, Google Maps struck out the place name Manvers, and instead returns the Durham Regional Municipality (shown below) which is a regional municipality in Ontario. Sort of in the neighborhood, but the Manvers Township of 1851 was not even in this outlined region.

As of 1 Jan 2001, it is in Kawartha Lakes at the top-middle of the above map. So Google Maps does not know, or does not want us to know they know.

What if we instead ask Bing Maps , again typing in exactly the place description from the 1851 Census?

Well, Bing Maps knows! The description above is exactly the where we are looking for, and it even lists Manvers Township.

But Bing Maps only sort of knows, or only sort of wants us to know. Bing Maps then drops the pin at the wrong place! The pin is even further from Manvers Township than Google Maps said, or did not say. And the pin is not even in the middle of the original place Durham County, or the current place Durham Regional Municipality.

And that, by way of example, is geocoding—wonderful!

Lots of Elbow Grease

So, if we want to see our place pins at the right places on a map, we are going to have to resolve all the original place names that no longer exist, or that no longer exist with the same names, to the current place names. And we need to save the original place names for research purposes—the records we are researching usually list the place names of their time, or an even earlier time, not our time.

How do we resolve all the original place names to current place names?

There are two steps: (1) find the current place name for an original place name, and (2) change the original place name to the current place name everywhere it appears in the family tree.

What magic do we use for step 1? No magic, just lots of elbow grease. Lots of web and map searches to find the right place. Original place names can be littered with alternate spellings and typos; names of nearby geographical features; names of castles, manors, plantations, and hospitals; etc. Sometimes, we have to find the original record referenced by a later reference we are using to confirm or correct the place name.

For step 2, we have found the places functionality of Family Tree Maker (FTM) to be very powerful, enabling us to quickly change tens or hundreds of facts containing an original place name to the current place name, and to enter the original place name in the description field of each fact. It is not perfect, but it sure beats manually changing hundreds of facts for a single place name.

FTM displays the place names in a hierarchy, making it is easy to distinguish Macon, Bibb County, Georgia, from Macon County, Georgia. We can check our work in real-time on a map that is displayed next to the editing menu. FTM also lets us enter or change the coordinates for a place name, allowing us to keep original place names, like the Kingdom of Northumbria (a kingdom in northern England and southeastern Scotland, 654-954 A.D.), and drop the pin at the right place.

After we are done, and sync our family tree from FTM back to Ancestry, a fact that occurred in Manvers Township in 1852 will look something like this:

The current place name—Kawartha Lakes, Ontario, Canada— is entered in the fact location so the pin will be placed correctly on the map. And the original place name, or the part that has changed—Manvers Township, Durham County—is entered in the description field of the fact.

1852? But we are working on the 1851 Census. Well, the 1851 Census was performed in 1852. That is time, not place, and is the topic for another day.

“Why Can’t We Be Friends?”

But—there is always a But—there is still a problem, 3 problems actually:

• Ancestry uses OpenStreetMap, an open-sourced map.
• Family Tree Maker uses Bing Maps.
  
• The Next Generation of Genealogy Sitebuilding (TNG), the genealogy software used on this website, uses Google Maps.

1 world. 3 different maps. 3 different geocoding databases.

So, until Google and Bing (Microsoft) and the OpenStreetMap contributor community agree to agree, we still do not always get the pin to drop on the map at the same place for a given place name as we move the family tree between Ancestry, FTM, and this website (TNG).

“Life is a Journey, Not a Destination”

“I started on a journey just about a week ago
To the little town of Morrow in the state of Ohio
I never was a traveler and really did not know
That Morrow was the hardest place I’d ever try to go.”

From To Morrow, by Lew Sully, published 1898.

Which family members lived in Morrow Village, Salem Township, Warren County, Ohio, USA?

Yes, it is a real place. Well, no one that we know of, yet.

But if we can not travel to Morrow, we can travel to Nowhere.

These family members lived in Nowhere, Madison County, Georgia, USA, according to the 1880 US Census:

• Benjamin Franklin O’Kelley, wife Elizabeth Miriam White, and family
• Bennett W. Brown, wife Susan A. Swindle, and family
• PVT George H. O’Kelley, wife Eliza Jane Ligon Pittman, and family
• Thomas Milton O’Kelley, wife Elizabeth Marian Chandler

In the Climb Our Family Tree section of this website, our family tree is stored in a database, MySQL if you must know. That endows The Next Generation of Genealogy Sitebuilding (TNG) software, integrated into this website, with superpowers—queries! Queries allow us to search the family tree for specific information that would be near impossible to find otherwise. TNG uses these queries to display reports.

We’ve provided quite a few pre-built reports at Climb Our Family Tree > Info > Reports. With these reports, you can quickly find all the immigrants, twins, or war veterans in the family tree, and much more.

Hint, hint … we have provided several reports that you can use if you are interested in taking on a project to research our family tree or correct obvious mistakes in its information. These reports are the ones whose names start with Help Correct … or Help Research ….

So what does a MySQL query look like? The Twins, Triplets, Etc. report runs this MySQL query:

SELECT c.familyID, p.personID, p.lastname, p.firstname, p.birthdate, p.birthplace, p.living, COUNT( c.familyID ) AS Number, p.gedcom
FROM tng_children AS c
INNER JOIN tng_people AS p ON p.personID = c.personID
INNER JOIN tng_children AS c2 ON c2.familyID = c.familyID
INNER JOIN tng_people AS p2 ON p2.personID = c2.personID
WHERE (
p2.birthdatetr = p.birthdatetr
OR p2.birthdatetr = DATE_ADD( p.birthdatetr, INTERVAL 1
DAY )
OR p2.birthdatetr = DATE_SUB( p.birthdatetr, INTERVAL 1
DAY )
)
AND YEAR( p.birthdatetr ) <>0
AND MONTH( p.birthdatetr ) <>0
AND DAYOFMONTH( p.birthdatetr ) <>0
GROUP BY c.familyID, p.personID, p.birthdatetr
HAVING COUNT( c2.familyID ) >=2
ORDER BY p.lastname, c.familyID, p.birthdatetr

That basically just says to list all the siblings in the tree that share the same birthday with one of their siblings, with some extra checking thrown in to ensure the birthdate is valid, and the list is then ordered by last name, then family ID, and then birthdate so the siblings are grouped together in the list.

We also have many other reports that are used by the family tree administrator to manage the family tree (e.g. finding typos and invalid characters in names, dates, and places; ensuring living family members are indeed listed as Living, ensuring recently deceased family members are listed as Private, and countless other tedious tasks). Consider yourself spared.

Many of these reports were generated by the TNG Community and can be found here.

If you have an idea for a report, let us know, and we’ll see if we can find or create the needed query.

Spend even a little time in the world of genealogy and you will encounter removed used to describe the relationship between two cousins; for example:

• First Cousin Once Removed
• Fourth Cousin 4 Times (4x) Removed

The degree of the cousin relationship (e.g. First Cousin, Fourth Cousin in the examples above) is determined by the cousin that is closest in relationship to (fewest generations below) the Most Recent Common Ancestor (MRCA) of the two cousins.

The removal of the cousin relationship (e.g. Once Removed, 4 Times Removed in the examples above) is the number of generations the two cousins are apart. So, for example, if the closest cousin is 3 generations below the MRCA, and the other cousin is 4 generations below the MRCA, then they are Second Cousins Once Removed:

Closest cousin is 3 generations below the MCRA → Second Cousins

4 generations – 3 generations = 1 generation apart → Once Removed

Below is a handy and well-formatted table of consanguinity from Graham Chamberlain:

Look up the relationship of the first person to the MCRA in row 0. Look up the relationship of the second person to the MCRA in column 0. The relationship of these two cousins is then found at the intersection of the column for the first person and the row for the second person. For example:

Great-grandson to MCRA → Row 0, Column 3

2nd great-granddaughter to MCRA → Column 0, Row 4

Intersection at Column 3, Row 4 → Second Cousin Once Removed

You can learn even more about cousins from Wikipedia.

With online document repositories, record indexing, and the oh-so-simple-looking Search box, we grow accustomed to being taken magically to just the record we are looking for. Another birth date, another ancestor for the family tree. It is oh so simple.

Go ahead, you know you’re feeling lucky.

But in this simplicity, we run the risk of developing tunnel vision and missing related records, missing much needed historical context, and well, missing the journey itself.

When the Search takes you to the record you asked for, take the time to look up and look down in the document to get a lay of the land. In a census, read the prior 5 pages, and the following 5 pages. You may be pleasantly surprised with what you find. We’ve lost count of how many times we have been. What leads us to …

Rule 1: Look Up, Look Down