Downloads & Documentation

If you use any of the Gigatrees applications, please consider donating.


All of the applications listed below are free for everyone. You will NOT be asked to create a user account or to provide any personal information. The applications are provided "as-is" without warranty of any kind. Please review the Usage Policies for relevant licensing information, terms of use and privacy information. Complete documentation is provided below. Unfortunately I no longer have the time to provide individualized techinical support to users (except for legacy paid subscribers), hence, I also no longer accept paid subscriptions. However, if you find these applications useful and would still like to make a contribution to support my efforts (or just treat me to a coffee), a Paypal link is located at the top of the page.

  • VGedX: GEDCOM validation
  • DNA Pool Analyzer: DNA analysis
  • Innuendo: Stand-alone blogging platform
  • Gigatrees Mini: Family tree generation
  • Gigatrees Pro: Advanced family tree generation

Installation Current Version Samples
Download 4.0.5 Sample Report
DNA Pool Analyzer
Download 2.0.2 Sample Report
Download 2.0.1 Sample Blog
Gigatrees Mini
Download 2.0.2 Sample Tree
Gigatrees Pro
Download 4.6.3 Sample Tree



Gigatrees is a family tree generator designed for use by genealogists and family historians. Gigatrees is a Microsoft Windows console application written in C++. It was first developed in 1999 and then continually maintained and expanded by the author over the next 20 years. The program consists of 48 source files with approximately 22,000 lines of code. The program also imports an additional 31 library files consisting of 113,000 lines of code for handling the processing of XML, JSON, SQlite, and Unicode. It also imports various Boost string handling library files and Windows static libraries. Gigatrees runs under Microsoft Windows only, it will not run natively under MacOS, Linux, Android, iOS, or any other operating system.

Gigatrees creates mobile friendly HTML pages, built upon the responsive features of jQuery and Bootstrap, so that they look good on any size screen. Gigatrees will read virtually any GEDCOM 5.x file including many application specific GEDCOM extensions. It also has built-in support for ANSI, UTF-8 and UTF-16 encoding, as well as ASCII, extended ASCII and UNICODE character sets. Gigatrees supports language translations and data text replacement.

Gigatrees focuses on evidence-based genealogy. It promotes the use of source documentation for genealogical claims and provides useful extensions for formalizing that documentation. Reliability assessments are automatically determined for every claim, based on the source documentation provided, making it easy for users to identify where their documentation is lacking, so that research can be focused in areas that need it the most. Gigatrees supports application specific source citation templates. Gigatrees also allows you to categorize your sources using the Genealogy Proof Standard, supports the GEDCOM source reference quality field, indicating impossible claims and assigning sources to parental relationships giving you the ability to provide appropriate documentation to back up your biological connections.

Other features include analysis for DNA matches, detecting vendor specific privacy and living flags, and performing living detection and birth year estimation automatically, allowing for public website generation. Gigatrees also automatically links embedded URLs and allows for embedding HTML into almost any data field. Gigatrees allows overriding paths to multimedia files, handles individual profile photos and source record images, calculates consanguinity between spouses, calculates ethnicity estimates, and has advanced date handling allowing it to recognize most unambiguous date formats, including built in support for British monarch dates.

Family trees include pages for each individual, source, and location in your database, a separate pedigree chart for each individual, name indexes and a data validation report. Individual profile pages include timelines, fan charts, origin maps, kinship, generation and DNA relationship lists and ethnicity estimates among other things. Gigatrees performs a thorough data consistency validation, comparing event dates between related individuals and reports when inconsistencies are found. Inconsistencies are linked from the data validation report, and highlighted in all event timelines.

  • DNA Analyzer is a tool that can be used to show your DNA relationships.
  • Gigatrees Mini is a family tree generator based on a scaled-down version of the core program.
  • VGedX is a GEDCOM dictionary validator.

More will be said about each of these programs in the documentation that follows.

Usage Policies

The Usage Policies, including the Terms of Use, License Agreements and Privacy Policies, specify how this website and its current and legacy applications (Gigatrees, Gigatrees Pro, Gigatrees Mini, VGedX, Bonkers, Innuendo, and the DNA Pool Analyzer) may be used, what limitations apply, and what steps I take to protect your privacy. Use of this website or its software constitutes acceptance of these policies. Users should review these policies occasionally as they may change without notice. This document is intentionally kept short and concise so please take a moment to read through it.

Terms of Use

Users can download and run the Gigatrees applications free of charge and share them with others.

Gigatrees makes no guarantees that existing services will work as you might expect them.

License Agreements

This license agreement supersedes that found in the LICENSE.txt file in the distribution.

The Gigatrees applications and generated web pages may also be subject to third-party license agreements. This document serves as attribution to those agreements and their licencors.

The Gigatrees applications are products of Tim Forsythe and are licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License

Creative Commons License

This license agreement states that you are free to use the Gigatrees applications for personal use, however you may not use them for any commercial purposes, and that when using them for non-commercial purposes, you may not modify them and that you must provide appropriate attribution. Read the full license agreement for more details. The license agreement applies to the applications only, not to the web pages generated by them. The generated web pages may be subject to additional third-party end user agreements as listed below.

The Gigatrees applications may be subject to the following third-party license agreements, depending on your configuration.

The web pages generated by the Gigatrees applications, depending on your configuration, may use any of the following third-party libraries that require attribution.

Most of the third party license agreements allow you to use them for any reason as long as you don't hold the licencor liable. The Geocoding services also prohibit the redistribution of their data. The Geocoding and Mapping services apply only to Gigatrees Pro.

Privacy Policy

The ip addresses of visitors and users, their names, email addresses and non-secure application ids may be saved on internal databases for the purposes of authentication and page access logging (Names and emails are only stored for paid subscribers). None of this information is ever published. Emails will not be used internally to send site-wide emails. Gigatrees may also collect anonymous statistical data during application processing. None of the information collected is personally identifiable. Gigatrees may also collect information about critical failures such as crash dumps and processing errors, which are necessary for troubleshooting application errors that occur when installed by users. Application performance data may also be collected to be used in development to optimize future releases. Configuration and feature usage data is also collected in order to better understand how the application is being used so that development can proceed in the most effective manner.

Gigatrees uses non-secure application ids for authentication instead of secure passwords. This should eliminate any concerns that hackers can obtain your personal passwords. Gigatrees does not accept credit card information or any other types of secure or personal data. User's genealogical data is never accessed by or stored on the server.


The applications are all stand-alone programs so do not require a separate program to install or delete and do not modify your system registry.

To install a program, download the distribution file and extract it into any folder of your choosing. The distribution file is in .zip format and extracts itself into an installation folder. The name of the installation folder varies depending on the application being installed. To uninstall the application, simply delete the installation folder.

The installation folder will include an application file with an cli folder which includes the application and any assets, plugins or includes used by the program. It also includes a web folder where the output file(s) will stored by default, a default batch file (build.bat) and a configuration file (config.xml). All configuration files are in XML format and will include all possible configuration items set to their default values. The only exceptions to this are the common parameters: AppendRecords and ReplaceText (See examples below). Sample configuration files (sample.bat, sample.xml) may also be included.

When upgrading, you should always start with a new installation - do not to try simply to copy the executable to your old installation folder. Even though the Gigatrees applications do not modify your system registry, assets, plugins, includes and default configurations items may have changed, obsoleting your old configuration file. You will need to manually copy over any existing configuration options to your new configuration. You can do this by comparing the two files - this is not an automated process. When upgrading Gigatrees Pro, your old location database file (includes/gigatrees.sqlite) should be copied over to the new installation so that your existing cached coordinates are retained. If you have made changes to any other file, you should manually compare the old and new versions and copy over any changes, similar to what you do for the configuration file. Examples include the language file (includes/lang.txt) or plugin changes.


All of the Gigatrees applications can be run using the build.bat or sample.bat file located in the installation folder. You may need to first edit the config.xml file to specify the location of your GEDCOM file or other parameters. The readme.txt file, also located in the installation folder, will usually tell you what needs to be modified. Some of the necessary parameters are discussed below.

The above batch file make a call to the executable directly. You may also call the executable from the command line if you desire. When doing so, it will look in the same folder for a default configuration file (config.xml) if one is not specified on the command line. To see what command line parameters are supported, locate the .exe file in the distribution's cli folder and then enter that filename followed by -h on the command line. When you press the return key, you should get a list of supported command line parameters.

Example:vgedx.exe -h

The -l is always processed first. The remaining parameters are processed in the order they occur. Although you can define any of the parameters multiple times, generally you would only do this for the -c option. Splitting-up configurations into multiple configuration files can be useful to divide large configurations or for creating common and discrete elements when creating multiple reports.

Before building your family tree, blog or other reports you will need to edit the configuration file(s) with a text editor to set the GedcomFile file path, the OutputPath and your website Title.

By default, the Header and Footer of your web pages are constructed using the plugins specified in your configuration file. Plugins are loaded in the order they are listed. Users should not modify which plugins are loaded or their order unless they understand how those changes will effect their output files. Most users can simply ignore this section of their configuration. All applications load the following plugins:

  • metadata
  • googlefonts
  • jquery
  • bootstrap
  • ie8
  • styles or blog.styles
  • page.header

Other plugins commonly included are navbar, fontawesome, dragscroll.

Adding Plugins

Gigatrees allows users to add external plugins, which can be used to easily add well-behaved third-party scripts and specialized PHP code to your website headers and footers. Several plugins are loaded by the default configuration file.

The Header and Footer options include several hooks that plugins can use to install themselves. These are specified by %PreHeader%, %DropHeader%, %DropBody% and %DropFooter%. The default Header and Footer includes these hooks in a typical fashion. The following shows the default Header and Footer

<![CDATA[ %PreHeader%<!DOCTYPE html><head>%DropHeader%</head><body class="container">%DropBody% ]]>

<![CDATA[ %DropFooter%</body></html> ]]>

The <![CDATA[ and ]]> allow for embedding HTML elements inside XML elements.

Plugins support hooks for metadata substitutions as well and can be found in use in the metadata and navbar plugins among others.. Some of the metadata options are directly configurable, others are determined at run time when the page is built.

  • %Domain% - defined using the Domain config option
  • %SiteTitle% - defined using the Title config option
  • %Description% - defined using the Description config option
  • %LangCode% - defined using the LanguageCode config option
  • %Application%
  • %MenuBar%
  • %AssetsPath%
  • Gigatrees Pro Only

  • %PageTitle% - post title
  • %PageURL% - post URL
  • %Author% - post author
  • %Keywords% - keywords
  • %FeedLink% - feed link
  • %PageStyles% - style overrides

The navbar plugin can be removed to prevent the navigation bar from being displayed, or can be replaced with your own hand-crafted navigation bar.

To create a new plugin, create a folder using the name of your plugin. Inside that folder create a plugin.xml file and include any necessary configuration options. Additional support files can be put anywhere inside the named plugin folder or into subfolders. The %PluginsPath% substitution macro can be used to access the relative path of the Output Path's plugins folder. The %AssetsPath% substitution macro can be used to access the relative path of the Output Path's assets folder.

To install plugins, use Plugins configuration option. Plugins are loaded in the order they are listed. Users should not modify which plugins are loaded or their order unless they understand how those changes will effect their output files.

<Plugin> cli\plugins\metadata </Plugin>
<Plugin> cli\plugins\googlefonts </Plugin>
<Plugin> cli\plugins\jquery </Plugin>
<Plugin> cli\plugins\bootstrap </Plugin>
<Plugin> cli\plugins\ie8 </Plugin>
<Plugin> cli\plugins\styles </Plugin>
<Plugin> cli\plugins\page.header </Plugin>

Anything that can be added in a plugin can also be added to the Header and Footer options directly. Plugins are especially useful however, when including specialized code from an external source such as another user, or when building multiple trees that may share configuration files but differ in which specializations they use.

Below shows the contents of a typical plugin's plugin.xml file, in this case, bootstrap. Not the use of %PluginsPath% to access the output path's plugins folder.

<link rel="stylesheet" href="">

<script type="text/javascript" src=""></script>
<script type="text/javascript" src="%PluginsPath%bootstrap/bootstrap-tooltip-handler.js"></script>
GEDCOM Validation

Gigatrees imports GEDCOM files only. It never modifies or writes to the imported file. Most genealogy applications/editors allow users to export their genealogy database into a GEDCOM file for easy transfer between applications. There are several GEDCOM versions in common use. VGedX, the GEDCOM Validator, supports all of these: 5.5 Rev 1 (January 2, 1996), 5.5 Rev2 (January 10, 1996), 5.5.1 and 5.6. GEDCOM 5.5 Rev 1 was a major change from its previous version, 5.4, which is effectively obsolete. GEDCOM 5.5 Rev 1 was updated shortly after its release through an email addendum (5.5 Rev 2), however the addendum was not widely distributed. GEDCOM 5.5.1 was released much later and is considered the defacto standard. GEDCOM 5.6 was never widely adopted. All of the versions listed have a common syntax, but use different dictionaries. It should be noted that 75% of the GEDCOM files I've processed over the last several years are 5.5 Rev1 or Rev2, whereas only 22% are 5.5.1. Over 40% of all files come from, so it would appear that the most significant player in exporting GEDCOM files never adopted the defacto standard, so perhaps it is not so defacto after all.

GEDCOM can be thought of as a genealogy database structure with predefined record types, record fields and record subfields. When a genealogy application exports its database to a GEDCOM file, it must map its internal database structures to the predefined GEDCOM record types, fields, and subfields. This is not always possible. When a conflict arises during the export process, the exporting application may create user-defined record types, fields or subfields (all versions of the common GEDCOM standards mentioned above support this extensibility feature), or they will discard the information so that it is not available in the exported file. When an importing application does not recognize a user-defined field created by an exporting application, it will usually discard the information. Since information is often discarded during either the exporting or importing processes, GEDCOM is a poor choice for the permanent transfer of data between genealogy applications.

GEDCOM Validation is at the core of all Gigatrees applications. As stated above VGedX supports and validates GEDCOM files by reading the GEDCOM version embedded in the file and then comparing each line to the GEDCOM 5 common syntax and then by comparing the record types, fields and subfields to the version's specific dictionary. In some cases, the various GEDCOM standards define enumerated values for record field data, however, many of these are now obsolete. VGedX makes no attempt to validate data fields against the defined enumerated types. It also makes no attempt to validate the data for consistency, such as making sure a birth date occurs before a death date. Gigatrees includes data consistency validation.

The GEDCOM standard(s) are often maligned by users and developers as being incomplete and ambiguous. I disagree with this assessment. Most of the ambiguities occur because syntax or dictionary structures are sometimes defined one way, and then used in their example in another way. There also some naming ambiguities, and global definitions that are overridden by local ones. In all cases, it is fairly obvious how the ambiguity should be interpreted, and there has been much discussion among technologists hammering out these finer points. Regardless, importing applications should be able to handle the ambiguities in all possible interpretations. As far as its incompleteness, the extensibility features I mentioned allow for adding new features, and I have made use of this in developing Gigatrees. Other vendors do as well. I cannot recall seeing any GEDCOM file exported from the 100+ vendors I've processed that does include some user-defined record, fields and subfield types. I worked with specifications for data transfer for over 30 years as a professional software engineer, both in communication protocols (which are complicated by hardware timing constraints) and general data translation and parsing, and I'd say that the existing GEDCOM standards are far superior than most in their accuracy and completeness. Most of the problems I see concerning GEDCOM have to do with how vendors implement the standards.

The Gigatrees applications (but not VGedX) includes support for an additional non-standard GEDCOM version 5.x specification, which is effectively an extended dictionary that includes all of the record types, fields and subfields defined by the common standards, plus hundreds of others defined by various genealogy applications that have been discovered during the processing of exported files. Support includes location records, shared roles and source citation templates.

Gigatrees somewhat arbitrarily, divides its validation statuses into three categories, Errors, Warnings, and Alerts. Errors are critical syntax failures that will more than likely prevent a GEDCOM line from being usable by an importing application. Warnings violate the letter of the specification, but are likely to not interfere with their usability by importing applications. Alerts are not violations and are provided for information purposes only. The only exception to this is the Trailing spaces not expected alert, which does violate the specification, but it is universally violated, so has been deprioritized. All warnings and alerts can be optionally ignored in VGedX. The other applications are able to process most of these, so they are not generally flagged.


  • Unsupported GEDCOM version detected
  • Level number expected
  • Level number gap
  • Invalid ID length
  • ID missing
  • Invalid ID reference length
  • Tag Expected
  • Data contains non-printable characters
  • ID reference missing
  • Unexpected ID reference
  • Invalid ID reference type
  • ID reference substitution
  • Duplicate record found
  • Referenced record not found


  • Level number exceeds limit
  • Level has leading zero
  • ID delimiter missing
  • Invalid ID length
  • Invalid ID character
  • Invalid ID reference length
  • Invalid ID reference character
  • Invalid tag length
  • Invalid tag character
  • Too few occurrences of tag
  • Too many occurrences of tag
  • Data contains tabs
  • Maximum line length exceeded
  • Data missing
  • Insufficient data
  • Maximum data length exceeded
  • Data not expected
  • Trailing data not expected
  • Unpaired ampersand (@)
  • Undefined record found (VGedX only)
  • Unsupported record found (5.x only)
  • Record not referenced
  • Data contains non-printable characters (5.x only)
  • Too many delimiters
  • Unexpected ID reference (5.x only)


  • Trailing spaces not expected
  • User defined record found
  • Embedded ID reference uses an implied record id

VGedX, as is shown above in the Usage section, supports command line options to generate sample GEDCOM files for each of the 4 supported specifications. The 4 sample GEDCOM files are also included in the distribution. These files include every supported dictionary record, field and subfield, such that the files can be used to test support of importing applications. The files are created exporting tags discovered by recursively walking the dictionary. The files should not be considered exhaustive test files. They do not include boundary test cases or syntax violations.


There are features common to all of the Gigatrees applications. One of these is the ability to modify the text generated by Gigatrees. By default, all system text is in English and is fixed. The LanguageFile option allows users to load a language file to replace the system text. The default language file is lang.txt. The file will include all of the system text as semi-colon delimited strings. The default language file includes English substitutions for the default system text. Users can replace the text occurring after the semi-colon with alternate text. This can be used by international users to create output files in their native language or by English speakers to display alternate text.

The following snippet is taken from the default language file. Close observers will notice several of the strings have been altered or cleared.

Replacing Data Text

In some cases, users may need to replace the record data found in their GEDCOM file. Commonly this is used to replace image file paths. To do this, the Replace option can be used. When defined, it will replace all occurrences found in GEDCOM field data.


<Text> c:\folder\pics\ </Text>
<Display> file://c:/folder/pics/ </Display>
Prepending Record Fields

Gigatrees supports numerous GEDCOM extensions as new user-defined fields. You will find many examples throughout the documentation. GEDCOM records contain three types of data tags, those for records, fields and subfields. Level 0 tags define GEDCOM records; Level 1 tags define GEDCOM fields; Level n (2,3,4,...99) tags define GEDCOM subfields. Gigatrees supports adding Level 1 tags (fields) only.

The AppendRecords option can also be used to prepend new record fields, or to override existing fields. Gigatrees processes record fields in the sequential order. When it finds multiple identical fields defined it generally keeps the first and discards the rest (this algorithm does not apply to individual and family events, such as birth dates where all occurrences are kept). The AppendRecords option is misnamed, because it actually prepends the configured tag to the record, making it the first occurrence and therefore given priority. See examples below.

How To Add Privacy Flags

When publishing family trees, privacy is an paramount consideration. Information about living persons and source material that might still be under copyright are two examples of sensitive information that should not be published online. The most common method for keeping this information private is to use a genealogy application to strip private data before building a family tree. This is generally overkill and may hide more data than is necessary. It also might not capture all private data when doing so. A more secure method is to use privatization flags that indicate exactly which records and fields should be privatized.

Gigatrees supports adding privatization flags to your database using the AppendRecords option. The flags take effect when either the HideLiving or Privatize security options have been enabled.

Gigatrees supports five different flags (and their vendor specific alternates): _LIVE, _SKIP, _SHOW, _HIDE and _PRIV..

The first of these, _LIVE allows you to add a living flag to living person in your database

<RecordId> I1 </RecordId>
<Tag> _LIVE </Tag>
<Value> Y </Value>

As shown in the example, privacy flags must be added as a field to the record where they apply. In this case, the living flag is applied to the individual's logical record. When a person is flagged as living, Gigatrees will change their name to HIDDEN _____ and all claims and source references associated with that person are deleted. Family links are preserved. Because Gigatrees automatically estimates missing birth years, adding living flags is generally not necessary. In those rare instances when Gigatrees cannot calculate a birth year, having manually entered a living flag will ensure that the individual is privatized.

Vendor Specific Alternates:LVG, LVNG, _FLGS.__LIVING, ATTR Living, _LIVING Y.

If you want to omit a profile page for an individual entirely, the _SKIP will direct all links to their tree page, showing only their name.

<RecordId> I1 </RecordId>
<Tag> _SKIP </Tag>
<Value> Y </Value>

The _SHOW flag is used to force showing all details for a living person, such as yourself. For skipped persons, only their name is shown. This flag has priority over the living flag. It is likely that you will only want to do this for a very few persons.

<RecordId> I1 </RecordId>
<Tag> _SHOW </Tag>
<Value> Y </Value>

The _HIDE flag is used to force hiding a logical record completely and take priority over all other flags

<RecordId> I1 </RecordId>
<Tag> _HIDE </Tag>
<Value> Y </Value>

Vendor Specific Alternates: _EXCLUDE

The _PRIV flag is used to strip any field from any record while leaving the rest of the record intact. When added using the AppendRecords option, acts like _HIDE option stripping the entire record. Luckily, several vendors support alternate versions of this flag which are supported (see the list below).

The only way add the _PRIV flag is to add it to the GEDCOM file directly, which is probably not very useful unless you are a FamilyHistorian user. The following example shows how they can use it to hide a birth record.

0 @I1@ INDI
1 _SHOW true
2 DATE 1 JAN 2000
2 PLAC Chicago, IL
2 _PRIV Sensitive

In the case of this above example, the entire birth record is omitted. _PRIVflags can be added to any record field and any level, so for instance it could have been used to strip just the birth date, while leaving the location intact. Privatization qualifiers such as "Y", "true", "Sensitive" and "Copyrighted" are always ignored by Gigatrees.

Vendor Specific Alternates:_FLGS.__PRIVATE, _CONF_FLAG.

Another way you can privatize any piece of data is by stripping it using the ReplaceText option, however doing so will replace the Text everywhere it is found in the GEDCOM file.

<Text> 1 JAN 2000 </Text>
<Display> </Display>
What Are Reliability Assessments?

When publishing a family tree it is useful for visitors to be able to quickly and accurately assess the validity of the claims being made. Gigatrees automatically calculates the reliability assessment for every claim using several pieces of data including, the source category defined for the referenced sources, the source reference quality (QUAY) defined within the source references for the claim, and the source type defined within the source itself. Gigatrees will display the calculated reliability assessment alongside each claim. Gigatrees also supports manually setting the reliability assessment for claims.

Gigatrees defines several levels of reliability.

"unsupported", "estimated", "unreliable", "uncertain", "proposed", "reported", "supported", "probable", "certain", "questionable", "proven" and "impossible".

When multiple sources are referenced for a claim, the source with the best quality is used. If a source reference is found for a claim, but no source or source reference quality is defined, the reliability assessment will be set to uncertain. If the claim is an estimated (calculated) birth year, the reliability assessment will be set to estimated. If the claim is not a birth date estimate, and no source reference is found for the claim, the reliability assessment will be set to unsupported. Biological relationships, including parental associations, are treated as claims (because they are) and are accompanied by reliability assessments. If you have not already done so, you may want to add source references to your parental association claims.

On occasion, the calculated reliability assessment may be inappropriate for the claim being made. This can be caused by improper source categorization or failure to reference all the available sources. It can also be caused by a reliable source making a unreliable claim. To override these, Gigatrees supports setting the reliability assessment manually to any claim by using the NOTE field.

0 @I1@ INDI
2 DATE 1 JAN 1900
2 NOTE proven

Overriding reliability assessments is the only method for directly indicating that a claim is impossible.

The reliability assessment strings are translatable so that you can use strings in your own language.

When displayed, claims always show the "best" assessment, which implies an order of precedence. In general the order of precedence always degrades from the most certain to the least certain. As shown in the table below, there are four GEDCOM data fields that affect order, the reliability assessment override field (_PROOF) described above, the presence of a source reference (SOUR@) for the claim, the source category (_QUAL), and the source reference quality (QUAY) as defined in the GEDCOM standard. Note that not all of the defined reliability assessment strings described above will be automatically determined, but can still be set using the reliability assessment override tag.

To prevent Gigatrees from making exaggerated reliability assessment determinations, sources that contain multiple types of evidence, should set the source category to the quality associated with the least reliable evidence. You can also break up your source into multiple sources, one for each type of evidence.

In the table below, an "x" indicates that a field must be present. An empty field indicates the the value of the field has less precedence or does not matter.

NOTE        SOUR@  category    type     QUAY  reliability
------ ---- -------- ---- ---- ---------
estimated [calculated]
[value] [value]
x 0 questionable
x dna proven
x 3 certain
x primary certain
x original certain
x 2 probable
x secondary probable
x transcript probable
x copy probable
x abstract probable
x research supported
x memoir reported
x 1 proposed
x derivative proposed
x unknown uncertain
x unreliable unreliable
x [value] [value]
x uncertain

When there is no other information available to determine the reliability assessment, Gigatrees makes one last ditch effort by looking at the source's type (@SOUR.TYPE or @SOUR._TYPE) field. This is a non-standard GEDCOM field, but is used by several popular genealogy applications.

Defining Impossible Claims

Most genealogy programs have no way of indicating that a claim is impossible (i.e. proved to be false), so genealogists are usually forced to delete these claims from their databases. This is an unfortunate practice that should not be necessary. A better practice is to retain impossible claims along with their source references and text explaining why the claim is false.

Gigatrees supports several methods for indicating that a claim is impossible. You can override any calculated reliability assessment using 2 NOTE impossible as described in the previous section.

0 @I1@ INDI
2 DATE 1 JAN 1900
2 NOTE impossible
2 NOTE This is a note explaining why the claim is impossible

You can also use the built in GEDCOM tag for source reference quality (QUAY) and set it to 0. Some users may set their source reference quality to 0 for other than impossible claims, so Gigatrees will display a questionable reliability assessment when this method is used. If you only use this tag for impossible claims, you may want to use the translate feature to manually replace the questionable display text with impossible.

0 @I1@ INDI
2 DATE 1 JAN 1900
2 SOUR @S1@
3 QUAY 0

When impossible claims are defined, Gigatrees will not considered them when calculating birth year estimates or consistency checking. Impossible claims will be highlighted on profile pages making it clear that the claim is known to be false. The following screenshot shows several impossible claims and their explanations. As you can see, keeping impossible claims has value in that is lets other researchers know which blind alley's they can avoid. If your explanations are not sufficient, however, it will not achieve that goal.

Handling Source Citation Metadata

Gigatrees supports the RootsMagic source template fields (@SOUR._TMPLT) and subfields (SOUR@_TMPLT)for capturing source citation data (metadata) as well as other standalone GEDCOM and vendor specific extensions.

RootsMagic implements a vendor specific source template field to define free-form name/value pairs. Gigatrees will read these pairs and use them in the source citation. Virtually any name/value pair can be used. For instance, RootsMagic uses many, including Bibliography, Footnote, ShortFootnote, Author, SuplAuthor, SuplRole, Title, SubTitle, PubPlace, Publisher, PubDate, OrigPubPlace, OrigPublisher, OrigDate, Creator, Periodical, SocietyInfo, Volume, Edition, PageRange, Remarks, Jurisdiction, County, District, Volume, Folder_Box, Series, AgencyRecords, Collection, Repository, RepositoryLoc, DatabaseTitle, ItemType, WebsiteOwner, WebsiteTitle and URL. URLs are automatically hyperlinked.

A typical name value pair might look something like the following:

0 @S1@ SOUR
3 NAME Bibliography
3 VALUE "United States Census, 1930," index and images, <i>FamilySearch</i> (ht
2 CONC tps:// : accessed 28 Dec 2013), C
2 CONC hicago (Districts 0751-10020), Cook, Illinois, United States; citing en
2 CONC umeration district (ED) 0972, sheet , family 53, NARA microfilm publica
2 CONC tion.

In addition, for source references, RootsMagic implements Page, Author, Title, PostDate, AccessType, AccessDate, SpanRead, Annotation and ItemOfInterest. When Gigatrees discovers the Page item, it will use its value for the source reference page number if not otherwise defined. Source reference template items are shown only in source reference tooltips.

A typical name value pair might look something like the following:

1 SOUR @S1@
4 NAME Page
4 VALUE p. 108

Gigatrees also recognizes several GEDCOM and vendor specific extensions that can also be used to define source metadata. These include the standard GEDCOM fields: TITL, ABBR and PUBL, as well as the vendor specific _SUBQ, _BIBL, EDTN, LOCA, TYPE, _TYPE, MEDI, _MEDI, DETA, and _OTHER fields.

Defining Source Categories

Gigatrees supports a number of different options for categorizing your sources. When defined, source categories are shown on the profile page for each source, as well as in the tooltips for every source reference. They are also shown on the sortable source index page.

The purpose of defining source categories is to help determine the possible types of bias that may overshadow the claims the source makes. Source categories are used internally by Gigatrees to help calculate reliability assessments. Gigatrees defines two types of source categories ('concurrency' and 'authority') that may be assigned to your sources. Each category type has several possible values.

Source Concurrency may be set to "primary", "secondary" or "unreliable", where primary represents that the document was created at the time of the recorded events (such as a birth certificate), secondary represents that the document was created some significant amount of time after the events occurred (such as a transcription of a birth certificate), and unreliable is a source that is known to be error prone.

Source Authority may be set to "dna", "original", "transcript", "copy", "abstract", "research", "memoir", "derivative" or "unknown". When adding a source containing yDNA or mtDNA test results that prove a biological relationship, the dna category should be used. It would be inappropriate to use this for autosomal DNA test results unless those results were combined with an in-depth analysis showing why they could be used as proof. original represents a document in its original form (such as a birth certificate). transcript is a direct unaltered transcription of an original source. copy is a subsequent copy of a transcription or of another copy (i.e. copy of a copy). abstract is any abstraction or summary of the original source (not in its original form). research is an authoritative collection of claims derived from multiple sources. In order for the collection to be considered authoritative, the researcher or genealogist should have included the relevant source citations. memoir is a collection of authoritative claims taken from memory, such as an autobiography, letters, notes, etc. derivative is a non-authoritative collection of claims derived from multiple primary and secondary sources. This will include most books, town histories, etc. unknown is a source from which no information as to its authority can be determined.

The source category strings are translatable so that you can use strings in your own language.

Claims that are both primary and original are generally considered to be unbiased, though not necessarily without error. Secondary sources may suffer memory bias due to a time lapse occurring between the event and the recording as well as from copy errors. Derivative sources may also suffer from these as well as author bias, intentional or otherwise. All sources may contain lies.

From experience we know that certain types of records are more accurate and have less bias than others. For instance, birth certificates (original, primary) almost never have incorrect birth dates. Baptism records (original, secondary), even those recorded within just a few months of birth, may contain incorrect birth dates caused by memory lapses of the mother, as astounding as that seems. Death certificates and tombstones (original, secondary), which usually occur many years after birth and the informant is generally not the mother, often contain incorrect birth dates. Census records (original, primary) are notorious for having inaccurate ages due to the fact that the informant was more than likely a spouse of the head of household, and who, especially early on, had little formal education resulting in subtraction errors or simply guesswork. Had the census authorities required birth years instead of ages, they would probably be much more accurate. Census records, however, are very accurate for documenting parental relationships, so there you go.

Categorizing sources can be very tricky and is sometimes more art than it is science. Gigatrees therefore allows you to not only categorize your sources, but to also override the reliability assessments derived from those categories for individual claims when necessary.

For many sources, multiple source categories might apply. When determining the appropriate source category to use, you should choose the least authoritative category that applies to the claims being extracted from it. For instance, if you have a source that includes scans of original documents, along with some memoirs and derivatives, but you are only using the images of the original documents from that source, they you can rightfully choose original as your source category. If however you include claims from the other areas of the source, then you should choose a different source category. A serious genealogist might, in this case, split their single source up into several source entries, each with their own category.

To add source categories to existing sources, use the AppendRecords and the _QUAL GEDCOM extension.

<AppendRecord> <RecordId> S1 </RecordId> <Tag> _QUAL </Tag> <Value> primary </Value> </AppendRecord>
<AppendRecord> <RecordId> S2 </RecordId> <Tag> _QUAL </Tag> <Value> memoir </Value> </AppendRecord>
<AppendRecord> <RecordId> S3 </RecordId> <Tag> _QUAL </Tag> <Value> secondary </Value> </AppendRecord>
<AppendRecord> <RecordId> S3 </RecordId> <Tag> _QUAL </Tag> <Value> derivative </Value> </AppendRecord>

Additionally, Gigatrees supports the RootsMagic method for adding source categories as part of a source reference. RootsMagic only supports source categories that align with those defined as part of the Genealogy Proof Standard (GPS), and then uses only the capitalized first letter of the category. For instance, in the following example, "O" is an abbreviation for original and "P" is an abbreviation for primary. Gigatrees will use the first reference it finds for a source to define the source's category.

0 @I1@ INDI
2 DATE 7 FEB 2014
2 SOUR @S1@
Defining Evidence Models

When using a source as evidence for a claim, it is useful to distinguish whether the source is direct (making a direct claim) or is indirect (indirectly supporting a conclusion). By default, source references indicating direct evidence are displayed in green with "Direct evidence for claim" shown in its tooltip. References indicating indirect evidence are displayed in purple and show "Indirect evidence supports this conclusion" in its tooltip.

Gigatrees supports the RootsMagic GEDCOM extensions for defining evidence models where the SOUR@._QUAL._EVID subfield can be set to D to indicate direct evidence, or to I to indicate indirect evidence. For example, a source that makes a direct claim would be

0 @I1@ INDI
2 DATE 7 FEB 2014
3 SOUR @S1@
Documenting Parental Relationships

By far, the most important claims in genealogy, and the ones needing the most documentation, are the biological links between children and their parents. Gigatrees uses parental association records and their source references to determine the reliability status for biological links. Unfortunately, the GEDCOM standard does not provide a good method for handling these claims. The only supported record types they provide are the Pedigree Linkage Type (PEDI), which provides built in predefined relationship fields, but does not allow you to link a source to the record, and the ASSO record, which does allow for referencing sources, but does not have built in predefined relationship types such as "mother" or "father". Several vendors support other relationship records such as the FamilyTreeMaker tags _FREL and _MREL, but like the Pedigree Linkage Type record, these do not allow for source references.

Gigatrees supports parental associations using all these methods. The Pedigree Linkage Type must be set to birth for it to be treated as a biological relationship of both parents.

0 @I1@ INDI
1 FAMC @F1@
2 PEDI birth

The _FREL and _MREL tags must have values of Natural or Biological.

0 @I1@ INDI
1 FAMC @F1@
2 _FREL Natural
2 _MREL Natural

The ASSO record should set its RELA field to "Father", "Mother" or "Parent". It can also be set to the translatable strings, "Associated Father" or "Associated Mother".

0 @I1@ INDI
1 ASSO @I2@
2 RELA Father
2 SOUR @S1@
1 ASSO @I3@
2 RELA Mother
2 SOUR @S1@

Gigatrees also supports leaving the RELA field blank, or leaving it off altogether, which in either case will assume a parental association. Any other text in the RELA field will indicate a non-parental association.

You must rely on vendor support to use any of the above methods to define parental associations, and only the ASSO tag allows for adding sources. Unfortunately, most vendors do not allow editing these fields. Gigatrees therefore provides a method that will work, no matter which application you use. Gigatrees defines new parental association source reference and source reference reliability GEDCOM tags. The new tags, _MREL_SOUR, _MREL_CERT (for the mother), and _FREL_SOUR, _FREL_CERT (for the father) can be added to any existing individual record using the AppendRecords option. If you have defined your source categories, then the _MREL_CERT and _FREL_CERT tags are only necessary if you need to override your reliability assessments.

<AppendRecord> <RecordId> P1 </RecordId> <Tag> _MREL_SOUR </Tag> <Value> S1 </Value> </AppendRecord>
<AppendRecord> <RecordId> P1 </RecordId> <Tag> _FREL_SOUR </Tag> <Value> S1 </Value> </AppendRecord>
Image Handling

Multimedia records specify the file paths or URLs to photos and images. URLs will be linked directly and automatically, but file paths require special handling.

File paths will be specified as either absolute paths including both the drive letter and image folder (i.e. c:\folder\pics\image.jpg), or as relative paths offset from the working folder of a database editor (i.e. \folder\pics\image.jpg or ..\folder\pics\image.jpg). Web browsers cannot display local file paths directly. The HideLocalLinks security option can be used to prevent dangling image placeholders from appearing in your family tree. To display local images in a web browser when viewing a website offline, the HideLocalLinks option needs to be disabled and the file path must be prepended with the file:// protocol scheme. This can be easily done by using the Replace option.

<Text> c:\folder\pics\ </Text>
<Display> file://c:/folder/pics/ </Display>

This same method can be used for relative paths, but requires including the images path in the replacement text.

<Text> ..\folder\pics\ </Text>
<Display> file://c:/[images path]/folder/working/pics/ </Display>

If you are hosting your tree online using an external server, and you've copied all your images onto the external server using the same subfolder structure, you can use the Replace Text option to remap these files paths to your external server URL.

<Text> c:\folder\pics\ </Text>
<Display> </Display>

By doing so you convert your file paths to website URLs. You can also map the file paths to relative URLs.

<Text> c:\folder\pics\ </Text>
<Display> /folder/pics/ </Display>

If you've uploaded your photos to a cloud service such as Flickr that permits external hotlinking, you can still remap your local file paths, but this will require remapping each image individually as follows.

<Text> c:\folder\pics\image1.jpg </Text>
<Display> </Display>
<Text> c:\folder\pics\image2.jpg </Text>
<Display> </Display>

File paths and URLs can only be linked when the they are recognizable as images. This means that the image name must end in a supported extension (.jpg, .png, .gif, .bmp). Cloud services that provide image links that do not end in one of these extensions will be treated as standard URLs.

Standard GEDCOM multimedia record structures are limited in what fields can be defined. Missing from the multimedia record structure are fields for thumbnails, captions, date, location and a credit line. Gigatrees includes extended support for additional fields which can be appended to existing multimedia records using the AppendRecords option. The AppendRecords option will only work with multimedia records, it will not work with multimedia record fields. The following example appends a thumbnail to an existing record.

<RecordId> M100 </RecordId>
<Tag> _PIC </Tag>
<Value> /folder/thumbs/thumbnail.jpg </Value>

The AppendRecords option can also be used to override existing fields. Gigatrees processes record fields in the sequential order. When it finds multiple identical fields defined it generally keeps the first and discards the rest. Since the AppendRecords option prepends the configured tag to the record, it is given priority. The following example overrides an existing multimedia file path, remapping it prior to processing any Replace configuration items.

<RecordId> M100 </RecordId>
<Tag> FILE </Tag>
<Value> </Value>

The following are a list of vendor specific extensions that are supported by Gigatrees:
_PHOTO - used instead of the "OBJE" when embedding photos or images
_FILE - used instead of the "FILE" field to include the path to the photo image
_TITL - used instead of the "TITL" field to include a photo title
_PIC - used to include the path to the thumbnail image if there is one
_CAP or _CMNT - used to include a caption
_SUBM - used to include photo credit
_NOTE - used instead of the "NOTE" field to include photo notes
_PLAC - used to include photo location information
_DATE - used to include photo date information.
URL - used to include the URL to the photo image
_URL - used to include the URL to the photo image
WWW - used to include the URL to the photo image
_WEB - used to include the URL to the photo image
_LINK - used to include the URL to the photo image
_WEBTAG - used to include a photo structure

The _WEBTAG field, specific to RootsMagic, uses a "NAME" field for the image title, and the "URL" field as described above.

  0 @S1@ SOUR
2 NAME Photo of my Uncle Walt
2 URL c:/folder/pics/image.jpg

When images are displayed, the thumbnail will be used. When no thumbnail is defined, Gigatrees will use the original image with reduced dimensions. If you have many images on a single page, this can result in slow page load speeds since each photo must be loaded.</>

All images use the FancyBox jQuery plug-in to display the photo in a popup light box when clicked on. The plug-in is loaded in the page Header and Footer metadata. This can be replaced or removed by modifying the Header and Footer options. Photo titles, captions, credit lines, etc. will be displayed in the FancyBox caption area. There is a FancyBox display configuration script handler(/assets/fancybox-handler.js) that can be modified to change how images are displayed. The default stylesheet (styles.css), also located in the installation's assets folder, include several style changes associated with FancyBox as well. Gigatrees does not encode any FancyBox specific elements into your family tree web pages, so you can replace the plug-in with an alternate if necessary.

When GEDCOM media image records or fields are assigned to individuals directly or by reference they will appear at the top of their profile page. Sources display their images wherever they are defined. When the image is clicked, it is loaded into a FancyBox. The FancyBox includes scrolling arrows if more than one image appears on a page, a control panel on the right and the image properties listed at the bottom. This formatting arrangement can be modified by editing the handler mentioned above. (The control panel moves to the top on small screens - see image below)

Specifying Marriage Order

Gigatrees supports several two special strings, "He Married" and "She Married", that can be configured in the GEDCOM family event description (FAMS.EVEN.TYPE) to indicate a husband's marriage order and a wife's marriage order. The strings can be translated as needed to something preferable. The marriage order should be defined using the GEDCOM FAMS.EVEN.CAUS record and set to a natural number: 1, 2, 3, etc. If defined, a person's marriages will display the ordinal (1st, 2nd, 3rd, etc.) for their marriage in their event lists. The following is an example of how the new event should be structured to indicate a husband's second marriage.

2 TYPE He Married
2 CAUS 2

Not all genealogy programs support adding new event descriptions\types and event causes.

Census Tables

Census Tables provide an easy way to view all of the census information for your ancestors in a single table, making it easy, at a glance, to determine which records are missing, where they are likely to be found, migration patterns, each person's approximate age and which persons are missing death dates. Census tables are included on a person's profile page if they have ancestors who were possibly living during the range of years specified by the CensusYears configuration option. CensusYears are not defined by default, so you will need to add the years to be considered. When no Census Years are configured, they will be determined automatically from the census records found in your file.

Census tables are composed of rows showing every applicable ancestor and columns showing every configured census year. Then for each census record found, the state abbreviation is placed in the table cell associated with the record's ancestor and year. State abbreviations are extracted from the SQLite3 database file specified by the LocationFile option. If no state abbreviation is found, then an 'X' is used instead. If the person has no census record for one of the census years, an "m" is displayed, and if the year does not apply to an individual, a "-" is used. If no census event was found for an ancestor whose living status cannot be determined, a question mark (?) will be displayed to indicate that the event is missing and that their living status is unknown. The state abbreviation is linked back to the applicable source record if found. Hovering over the state abbreviation displays a tooltip with the source title.

Gigatrees supports name type detection for census events, i.e. Named, Given and Counted. A name type of "Named" indicates that a person's given and surname are both provided as would be true for the head-of-household. When set, the location code will be shown in bold. A name type of "Given" indicates that only a person's given name is provided such as would be true of a spouse whose maiden (sur)name is not provided. When set, the location code will be underlined. A name type of "Counted" indicates that a person is counted in the census, but no name is provided, such as would be true of early U.S. Federal census records that only provide head counts. When set, the location code will be shown in italics. For all cases, the name type will be also be appended to the source citation tooltip for easy review. To set the name type for a census event, the GEDCOM CAUS field must be used. uses the RESI tag instead of CENS tag to indicate census records. Gigatrees will recognize these when the source for the residence claim indicates that it is a census source record.

When a GEDCOM census event description (CENS.TYPE) field is present, it will be used in place of the display string associated with the CENS tag in all timelines and event lists.

0 @I1@ INDI
2 TYPE Census (US Federal)
2 DATE 1 JAN 1920
2 PLAC 147 W. Knox St., Galesburg, Knox County, Illinois
2 AGE 5m
2 CAUS Named

Gigatrees also supports a _NO_CENS tag that will indicate that the person should be removed from all census tables for the year of that census record. An ancestor will be completely removed from a census table when it has been removed from every year for which they are applicable. This is useful for removing the early and immigrant ancestors from your tables who were living in areas where there were no censuses taken.

<AppendRecord> <RecordId> I1 </RecordId> <Tag> _NO_CENS </Tag> <Value> 1810 </Value> </AppendRecord>
<AppendRecord> <RecordId> I1 </RecordId> <Tag> _NO_CENS </Tag> <Value> 1820 </Value> </AppendRecord>
Pedigree Charts

Gigatrees supports six-generation bi-directional scrolling Pedigree Charts for each individual. The charts are available under the Tree menu or from the Pedigree button located at the top of each person's profile page. By default the Tree menu points to the first individual found in the GEDCOM file. This can be changed by modifying the HomePerson setting under the FamilyTreePages option.

<HomePerson> I1 </HomePerson>

You can click/touch the up or down arrow to scroll through the charts. Plus signs are used to indicate if the person's ancestry continues beyond the current chart. Unsupported biological relationships are indicated using a grey box. Clicking/touching on any box takes you to that person's profile page. The charts are designed to display correctly on desktops and iPads, but will require scrolling on iPhones and other small tablets.

Generation Lists

Gigatrees supports generation lists using the AGNUS numbering system. Generation lists are basically, nothing more than ancestor lists that use AGNUS rather than the popular Ahnen numbering system (referred to by some authors, including myself on occasion, as the Ahnentafel numbering system). The Ahnen numbering system has been in use for over 400 years, and has remained the most commonly used numbering system for creating lists of ancestors, called an Ahnenliste, due in part to its simplicity, and, no doubt, to its cool name. The Encyclopedia of Genealogy described the numbering system briefly.

"In an Ahnentafel numbering system, the base person is assigned the number one. The father of each person is assigned a number equal to double the child's number. The mother of each person is assigned a number equal to double the child's number plus one. As a result, the number of any child is one-half that of their parent, ignoring any remainder."

The Ahnen numbering system was developed in the age of pen-and-paper genealogy, for persistence. It was important that id numbers did not change when someone was inserted or removed from a list; redrawing was a bear. There is of course no protection for ids when generations are inserted or removed.

The Ahnen numbering system has what can be referred to as a primary id number and an alternate id number. The alternate id number only appears when a person occurs in more than one location in a list. In a typical Ahnenliste, this can be seen as a "same as" number and is usually located next to an individual's name. Alternate id numbers are caused by consanguinity among ancestors due to intermarrying within families. Primary id numbers in an Ahnenliste grow by the power of two, so for a 50 generation list this results in ids in the hundreds of trillions. For those not interested in writing this out, it requires 15 digits and asks computer algorithms to perform 64 bit arithmemagic. The Ahnen numbering system was definitely never meant to be used for such large trees.

Agnus makes no attempt at being persistent and therefore cannot be thought of as a direct replacement for the Ahnen numbering system. Agnus was developed for computer presentation where renumbering can be done on the fly. Agnus uses a primary id, an alternate id, and an additional secondary id. The generation is kept separate, and for the purposes of presentation is optional when generational information is otherwise displayed. Also, the primary id is composed of a family line and a generational position. The secondary id, is also composed of a family line and a generational position, but for the secondary id, the position is always 0, so need only ever be optionally displayed. Where the primary id in both systems tracks the male ancestral line, the secondary id in Agnus tracks the female ancestral line. Alternate ids indicate the primary id of a duplicate individual.

The benefit of Agnus, is that a list with both primary and secondary ids (and alternate ids) is bidirectional in that it can be traversed in both directions, ancestrally and descendantly (my spell checker says that isn't even a word. I say it didn't use to be). With Agnus, you can tell at a glance who the parents of any person are as well as their descendant. You can traverse paternal ancestral lines by using primary ids only, or you can traverse maternal lines by using the family line numbers of both the primary and secondary ids. When an alternate id is found, the primary id effectively switches over to that of the alternate id -- this behavior is the same for the Ahnen numbering systems as well. For example, if a person's primary id is 1.01 and their secondary id is 2[.00], then their father will be found at primary id 1.02 and their mother at primary id 2.01. Alternately, if the person's primary id is 1.02, their child will be found at primary id 1.01. If the person's primary id is 2.01, their child will be found at secondary id 2[.00].

When it comes to presentation, each of the three ids can be displayed in fixed width formats containing an optional generation id followed by an optional colon, followed by a family line id, followed by a period and a 2 digit generational position, i.e. [GG:]LLLL.PP. The optimal fixed widths can be determined at presentation time. The brackets shown in this syntax indicate optional elements only. One additional presentation feature is needed to indicate whenever the primary id's final generational position has been reached, i.e. the individual has no father. For this I propose placing a simple asterisks (*) after the id, though any sort of visible terminator could suffice. The benefit of this terminator is to inform the viewer when traversing up the list that to continue on to the next generation they will need to follow the secondary id's (mother's) family line. If the mother's line has terminated, the secondary id is simply left blank. The terminator should not be used when an alternate id is present as that already provides that indication. The secondary and alternate ids have a similar syntax, except that neither will ever have an asterisks, the secondary id generational position (PP) is always "00" so only need be optionally displayed, and the alternate id is generally accompanied by the generation number, though it is not necessary as the generation list can still be used effectively without it, but may require more searching as alternate id family numbers are sometimes found in non-adjacent generations. When generation numbers are present in alternate ids, they can also provide an indication of generation hopping which may be helpful to viewers in locating errors in their lineages. A typical 3 id indication therefore might look something like: LLLL.PP* LLLL GG:LLLL.PP. The last presentation feature is strictly optional; whereas in the Ahnen numbering system, ancestors are paired by couples, I propose that Agnus primary ids are sorted by the family line number within each generation. This makes it much easier to visually trace family lines between generations. Each generation in the resulting generation list will then show all male ancestors before showing all female ancestors. Similarly, when secondary ids are assigned as described below, it would simplify presentation if they followed this sorting order, however, accomplishing this may be overly complex, so is not required.

The algorithm is simple. The primary id of the root person when their father is also present in the list will always be 1.01, that is, family line 1, position 1. The same person's secondary id when their mother is present in the list is 2[.00], representing family 2. The primary id of this person's father is 1.02, indicating the 2nd generational position, and their mother will be 2.01, indicating the 1st generational position. With the exception of the root ancestor, all lines begin with women, but generational positions always follow the male line. Best of both worlds, eh? New family lines are created for every woman in the list in numerical order (unless sorted as described above). That is it in a nutshell.

The following list includes the first 4 generations of ancestors for Henry Plantagenet III, King of England. Generations are sorted by family lines, secondary ids were assigned in numerical order (not sorted order).

Generation 1
[1.01 2] Henry Plantagenet, III, King of England

Generation 2
[1.02 3] John Plantagenet, I, King of England
[2.01 4] Isabelle d'Angouleme, Countess of Angouleme

Generation 3
[1.03 5] Henry Plantagenet, II, King of England
[2.02 7] Aymer de Valence, Count of Angoulême
[3.01 6] Eleanor, Duchess of Aquitaine and Queen of France
[4.01 8] Alice de Courtenay

Generation 4
[1.04 9] Geoffrey Plantagenet, V, Duke of Normandy
[2.03 13] William, VI, Count of Angoulême
[3.02 11] William, X, Duke of Aquitaine
[4.02 15] Pierre de Courtenay, I, Count of Courtenay and Montargis
[5.01 10] Princess Matilda, Empress of Germany
[6.01 12] Eleanor de Chastellerault
[7.01 14] Marguerite de Turenne
[8.01 16] Elizabeth de Courtenay

As you can readily see from this list, the root person's male ancestors follow family line 1, i.e. 1.01 -> 1.02 -> 1.03 -> 1.04. His maternal line: (2) -> 2.01 -> (4) -> 4.01 -> (8) -> 8.01. Since family numbers are doled out in order, this is not the same as doubling or bit shifting (adding powers of 2), so the maternal line can include odd numbered families as well. In a similar fashion then, the maternal line can be traced backwards 8.01 -> (8) -> 4.01 -> (4) -> 2.01 -> (2) - > 1.01. For the purposes of presentation, this is a great advantage. Though it is possible to manually traverse a list in such a manner, it is also possible to automate these traversals in a variety of different ways, making Agnus ideally suited for computer presentation of generation lists.

Generation Lists are included on the profile pages of all persons having ancestors. Generation Lists include for each ancestor listed, their migration path, and accumulated reliability assessment. Accumulated reliability assessments always choose the least reliable assessment for the relationship shown and the relationships of all their descendants, so that if a low reliability is found for any parental relationship, no relationship for any earlier ancestor can be more reliable.

Fan Charts

Gigatrees supports Fan Charts on the profile page of every individual having ancestors. The same algorithms used to build the Generation Lists are also used for the Fan Charts. The Fan Charts are generated using the D3 charting library. The number of generations shown will depend on screen size, which is limited by D3 as well as Gigatrees for comfortable viewing. The percentage of chart completion is shown based on the scaled size. Missing generations are dislayed in light grey. Generations including a pedigree collapse will appear in white. Fan Charts allow for a IndicateReliabilityInFanCharts setting under the ProfilePages option. It is disabled by default, but is enabled in the sample.xml file. When enabled, the chart will be color-coded based upon the relaibility assessment of the biological relationship. The colors range from dark green, indicating the highest reliability, through light green, shades of yellow/amber/brown and then finally red, indicating the least reliable claims. When the setting is disabled, the colors are somewhat random.

<IndicateReliabilityInFanCharts> true </IndicateReliabilityInFanCharts>

Hovering over or clicking/touching any location in the Fan Chart will dynamicallly expand to display the ancestor list for that individual and each person's relationship as well as the associated reliability when the above setting is enabled. Clicking outside the Fan Chart will collapse back to its default size.

If you want to disable the fan charts for any reason.

<EnableFanCharts> false </EnableFanCharts>
Fan Chart: Collapsed

Fan Chart: Expanded

Fan Chart: Scaled

Determining Consanguinity

When researching ancestors from several hundred years ago, back into the medieval era, it is sometimes useful to know if there is a consanguineous relationship between married individuals. Primarily because marriages between individuals too closly related were prohibited by the Church and often by civil law. Royal marriages in Britain between closely related individuals sometimes required a special dispensation from the Pope in order for the marriage to be recognized. If a researcher discovers what they think is a new marriage, and the couple is found to be closely related through their family lines, but no special dispensation can be found, then the researcher must be able to provide convincing evidence that shows clear proof in order for their results to be accepted. Finding how closely related spouses are is often a manual, time-consuming process. Gigatrees does this automatically.

Gigatrees automates this process by calculating all kinship lines for all unions and married individuals found in your GEDCOM file and based on the relationship data found there for their ancestors. The spouses' profile pages will display Kinship Lines (shown above) listing each kinship found, the degree of kinship and their Most Recent Common Ancestor (MRCA). Clicking on the MCRA will pull up a Kinship List page showing the descent for each spouse from the MRCA (shown below). The Kinship List page a Generation List, but includes only the MRCA and the spouses identified.

Gigatrees calculates the degree of kinship using civil law, and sets the prohibitive degree of kinship by default to 4. All persons found to be having civil kinships of the 4th degree or less will be listed and linked to from the Data Validation page for easy access.

Determining Ethnicity

In the current environment of autosomal DNA testing, ethnicity estimating has gotten a bad rap. This is because all the DNA testing companies show different results, and often these results are confusing. Firstly, all of these companies compare a selected portion of your DNA against a relatively small sample of known profiles of living people whose ethnicities are defined as belonging to certain regions according to their known heritage. These small samples and assumed heritages have a tendency to skew the results. Secondly, genetic inheritance provides no guarantee that a significant portion of an individuals' ancestors' DNA will be passed down to the individual, nor that the ancestors' DNA will be part of the sample analyzed. Thirdly, DNA segments mutate at varying rates, but averaging in the thousand years plus range, so that the ethnicities that these companies provide may extend back multiple to tens of thousands of years, far beyond the 1500 or so years that our genealogies can be traced.

I think that what most people are looking for and expect are ethnicity estimates that align closely to their genealogical research. Gigatrees provides exactly this sort of estimate by calculating ethnicities based on the known birth locations of each individuals' root ancestors.

Gigatrees does this by calculating the percentage of ethnicity (not DNA) that each ancestor contributes to their descendant. The algorithm will use the location of an ancestor's earliest event when no birth location can be found. If no location can be found, "Unknown" is used. The algorithm also handles single consanguineous relationships seamlessly, multiple levels are reported as "Duplicates". This method is obviously limited by the available ancestors and the accuracy of each genealogist's research. Given these limitations, however, the ethnicity estimates calculated by Gigatrees fall directly in line with what most people think when think "Ethnicity."

Data Consistency Validation

Gigatrees includes support for data consistency validation. The applications will compare claims between related individuals in your database to determine when those claims are impossible, improbable, inconsistent or have missing data. They will generate a report including the results. Gigatrees will integrate the report into a complete family tree so that individuals in the report are linked to their profile pages. Those individuals' profile pages will highlight the claims that have been flagged. Estimated birth years are not used when comparing vital claims.

The following data consistency tests are performed during Data Validation and shown on your Data Validation page.

  • Persons born after they were baptized
  • Persons born after they were married
  • Persons born after their children
  • Persons born after they died
  • Persons born after being buried
  • Persons born after one of their parents died
  • Persons born after one of their parents was buried
  • Persons baptized after being buried
  • Persons baptized after being married
  • Persons married after being buried
  • Persons baptized after they died
  • Persons married after they died
  • Parents died before having children
  • Persons died after being buried
  • Persons buried before children were born
  • Persons with multiple parents
  • Persons having an ancestral loop
  • Persons baptized after a certain age
  • Persons married before a certain age
  • Wives married after a certain age
  • Persons living past a certain age
  • Persons who are much older than their spouse
  • Persons having children before a certain age
  • Mothers having children past a certain age
  • Persons having similarly named children
  • Persons having a prohibited kinship
  • Persons having a non-biological parent
  • Persons with unknown genders
  • Families having swapped spouses
  • Persons having inconsistent DNA relatives
  • Persons with invalid dates
Location Processing

Gigatrees Mini will attempt to parse all location descriptions found in your GEDCOM PLACe and ADDRess fields in order to determine which state and country name (and their international alternatives) is being referenced by each. Gigatrees recognizes ISO 3166 place names and 3-letter abbreviations.

These names are used in the following sections: census tables, ethnicity estimates, generation lists and the location pages. In order for Gigatrees Mini to recognize these names, the LocationFile configuration option be set to point to the location file (gigatrees-locations.sqlite) located in the installation folder.

While parsing the location descriptions, Gigatrees Mini will also reformat the description by filling in missing country names, and adding commas and spacing, etc. If you prefer to use your original descriptions, you can remove the path to the locations file from the LocationFile configuration option. Doing so, however, will limit the detail shown in the above named sections.

If you are using names in your location descriptions that do not meet the ISO 3166 standard, which is often the case with international users, you can edit the names found in the location file by using a SQLite3 editor to modify the database.

DNA Analysis

By now most of us have taken a DNA test with one of the major testing companies, all of which provide the tester with a list of DNA matches, those other testers to whom the tester is related. In the details for each relationship is found the total segment length of shared DNA, the number of matching segments, and sometimes, the length of the largest segment. This is all the information necessary to approximate the degree of kinship between a DNA tester and their DNA match. Knowing something about the DNA matches's pedigree can further determine the range of possible relationships.

Gigatrees Pro supports adding all of your DNA relative details from the various testing companies to your configuration. You do not need to modify your GEDCOM file or genealogy database to make use of this feature, so literally anyone can use it. Preferably, your database will include the ancestors for both your DNA tester and your DNA match up to and including the most recent common ancestor (MRCA). Gigatrees will automatically determine the MRCA, derive the relationship between the DNA tester and the DNA match and create a DNA relatives table. Gigatrees Mini will include the table as a new section on the profile pages for both the DNA tester and the DNA match.

The DNA Relatives Table will include the DNA match's name, their derived relationship, the configured shared DNA details (shared segment length in centimorgans, in percent, number of segments, longest segment and testing company), the probability of that relationship and the name of the MRCA, linked to a DNA Ancestor chart showing the tester's and all their DNA match's descent from the common ancestor. When another relationship has a higher probability than the derived one, a "Suggested Relationship" column will be added to the table. If no common ancestor is found, for instance if the DNA match's full ancestry has not been added, a suggested relationship based on that with the highest probability will be listed and the probability will be listed as a percentage. The percentage may be less than 100% because the higher the degree of kinship between the two testers, the less likely their relationship can be determined with any certainty. The most probable relationship may include several possibilities as the resolution of determination terminates at the degree of kinship. For instance Aunts, Uncles, Nephews and Nieces all have the same degree of kinship. Ages and genders will be used to narrow down the possibility, one of which will appear as a suggested relationship. Just know that other relationships with an equivalent degree of kinship as equally likely.

When derived relationships are not inconsistent, probabilities are converted to levels of certainties where those in the 1st two standard deviations are considered certain, those in the 3rd are probable, those that are not the most probable, and where the most probable relationship is in the 1st two standard of deviations, are questionable, those where the most probable is in the 3rd are uncertain and all others are supported. In inconsistent relationships, the highest probability will be zero. In this case the certainty will be impossible and the entry will be flagged in the table. It will also be added to the Data Validation page so that all inconsistent relationships can be found easily. DNA Analysis handles kinship offsets, half relationships, double cousins, and pedigree collapses.

To get a understanding of what information is included, take a look at these samples images. The first sample image shows a portion of a DNA Relative report taken from the author's actual family tree. The second image shows one of the many DNA Ancestors chart automatically generated. Anchors are used to indicate consanguineous relationships. Anchors are specific to each chart. The first anchor in each chart will always be 'A' and will increment through the alphabet for subsequent ones.

To use the program, you must configure the DnaProbabilityFile and the DnaDataFile options. If you are using this feature simply to suggest the most probable relationship for persons whose relationship is not known, a GEDCOM file is not necessary. The DNA Pool Analyzer can be used for this purpose as well.

The DNAProbabilityFile is used to calculate the probabilities that a given total shared segment length of DNA will be associated with a particular degree of kinship (or cluster). Two probability matrices (spreadsheets and comma-separated files) are provided in the installation folder. You can only import the comma-separated file. The matrices are derived from two sources. The first table was taken from an article on Dr. Leah Larkin's website, "The Limits of Predicting Relationships using DNA", The DNA Geek, Dec. 19, 2016 (accessed Oct. 28, 2018), . The author used a charting tool to re-engineer a probability chart published by The second table was taken from Jonny Perl's "The Shared cM Project 3.0 tool v4", . He states that the data was taken from Dr. Blaine Bettinger's "August 2017 Update to the Shared cM Project", Blaine T. Bettinger, Aug. 26, 2017, (accessed Oct. 28, 2018), . An in-depth analysis of Dr. Bettinger's raw data can be found in his PDF file. The raw data for the Shared cM Project was gathered by user entry. A link is provided on his website if you would like to contribute.

There are some obvious issues with both tables. In the case of the first, Ancestry's original chart contained low resolution data. The conversion method, although genius in idea, undoubtedly suffers from the accuracy of the tool used, the accuracy and resolution of the image scraped, and one's ability to use the scraping tool properly. Dr. Bettinger was clear on some of the issues with the second matrix's data.

Data entry errors - some of the information entered by participants is affected by data entry errors (for example, a longest segment greater than the total shared cM). When these entries could be definitively determined, they were removed.
Incorrect relationships (known or unknown) - some relationships were almost certainly entered incorrectly, which might be due to misunderstandings of "removed" relationships in genealogy. Other relationship errors were clearly due to misattributed parentage events resulting in the believed relationship being incorrect.
Endogamy and Pedigree Collapse - Some relationships will be affected by endogamy and/or pedigree collapse, which will increase the amount of DNA shared by test-takers having a certain genealogical relationship. Although the collection form requests information about known endogamy and/or pedigree collapse, many contributors will not be aware of the endogamy and pedigree collapse in their tree. Additionally, some participants may have selected only one relationship although there were several known relationships.
Company Thresholds - Each of the DNA testing companies applies a different matching threshold to maximize the identification of genetic cousins while minimizing false positives. These thresholds may impact the total amount of DNA shared by two test-takers, especially at more distant relationships.

The DNA Data file is tab delimited making it easy to export from a spreadsheet. You can view the sample DNA data files provided in the distribution for an example. The following fields are available for data entry: DNA Tester, DNA Match, Shared DNA, Shared Pct, Number of Segments, Longest Segment, Testing Company, Comment, Notes. When adding DNA testers and DNA matches you can enter their name or GEDCOM record ID. If you enter their name, it must be unique in the database (or the wrong person might be found when looking up their name). If they do not have a unique name, you may be able to use your genealogy editor to add an additional unique name for that person. Using the GEDCOM record ID will eliminate lookup errors. You can include any number of DNA testers and DNA matches in a single file. You can even add the same persons multiple times if, for instance, different testing companies provide different shared DNA details. The Shared DNA and Longest Segment can be entered in either centimorgans (cM) or percent (%). Centimorgans is assumed if no units are present. The units are NOT case sensitive and do NOT need to be delimited by a space. The shared DNA details can include additional free-form text after the units, for instance, 1234 cM (34 segments). The Comment field supports hotlinking of URLs. The Notes field and all columns that follow it are ignored (not processed).

To help simplify the process of creating your DNA Data file, the DNA Match Manager, by Heirloom Software, allows exporting DNA match data from various testing companies into a spreadsheet, which after reordering the columns slightly can be exported into a tab delimited DNA Data file.

Gigatrees and the DNA Pool Analyzer automatically sends derived relationship and associated total and shared DNA segment length data to the server at run-time. This information is sent anonymously and generically so no user information is collected. The accumulated statistics can be see on the DNA Statistics page where various properties associated with those relationships such as sample size, maximum, minimum and average values, variance and the standard deviation are displayed. The intent is to behave similarily to the Shared cM Project, but using automatic reporting.

Gigatrees attempts to solve the issue with report accuracy indicated above by deriving the most common recent ancestors (MRCAs) automatically. Gigatrees cannot solve every problem however. Shared DNA segment lengths vary between testing companies. This is partially because they are calculated as a ratio to the total chromosome length tested between individuals. Gigatrees will calculate the total chromosome length when parents or children are included as part of the dataset, but there will undoubtedly be times where the value is not known. Gigatrees also assumes that the total chromosome length, even when known applies to all configured DNA matches. This is probably not the case. Testing companies do not necessarily always use the same value for every DNA match and configurations may include DNA matches from several different testers having slightly different values. Another possible problem is that users may have added their DNA matches to their tree incorrectly, leaving off or adding extra generations, or be unaware of consanguineous relationships in their ancestry. Users may also have used the tools to test out scenerios and hypotheses by forcing connections in their tree. All of these can cause outliers to occur. To address the issues of outliers, there are several techniques that can be used to eliminate them from calculations. The first is to toss entries that fall several standard deviations from the average. This assumes that the normal distribution is a symmetrical bell curve. The is a valid assumption, but only when the sample sizes are large. Outliers in small samples skew the results significantly. Another method is to extract the quartile values from the data, determine cutoff values based on their difference and discard those falling outside the lower and upper limits. A third method is to measure the variance in the data and when above a threshold, use the median absolute deviation (MAD) instead of the standard deviation. The advantage of the median absolute deviation is that it reduces the effects of outliers when calculating deviation results. This is because when small samples are being used, outliers have significantly more influence on the average than they do the median. Having summarized these methods, I should note here that I am not a statitician and there may be other statistical tools that would better serve both small and large DNA samples. The DNA Statistics tables can be used by genealogists to gain some insights into the correlation between biological relationships and DNA segment sizes. Bear in mind that the database is new, extremely small, and therefore cannot currently be used in making predictions.

In the first table, the first three columns show the calculated relationship and the generation where the first pedigree collapse occurred. The collapse generation includes both the tester's generation and the generation where consanguinity first occurs. Together these constitute a unique relationship type. The cluster numbers align roughly with relationship distances. The 4th column shows the number of times that a unique relationship has been submitted (or sample size). Sample sizes less than 400 have a 5% or higher error band and therefore cannot be used with any real confidence. Sample sizes above 10,000 do not provide any significant additional confidence. The remaining columns show the minimum, median and maximum values along with the 25% quartile (Q1), 75% quartile (Q3) and the upper and lower cuttoff values. As you can see from this table, the sample sizes are still too small to make the cuttoff values of any use in eliminating outliers.

In the second table the mean (or average) and the delta (Δ) are included. The delta, as I've defined it here, represents the percentage difference between the mean and the median. Large deltas indicate a skewed distribution due to a large number of outliers falling to either side of a normal distribution curve. The variance is also included and indicates how outliers flatten a normal distribution curve. Sigma (σ) is the symbol for standard deviation and is calculated from the average and total values for each relationship. Because the sample sizes are still so small, significant delta and variation can be seen for some relationships. The mean absolute deviation (MAD) is calculated using a normalizing coefficient [Wikipedia, Oct. 1, 2018, (accessed: Nov. 4, 2018),], and is used to reduce the effect that outliers have on the distribution functions for those relationships. The final three columns show the range of segment values as a ratio of their total chromosome lengths, for several confidence levels. The column for 100% uses a standard deviation value that should result in no errors for a total population size aproximating the total number of DNA tests conducted by all testing companies (10 million). The confidence level is important because users of these tables are looking to verify that the length of a total shared DNA segment with one of their DNA matches is valid. A confidence level of 99% means that out of all the DNA tests conducted so far worldwide, 100,000 of those matches might fall outside this specified range. A confidence level or 100% indicates that none should fall outside that specified range.

In the third table, the ranges of absolute segment lengths for each relationship type are shown based on the confidence level calculations from the previous table and using 6900 cM as a sample total chromosome length value. When the sample sizes become large enough to warrant it, I will make the live distribution curves available so that users and developers will be able use the results to build reliable prediction algorithms.

Pro: Going Pro

Gigatrees Pro is scaled-up version of Gigatrees Mini. It is now freely available to all users. The only disadvantage of using Gigatrees Pro, is that it is more complex to configurem which may be a deterent for many users. Where Gigatrees Mini only has a few configuration items, Gigatrees Pro has well over 100 and requires a special configuration interface to setup the configuration. Gigatrees Pro includes full internal support for DNA analysis. It extends the support for data consistency validation by providing additional tests and allows for editing the parameters used in its algorithms. It also includes an integrated blogging platform so that embedded references can access individual records as well. Gigatrees Pro allows you to fine tune the contents and look of your family tree. It includes support for several new page types including a photo gallery, a population distribution map, individual origin maps, census tables, ancestor, generation and descendant lists, immigrants, military and nobility pages, century timelines, and a statistics page. Gigatrees can be configured to generate pages in either HTML or PHP. PHP pages are saved in an SQLite3 database file for dynamic page serving reducing your website footprint to just a few files. Gigatrees allows for extending the navigation bar, supports plugins for integrating well-behaved third-party scripts, and supports seamless integration into existing websites and content management systems like WordPress. Gigatrees Pro has advanced location processing, including the ability to automatically determine the coordinates for every location in your database and to override location coordinates when necessary. Perhaps the biggest difference between it and Gigatrees Mini is that it has a user interface that can be used to load, edit and save configurations, and run the console program. The user interface includes embedded help for every option by clicking on the option title. Note that the configuration interface may not include every configurable parameter; if an option is mentioned in this documentation does not appear in the interface, then it must be entered manually into the configuration file. Manual changes to the configuration file, such as these, will be preserved when the file is loaded into the confiruation interface and then re-saved. These are just some of the highlights available in Gigatrees Pro. The best way to get a feel for its full feature set is to download it and try it.

To begin, double-click on gigatrees.bat in your installation folder. This will load your configuration interface. You will need to browse for your Input File (GEDCOM) on the main page, and browse to your Output Path. Press F2 to save your changes and then F5 to run the application. When the application finishes, Ctrl-1 will load the build long in your default text editor, and Ctrl-2 will open your output's home page in your default browser. You may also run the sample.bat file to build a complete family tree using the sample configuration file.

Registered users (I am no longer acepting new registrations) may find the Gigatrees Dashboard at The Dashboard includes access to some user data statistics.

Pro: Dynamic Page Serving

Gigatrees Pro generates web pages in HTML format by default. This allows you to view your pages in your browser offline by clicking on them or accessing them through the application View menu. Gigatrees may however create thousands of separate files which makes deployment to online servers difficult (although this can be alleviated by adding all the files to a single Zip before uploading, and then extracting that Zip file on the server). A better option is to use Gigatrees to store your family tree pages in an SQLite3 database and then host that database on your web server. This will require that your web server supports SQLite3 and PDO extensions. This is standard for Apache servers and easily enabled if not done so by default. Consult your hosting service or web server documentation for instructions. Setting up a website for dynamic page serving is not for the faint of heart and usually requires some technical know-how. I cannot provide support beyond setting up your Gigatrees configuration here. Incidently, Innuendo also now supports dynamic page serving.

In order setup dynamic page serving, you need to make several changes to your configuration. First, you will need to set the Enable Server Database option to true. You also need to set the ServerDatabaseName to your database a filename. Any valid filename will do. The extension should be ".sqlite". For example: my-database.sqlite. You will also need to set the LocalDatabasePath option to a folder on your computer where you want the database stored. This is necessary for the application to find and use when building your website. This path is not used at run-time. Lastly, you will need to set the ServerDatabasePath option to the path on your server where you will be storing your database. This path IS used at run-time. The path can be specified as an absolute or a relative path. This is your server path, so make sure you get your slashes correct. A trailing slash is required. Generally, you do not want to store your database into a public folder on your server, lest someone try to download it directly, although you can prevent this by disallowing direct access to the file. I will be discussing this a bit later.

Now that you have your setup complete, you will want to save your configuration and then run Gigatrees Pro. The first time you run the application it will ask you to create the database - do so. When the application finishes, your output folder will include several PHP files and an HTACCESS file (.htaccess). The HTACCESS file is an Apache Web Server specific file. If you are using a different server, you will need to convert this file to a similar file compatible with your server.

The HTACCESS file is the first thing loaded by the Apache server when retrieving a web page request from a browser. Your HTACCESS file contains three small sections of server code. The first section prevents direct access to itself, your database file and your configuration file, though I would not recommend uploading your configuration file to your server. The second section prevents visitors from viewing the content of your server's directories. The last section forwards all requests to URLs that are not otherwise found, to the Router (router.php) for processing. If a file associated with a URL is found, it will be called directly instead of searching for it in the database. This allows you to include other web pages within your website structure.

## Prevent direct access to private files
<FilesMatch "\.(htaccess|sqlite|xml)$">
order allow,deny
deny from all

## Prevent direct access to directories
Options +SymLinksIfOwnerMatch -MultiViews -Indexes

## Redirect missing files and directories to router
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ router.php

The Router is the primary URL handler for your application. Its function is to parse the URL, extract the web page filename, lookup that filename in the database, read out the contents, assemble the page (prepending the Header, appending the Footer, and making any last minute macro substitutions) and then send it to the requesting browser. At the top of the Router file, are included two other files: includes.php and pdodriver.php. The Includes file simply defines the database server path that you setup in your configuration, for instance define ('GIGATREES_PAGES_DB', '/databases/my-database.sqlite');. This allows the router to use a named constant to locate the database. The PDO driver file provides handlers that allow the router to read data from the SQLite3 database using PDO extensions. The Header (header.php) and Footer (footer.php) files were created from your Metadata and Plugins configuration and are kept separate allowing for last minute changes without rebuilding your website. Also, when the application runs, it does not overwrite pages that have not changed making the build process much faster. Keeping the Header and Footer separate means that you can change them without affecting the changed status of your page. The same holds true for making changes to stylesheets.

All that is left to do, is to deploy your website. This generally means you will use FTP or some type of SSH connection to copy your website into a folder on your server. This will include your database file, the HTACCESS file, the 5 PHP support files, the assets folder, the plugins folder (if you have any), and if you have a blog, the blog folder, which contains your feed.rss file. Once deployed, you should be able to load your website using the your domain name and the folder name you selected in your URL, for example:

Pro: Extending the Menu

Gigatrees Pro gives you several options for extending the navigation bar. Like Gigatrees Mini, the navbar plugin can be removed or replaced with your own hand-crafted menu. In Gigatrees Pro you can disable the Menu Bar, which does the same thing. By default the navigation bar is floating (it scrolls with the page). Gigatrees Pro gives you the option of setting it to Fixed which will adhere the navigation bar to the to of the browser window so it remains on screen at all times. Lastly, you can extended the menu to add additional items as shown in the image below.

Pro: Integrating Your Gigatree With WordPress

The following settings can be used to integrate Gigatrees Pro into a self hosted WordPress blog. Other blogs should work similarly. Dynamic page serving must be configured as discussed above. If you plan on using the WordPress navigation bar, then the Menu Bar option in Gigatrees Pro will need to be disabled. If you still plan to use Gigatrees navigation bar, then the Fixed option should be unchecked (floating) so that the menu bar does not interfere with the blog's header.

The Header and Footer options will also need to be modified to load the blog's header and footer. This can be done directly in the configuration file. Any third-party scripts such as loading the Google Maps API (for maps),FancyBox (for photos) and D3/C3 (for charts) will need to loading using the WordPress configuration.

For WordPress, the Header should be set to:

<h1 id="gt-page-title">%PageTitle%</h1>

For WordPress, the Footer should be set to:

Pro: Embedded References

Embedded references are shortcodes that can be used to create automatic links to records such as blog posts, media images, sources and individuals. Embedded references are in the form of {ref:id[#item][@description]}. In all cases, the "id" refers to the record id.

Referencing a blog post will display the post's title by default. The "description" can be used to provide alternate link text, and the "item" can be used to provide a link to a named anchor in the post's content. For instance, {ref:POST1#footnotes@"Footnotes"} can be used to provide a link to the footnotes section of a blog post. When providing a reference to another post, a link to that post will be added to the other post's Related Posts section.

Similarly, when referencing an individual's record id, their personal name will be displayed by default. The "description" can be used to provide alternate link text, and the "item" can be used to provide a link to a named anchor in the person's profile page. For instance, {ref:I100#census@"his census table"} can be used to provide a link to the census table section.

For sources, the source title is displayed by default and the "item" refers to the referenced page number. Specifying {ref:SOURCE1#23@his obituary} would provide a link to the source, embed the page number in the citation, and label it "his obituary". The SourceTemplates option can be used to provide detailed source citations and formatted footnotes.

For references to media images, the image is shown by default without a caption. The "description" can be used to provide a caption. The "item" can also be used to alter the default behavior, and may contain multiple parameters delimited by periods. The item can be set to title, caption or credit to use any of the defined strings. If not otherwise specified, the medium image will be displayed. You can use the item field to specify an alternate image using large or small. You can also use the item field to specify an alternate width for the media image using wXXX. Also by default, the image is left-aligned. You can use the item field to specify an alternate alignment using center, floatleft or floatright. Lastly, by default, the image is hyperlinked to the largest media size defined. You can use the nolink option to prevent this behavior. Since multiple item fields will often be necessary, the items should be delimited by periods as in

You can also add text footnotes also by leaving off the "id" and providing a "description" only in the form of {ref:@description}. The footnote will be added to the footnotes section at the bottom of the post. The footnote will also be shown when hovering over the footnote number.

An additional feature is to use embedded references to provide help text in the form of {ref:?description}. In this case the "description" is the help text. A footnote will not be created, and the footnote link will display a question mark.

Pro: Blogging

Gigatrees Pro has built in support for an integrated blog. If you are looking for a stand-alone blog, you can use Innuendo; it works similarily.

When editing a blog post, you have options to set the base filename (slug), publication date and time, modification date and time, author, abstract or summary, a featured image id, a category, multiple external hash tags and multiple keywords. Hash tags can also be embedded within post content. You can also specify to exclude the specific post or just its content from the feed, hide the post on public sites, from the index, or from the related posts area, and put the post in draft mode so that it will not be included in the generated blog. You can also choose to remove extra line breaks on per post basis, and hide the featured image on the actual post.

The SourceTemplates and Source option can be used by documentation heavy blogs to setup reusable source citation templates for use in the footnotes of your blog posts, and accessed via embedded references. The SourceTemplates and Source options are not discussed here but there use is demonstrated in the source.xml sample configuration file.

Embedded references can be used by blog posts to create automatic links to other blog posts, media images, and sources. Media images can be added using the Media gallery option. For instance, {ref:POST1#footnotes@"Footnotes"} can be used to provide a link to the footnotes section of a blog post and {ref:SOURCE1#23@his obituary} would provide a link to the source, embed the page number in the citation, and relabel the link. The SourceTemplates option can be used to provide detailed source citations and formatted footnotes.

The Blog option allows you to specify the number of post links to include on the index pages and on your feed, you can set the auto-generated abstract length, sort order and minimum hashtag size. You can enable/disable the feed, include/exclude post content from feeds, prepend category names to filenames, override filenames, and remove extra line breaks (when embedding HTML, see below).

Blogging includes pagination on the index pages, and allows embedding HTML tags into post content. It will auto hotlink all URLs it finds in the text and images will be opened using the FancyBox jQuery plugin. It also supports hash tags. Whenever it finds a pound sign (#) followed by text, it will flag it as a hash tag. Dashes in hash tags are converted to spaces when displayed. Hash tags can also be added outside of a post in the configuration. Separate index pages are created for each hash tag, category and author found in your blog. Hash tags in your text are automatically hotlinked to their index pages. The category and author are also linked at the top of your posts and on the index pages, and the hash tags are linked at the bottom. In addition, the author, category and hash tag index pages are listed and linked at the bottom of the main index below the pagination element.

By default, blog indexes are sorted by reverse publication date. They can be configured to be sorted by either reverse modified date or record id. Publication and modified dates are shown in long format (i.e. January 12, 2001) by default. Gigatrees Pro supports a Short Dates option to force showing the dates in short format (i.e. Jan 12, 2001).

Gigatrees Pro allows you to specify an abstract to display on the index page along with the blog post's title. When no abstract is specified, one will be created automatically from post content. HTML tags are stripped from all abstracts.

If you are embedding HTML in a blog post, you will find Gigatrees Pro treats all carriage returns (or newlines) found in text as HTML break characters. Unexpected line breaks can occur in text because many tags such as header (<h>), page (<p>), and blockquotes have implied line breaks built into their opening and closing elements. To minimize these unexpected breaks, you generally need to butt HTML tags up against one another rather than putting them on separate lines. The configuration has a CleanLineBreaks option that will convert multiple breaks to single breaks, and remove extra breaks around some of the more common HTML opening and closing tags. When this option is enabled, you can still force extra breaks by adding the HTML non-breaking space character entity (&nbsp;) to a blank line. The CleanLineBreaks option only works if the HTML tags contain only breaks between them and no white-space. Gigatrees Pro also supports wrapping text blocks in [[[ and ]]] elements to prevent cleaning line breaks in those blocks. This can be useful when embedding Javascript or other code where spacing and breaks matter.

Pro: Source Citation Templates

Gigatrees Pro allows users to define source citation templates in order to extend their existing source metadata without needing to modify their GEDCOM file or their original database. This is useful for users whose favorite genealogy editing application does not support these features and for users whose genealogy application may export metadata, but not templates. Source citation templates are used to format how source citations are displayed when viewing a source, hovering your mouse over a source reference, or in blog post footnotes.

Gigatrees supports 4 template fields, Source Citation, Footnote, Short Footnote and Ibid Footnote. The default template (T0) was designed to include all supported source citation elements as optional. You will only need to define new Source Citation templates if the default template does not meet your needs. Brackets "{" and "}" are used to delimit conditional statements and the percent symbol "%" is used to delimit source citation elements. If none of the the source citation elements specified within a conditional statement are defined, the entire conditional will be discarded. Text and HTML may be included.

The default template Source Citation field is designed to include all possible elements.

{%Jurisdiction%}{, %Series%}{, %SocietyInfo%}{, %Collection%}{, %Author%}{, %SuplAuthor%}{ (%SuplRole%)}{, %Creator%}{, %Compiler%}{, "%DatabaseTitle%%Title%: %Subtitle%"}{, vol. %Volume%}{, pp. %PageRange%}{, %Format%}{, %Media%}{, (%PubPlace%: %Publisher%, %PubDate%, %Edition%)}{, %WebsiteOwner%}{, %WebsiteCreator%}{, <em>%WebsiteTitle%</em>}{ (%WebsiteUrl%: accessed %AccessDate%)}{, %Periodical%}{, %Section%}{, %Type%}{, %RecordType%}{, "%RecordTitle%"}{, pp. %RecordPageRange%}{, %ItemofInterest%}{, %RecordDate%;}{ p. %RefPage%}{, <br/><em>"%Quotation%"</em>}{, %Remarks%}{, %Annotation%}{, %Detail%}{, %RepositoryLocator%}{, %Repository%}{, Original data: %Original%}.

The Footnote field is used to define the format for the source citation that will appear when sources are shown as footnotes. This template will only be used for the first footnote referencing that particular source. The default template is identical to that of the Source Citation field.

The Short Footnote template field is used to define the format for the source citation that will appear for subsequent footnotes referencing that particular source.

{%Jurisdiction%}{, %Series%}{, %SocietyInfo%}{, %Collection%}{, %Author%}{, %SuplAuthor%}{ (%SuplRole%)}{, %Creator%}{, %Compiler%}{, "%DatabaseTitle%%Title%"}{, vol. %Volume%}{, pp. %PageRange%}{, <em>%WebsiteTitle%</em>}{, %Periodical%}{, %Section%}{, "%RecordTitle%"}{, p. %RefPage%}{, <em>"%Quotation%"</em>}

The Ibid Footnote template field is used to define the format for the source citation that will appear for "ibid" footnotes. The Ibid Footnote template will be immediately preceded by the word ibid., so it should not be included in the template.

{(p. %RefPage%)}{ <em>"%Quotation%"</em>}

Creating source citations templates is more art than science. Elizabeth Shown Mills' book, Evidence Explained provides some ready examples. The sample configuration file contains several example templates derived from the Evidence Explained website. When defining a new template, you must give it a unique record id (i.e. EE94). The following example shows the source citation template fields for EE94: Archived Material: Digital Archives.

Here are some additional examples

Source Citation = "%Collection%." %Format%. %WebsiteOwner%. <i>%WebsiteTitle%</i>. %WebsiteUrl% : %AccessDate%.
Footnote = "%Collection%," %WebsiteOwner%, <i>%WebisteTitle%</i> (%WebsiteUrl% : accessed %AccessDate%), %Format%, "%Title%," p. %RefPage%; crediting "%Original%."
Short Footnote = "%Collection%," <i>%WebisteTitle%</i>, "%Title%," %RefPage%.

Source Citation = %WebsiteOwner%. <i>%WebsiteTitle%</i>. %Format%. %WebsiteUrl% : %AccessDate%.
Footnote = %WebsiteOwner%, <i>%WebisteTitle%</i> (%WebsiteUrl% : accessed %AccessDate%), %ItemOfInterest%, cititing %Original%.
Short Footnote = <i>%WebisteTitle%</i>, %Format%, %ItemOfInterest%.

Source Citation = %Jurisdiction%. %Collection%. %Section%. %RecordTitle%. %PubPlace%: %Publisher%, %PubDate%.
Footnote = %Collection%, %Jurisdiction%, %Section%, %Volume%, %RecordPageRange%, %ItemOfInterest%, %Detail%, %RecordTitle%.
Short Footnote = %Collection%, %Jurisdiction%, %Section%, %Volume%, %RecordPageRange%, %ItemOfInterest%, %Detail%.

Source Citation = %Jurisdiction%. "%Title%". %Type%. %WebsiteOwner%. <i>%WebsiteTitle%</i>. %WebsiteUrl% : %AccessDate%.
Footnote = %Jurisdiction%, "%Title%," %Type%, %WebsiteOwner%, <i>%WebisteTitle%</i> (%WebsiteUrl% : accessed %AccessDate%), %ItemOfInterest%; citing %Original%.
Short Footnote = %Jurisdiction%, "%Title%," %ItemOfInterest%.

Source Citation = %Jurisdiction%. %Collection%. %Repository%. %Format%. %WebsiteOwner%. <i>%WebsiteTitle%</i>. %WebsiteUrl% : %AccessDate%.
Footnote = %Jurisdiction%, %Collection%, %Section%, %RecordTitle%, %RecordPageRange%, "%ItemOfInterest%," %RecordDate%; %WebsiteOwner%, <i>%WebisteTitle%</i> (%WebsiteUrl% : accessed %AccessDate%).
Short Footnote = %Jurisdiction%, %Collection%, %Section%, "%ItemOfInterest%."

Source Citation = %Author%. "%Title%: %Subtitle%." <i>Collection</i> %Volume% (%PubDate%). %Format%. %WebsiteUrl% : %AccessDate%.
Footnote = %Author%, "%Title%: %Subtitle%," <i>Collection</i> %Volume% (%PubDate%), %Format%. (%WebsiteUrl% : accessed %AccessDate%), ItemOfInterest.
Short Footnote = %Author%, "%Title%, %ItemOfInterest%.

Pro: Source Citations

Gigatrees also includes support for a Source Citation option where your can specify the Source record id for an existing source, and then either specify the source template id to associate with that source, or define the 4 source citation templating fields directly. When defining these directly, you can use the the source citation elements shown in the previous section, or enter free-form citations directly. This is convenient for use with many online source providers like or where they often provide free-form source citations for you. You can also use this option to define a Source Type, Source Category or any of the fields used as substitution in the source templates described above: Jurisdiction, Collection, Author, Supplemental Authors, Title, Subtitle, Volume, Page Range, Format, Section, Publication Location, Publisher Name, Publication Date, Website Owner, Website Title, Website URL, Access Date, Record Type, Record Title, Record Page Range, Record Item of Interest, Record Date, Detail, Repository Locator, Repository and Original Source.

The list provide does not include every possible metadata field described in Eviodence Explained, so for specializations, it may be necessary to commandeer an element for another use. For instance if you are creating a Census template and need an element to indicate "enumeration district", you may want to use Collection since that element would not normally apply. Every element is a simple text string, so as long as your template matches your elements, the names of the elements do not really matter. I have tried to provide a comprehensive, but not exhaustive, set of options.

In addition to the elements listed above, Gigatrees supports additional fields that may already exist in your database as part of your source record including: Series, Society Info, Supplemental Author Role, Creator, Compiler, Database Title, Media, Edition, Website Creator, Periodical, Type, Remarks and Annotation. For source references, the RefPage and Quotation elements are also supported. These can all be used in your templates, even though they do not appear in the configuration dialog.

Source records can be referenced from any blog post or note field found in your GEDCOM file (including embedded notes) using embedded references in the form of {ref:id[#page][@description]}. The brackets "[" and "]" indicate optional components. The "id" is the Source Id of the source you want to reference. An example of the simplest reference is {ref:S1}, where the Source "Title" element will be substituted for the link. To specify a page number you would use {ref:S1#33}. When the page number is specified in this manner, it will be used for the RefPage source citation element in the template. If there is a matching page number in the source, and there is a source quotation for that page, it will be used for the Quotation source citation element in the template. To provide an alternate description (instead of the source's title) in context you could use something like {ref:S1#33@his census record} or {ref:S1@obituary}.

Another way to use Source Citations is simply to extend the details of an existing source. For instance, I do not define Source Templates myself as I find the built in default template described under Source Templates to be sufficient for my needs. I do however often wish to add additional details to a source in my database. A typical example is the following source record for the 1850 census taken from In this example, I did not use the website's free form source citation provided the references I have to this source, so in order to cleanup the citation that appears on my website, I added the following:

<Id> S1092 </Id>
<Title> 1850 United States Census: Illinois, Fulton, Vermont </Title>
<Format> [database on-line] </Format>
<PubPlace> Provo, UT, USA </PubPlace>
<Publisher> Operations, Inc. </Publisher>
<PubDate> 2009 </PubDate>
<Details> Images reproduced by FamilySearch </Details>
<Repository> </Repository>
<Original> Seventh Census of the United States, 1850; (National Archives Microfilm Publication M432, 1009 rolls); Records of the Bureau of the Census, Record Group 29; National Archives, Washington, D.C. </Original>

In the above example, the actual Source record Id is used so Gigatrees knows which record to modify. The Title field is not necessary, since the record should already have a title, although if you modify it here it will be used instead of the one in your database, but I add it so I know which record I am referencing. You could also comment this line out by wrapping it in <!-- and --> tags. The other reason I had for modifying this source was because I also referenced it from a Blog post using Embedded References. Like I mentioned above, I could have also added a Source Category here, but my genealogy application already uses Source Types so it wasn't necessary.

Another useful feature provided by Source Citations option is that it can be used to add a privacy flag without the need to create a separate Append Records property. This is don in the dialog by clicking the box at the bottom of the age labeled Hide this source on public site. You would obviously want to do this if your source was still under copyright, or it contained sensitive information about persons still living.

Pro: Source Types

Like Source Citations, you can define new Source Types and associate them with specific Source Categories and Source Template Ids. This is especially useful for users whose genealogy software supports source types, such as FamilyHistorian.

Pro: Photo Album

One of the new pages types available in Gigatrees Pro is the Photo Album. The Photo Album will include all GEDCOM media images assigned directly to or referenced by individual records. It will not include source and event images. The images are displayed in the same fashion described in Image Handling.

When the photo is clicked on, the image count, scrolling arrows, a control panel, the photo caption and hyperlinks to the referenced persons are displayed.

Pro: Statistics

Gigatrees Pro includes a statistics page that users might find interesting. The first (shown in top chart below) shows the most popular names found in your database for both Boys and Girls, and the most common surnames. When you hover your mouse of any name, the total count is displayed. The Data Validation option supports loading an Alternate Names File where you can group similar names so that, for example, Ann, Anne, Anna and Nancy would appear in these charts as a single name.

The second set of statistics (shown in the bottom chart below) shows the average life spans by gender for each century and the number of life spans counted by gender for those same centuries. These values are used by Gigatrees Mini and Gigatrees Pro in the algorithms for estimating birth years for individuals missing them.

The chart shown uses the free D3-based Reusable Chart Library, called C3.js, which is loaded by default in the Header and Footer. Also loaded is a chart handler script /assets/gigatrees-charts.js, which can be modified by technical users to change colors, legend placement, etc.

Pro: Massaging the Numbers

Gigatrees Pro gives you control over the age and date parameters that are used in the algorithms for estimating birth years for those missing them and for data consistency validation. Data consistency validation will flag as improbable events where any of these values are exceeded. The values shown are the default values, however you should adjust these to align better with your own database. It is always better to keep age ranges as narrow as possible. Widening age ranges results in less accurate birth year estimation. It would be preferable to have the occasional event flagged instead.

Pro: Event Types

Gigatrees Mini and Gigatrees Pro automatically map known GEDCOM event types (birth, death, marriage, etc.) to their Living and Adult states, where each can be set to true, false or unknown.

GEDCOM allows for defining new event types using the Event Descriptor field such as:

2 TYPE Moved
2 DATE JUN 1966
2 PLAC 3501 Orient Drive, North Richland Hills, Tarrant County, Texas

Not all genealogy application support this feature, but for those that do, mapping new event types to their Living and Adult states will improve the algorithms used for estimating birth years for those persons missing them.

Pro: Extending Data Consistency Validation

Gigatrees Pro includes additional data consistency validation tests, some of which are configurable using the Data Validation option.

Show Inconsistent DNA Relatives is always enabled for Gigatrees Mini, but is optional for Gigatrees Pro. This will flag individuals in your DNA Relatives section or page whose calculated probability is zero, or is some cases, when the difference between DNA tester and DNA match generations is too large, indicating that the DNA match may have a duplicate name, and Gigatrees is selecting the wrong person based o that name. Show Unmappable Locations will list all locations whose coordinates could not be found by the lookup service, and all persons who have an event locations referencing that location. This option does not flag these events as inconsistent. If you want to get a list of all persons who have undocumented claims, then you should enable the Show Persons With Unsupported Claims option. If you want a similar list of all persons who have undocumented parents, enable the Show Persons With Undocumented Parents option. If you are looking for where to focus your ancestor hunt, you can Show Persons Missing One Parent or Show Persons Missing Both Parents. The Alternate Names File Path option was discussed under Statistics. Use of the alternate names file is especially useful if you have ever merged two databases and want to find when similarly named children exist. They will be listed under Persons Having Similarly Named Children . For instance, mapping the names Ann, Anne, Anna and Nancy together will then detect if you have an Ann and a Anna assigned to the same parents. Children will not be marked as similar if the death date of one occurs before the birth date of the other. It will however flag children in certain ethnic groups who give all their daughter the same first name (i.e. Maria), but different second names.

Another new consistency validation test is to list Persons Whose Birth Dates Could Not Be Estimated. This option does not flag the birth events as inconsistent, instead the birth event will be missing. There are a lot of reasons this may occur, not all of them problematic. The birth year estimation algorithms are deep-scanning, running recursively over several passes, on each ancestral line, and where each pass uses the estimated birth years from the previous pass. The algorithms take into account vital statistics for both recent ancestors and recent descendants. As I noted in Massaging the Numbers small changes in the dates and age ranges can cause errors to accumulate with each pass. Also since the algorithms are not fanning, estimates can phase shift between adjacent families. The algorithms also use some statistics gathered over the entire database such as average life spans per gender, per century, average age of first marriage per gender and average years per generation per gender. Since these are averages applied as a whole, they will have inherent errors. On the other hand, one incorrect date in an ancestral line can skew the entire line and cause a major phase shift between lines. For all of these reasons it is not uncommon to have many persons whose birth years cannot be estimated. Each person listed will include a list of short codes that can be used to help track down which inconsistencies is causing the error. Sometimes fixing the error is as easy using these to locate the fault date, other times you may need to fill in approximate date for near relatives to solve the issue.

The following is the list of short codes representing dates used in the estimation process.

  • fb = father's birth
  • mb = mother's birth
  • pm = parent's marriage
  • b = birth
  • bp = baptism
  • sb = earliest spouse's birth
  • xb = latest sibling's birth
  • m = earliest marriage
  • cb = child's birth (range)
  • cm = earliest child's marriage
  • pd = latest parents death
  • d = death
  • bu = burial
  • le = living event (range)
  • fe = flourishing event (range)

In the following example, you can easily see that Beatrice's child was married 76 years before she was. In this case you can expect that child to have additional consistency errors. In the second example, Joan was living 92 years after her child was born. When you take into account the likely average years per generation and life spans, she would have been well over 100 years old, and Maximum Life Span is probably set at 100 years.

Pro: Geocoding and Maps

Gigatrees Pro supports two types of Maps: Heatmaps and Named Location maps. The heatmaps (Population Distribution Heatmap and Origin Maps) use a Google map to display the location markers using the latitude and longitude for each location and is overlaid with a density heatmap. When multiple location markers occur in close proximity, they are grouped together and their total count is shown. Zooming in on a map regroups the markers. Clicking the [Toggle Markers] button ungroups as markers. Hovering over a location marker display an information window showing the location name, the coordinates, and hyperlinks to the persons found at that location.

The map display is controlled by the /assets/gigatrees-maps.js script. Technical users can modify the file to change the heatmap gradient, radius and opacity, the initial and maximum map zoom level, map center and bounds, enable roads and in general muck with its look. You may be able to get some tips from the Google development site. The location and group markers are also located in the installation's assets folder and can be replaced if desired.

The Population Distribution Heatmap includes the locations of all dated and undated events found in your database. The Origin Maps are found on the profile pages of individuals who have ancestors and display only the first dated event for each ancestor; usually their birth date, but if missing, a baptismal date or something later is used. This map type gives a representation of where each person's ancestors were born. Gigatrees Pro also allows for disabling origin maps on profile pages to reduce age load speeds and enabling a new origin map age type where you can specify just those individuals for which you want an origin map displayed (i.e. yourself, spouse, parents, etc.).

The Named Location maps appear on the location pages and also use a Google map to display the location marker using its latitude and longitude. When location coordinates are missing, Google will use the location description to perform the client-side geocoding lookup. Google requires an API key to perform this lookup and to display the results. If you see any of the following errors when viewing the named location maps, then Google needs the API key or the API key is misconfigured: Oops! Something went wrong., Cannot load this page correctly; Do you own this site?. To obtain an API key from Google, go to and click on the "[Get Key]" button. You will need to create a dummy project if you do not have one already. If you are viewing your maps online, you will need to set a restriction under HTTP Referrers for your domain path. This restriction will prevent web scrapers from discovering your key and using up your allotment of free queries. If you are viewing your maps offline, no restriction should be necessary.

The following shows the restrictions I used for the Gigatrees Pro Sample Tree (but only if viewing the pages online)*

The API key allows Google to restrict lookups to 25,000 per day for free uses (more than enough). Once you have an API key, you can add it to the Google Maps API Key option. In addition to the map, Location pages also display a timeline for every event found at that location which makes it easy to isolate which individuals might be found at a particular location over any particular time-frame.

If your Google maps are not appearing as expected, I recommend you follow the following procedure on a new installation. This will test that your Google Maps API key is valid and setup correctly.

  1. Double-click on gigatrees.bat located in your installation folder to open your configuration interface.
  2. Go to File->Load Config in the menu and select the sample.xml file also located in the installation folder.
  3. Go to Options -> Modify Gigatrees Config -> Coordinates in the menu, and enter your API key under Google Maps API Key.
  4. Click on Done to close the dialog.
  5. Press F2 to save your config. This will create a new file,sample.bat.
  6. Press F5 to run the program and wait for it to complete.
  7. Go to View -> Website Home Page in the menu to load your website into your default browser.
  8. Go to Locations in your website's menu.
  9. Click on the first location - you should now see a functional Google map.

In order to use the heatmaps maps effectively, all locations found in your database must include associated coordinates. Gigatrees supports configuring automatic geocoding that will query one or more free servers, to resolve any missing coordinates found while processing.

To obtain an API key for the MapQuest geocoding service, you will need to go to , signup and follow their instructions to obtain a Consumer Key and then enter that key into the MapQuest Geocoding Key option in the configuration. To obtain an API Key for LocationIQ, goto , signup and follow their instructions to obtain an AI token and then enter that token into the LocationIQ Geocoding Key option in the configuration.

When Gigatrees Pro runs, it will check each location it finds in your database to see if the coordinates for that location are contained in the database as well. Gigatrees Pro supports vendor specific Location records (_PLAC and _PLAC_DEFN) as well as location Map fields (PLAC.MAP). If it finds coordinates for a location it will use them and go on to the next location. If it does not find embedded coordinates, it will check to see if coordinates for that location have already been added to the locations database file (/includes/gigatrees.sqlite). If it finds coordinates for a location it will use them and go on to the next location. If it does not an find coordinates in the database and if either of the gecoding services are enabled (have an API/Geocoding Key) it will query each service in order, using the location description, until it gets a positive result or until all services have been queried. When it gets a positive result, it saves the coordinates into the location database, uses them and then goes on to the next location. If it does not receive a positive result from any of the geocoding services, it will strip off the most specific term of the location description, such as a street address or town name ,and re-query the geocoding services using the partial description. It will repeat this process, stripping off ever more specific terms until it gets a positive result. This will result in less specific coordinates being cached for a location, such as a town or city center instead of a street address. In this way, only location descriptions that include unrecognizable country names will not be resolvable. Unresolvable locations may re-query the geocoding services each time you run the application. It is important, therefore, that the location descriptions provided by your database can be resolved by at least one of the geocoding services. Genealogists tend to enter their location descriptions in the format they are found in their source materials. This may result in archaic descriptions being entered. Prior to the use of geocoding services this was considered a good practice, however, these services will not recognize obsolete descriptions, so I recommend that users enter only modern location descriptions into their databases, and add the original descriptions to their location fields in the form of a note of some sort. Future genealogy standards will undoubtedly include a separate field for original location descriptions. When upgrading Gigatrees Pro to a new version, the location database file should be copied over to the new installation so that your cached coordinate lookups are retained.

All of the coordinate lookup services that Gigatrees uses throttle requests by limiting how often they can be queried and how many queries are permitted per hour and per day. MapQuest limits queries on free accounts to 15,000 per month and LocationIQ limits queries to 10,000 per month. Gigatrees Pro is therefore limited in how quickly it can resolve missing coordinates. It generally takes running the application several times over a period of days to complete the process for a new database. If Gigatrees Pro hits a restriction for one service, it will try another. If Gigatrees runs into a restriction for all services, it will stop making requests until the next time it is run. Re-running Gigatrees to get around these restrictions will not help, since the limitations come from the external servers. Once all coordinates have been resolved, Gigatrees will stop querying the services. You can monitor the geocoding progress in the build log. It will tell you when the process is complete and if it aborted, the reason. You can also monitor your geocoding progress in the User Data section of the Gigatrees Dashboard

If your heatmaps are not appearing as expected, I recommend you follow the following procedure on a new installation. This will test that your Google Maps API key is valid and setup correctly as well as your MapQuest and LocationIQ geocoding keys.

  1. Double-click on gigatrees.bat located in your installation folder to open your configuration interface.
  2. Go to File->Load Config in the menu and select the sample.xml file also located in the installation folder.
  3. Go to Options -> Modify Gigatrees Config -> Coordinates in the menu, and enter your API key under Google Maps API Key. and your other keys under MapQuest Geocoding Key and/or Location IQ Geocoding Key
  4. Click on Done to close the dialog.
  5. Press F2 to save your config. This will create a new file,sample.bat.
  6. Press F5 to run the program and wait for it to complete.
  7. Go to View -> Website Home Page in the menu to load your website into your default browser.
  8. Go to More->Map in your website's menu.
  9. You should now see a functional Google heatmap.

If you find yourself in this situation where the location description your provided in your database could not be resolved or resolved to a less specific location such as a town or city center instead of a street address, as mentioned above, you can adjust your location description to be more accurate and rerun the program, or you can manually enter the correct coordinates into your database into any one of the standard latitude and longitude fields that the GEDCOM standards support. Some genealogy database editors, however, do not provide this capability, so users are left without this means of resolution. Gigatrees Pro also supports adding coordinates via Location records using the InsertRecords and AppendRecords options. The InsertRecords option allows you to add a new logical record by assigning it a unique id, a record tag (_PLAC), and a value, which in this case is the location description. To add the coordinates, you can append two record field tags (LATI and LONG) to the newly inserted record id, where the value corresponds to the coordinate value. Doing this for a large number of locations using the configuration interface can be cumbersome. It is generally easier to manually edit the configuration file to add these entries. All changes made when editing a configuration file manually will be retained when reloaded into the configuration interface and when re-saved by the interface.

<InsertRecord> <RecordId> L1 </RecordId> <Tag> _PLAC </Tag> <Value> St. Jean Baptiste Catholic Church, Macon, Hainaut, Belgium </Value> </InsertRecord>
<InsertRecord> <RecordId> L2 </RecordId> <Tag> _PLAC </Tag> <Value> London, UK </Value> </InsertRecord>
<AppendRecord> <RecordId> L1 </RecordId> <Tag> LATI </Tag> <Value> 50.6407351 </Value> </AppendRecord>
<AppendRecord> <RecordId> L1 </RecordId> <Tag> LONG </Tag> <Value> 4.66696 </Value> </AppendRecord>
<AppendRecord> <RecordId> L2 </RecordId> <Tag> LATI </Tag> <Value> 51.5073219 </Value> </AppendRecord>
<AppendRecord> <RecordId> L2 </RecordId> <Tag> LONG </Tag> <Value> -0.1276474 </Value> </AppendRecord>