The remainder of this document is divided into the following sections and should be used as a ready reference.
- Common trackDb settings
- Settings by track type – with examples
- Grouping tracks into sets and hierarchies – with examples
- Table of Contents
track |
type |
shortLabel |
longLabel |
bigDataUrl <url/relativePath> |
visibility |
html |
Many settings are valid only for certain types of tracks. Many of these tracks are described below along with settings specific to their types.
type bam |
bigDataUrl <url/relativePath> |
|
Related settings:
bamColorMode <strand/gray/tag/off> |
bamGrayMode <aliQual/baseQual/unpaired>aliQualRange <min:max>baseQualRange <min:max> |
bamColorTag <XX> |
noColorTag . |
bamSkipPrintQualScore . |
indelDoubleInsert <off/on>indelQueryInsert <off/on>indelPolyA <off/on> |
minAliQual <#> |
|
Related settings:
pairEndsByName . |
pairSearchRange <#> |
showNames <on/off> |
|
Additional settings found in the "Item or region tracks" section are also available for displaying bam tags. maxWindowToDraw, |
Example of a bam track
|
type vcfTabix |
bigDataUrl <url/relativePath> |
|
Additional settings found in the "Item or region tracks" section are also available for displaying Variant Call Format tracks. maxWindowToDraw |
|
Example of a VCF track
|
- "multiWig" container: when the tracks are
all in signal (wiggle or bigWig) format and it makes sense to overlay
them.
Example: a set of bigWig tracks with H3K27ac signal, all on the same scale - "composite" container: when the
tracks are expected to be configured together or have an internal
subgrouping, like cell type or cell treatment.
Example: a set of ChIP-bigBeds in three different cell types - "superTrack" container: when the tracks
share no specific configuration and you mostly want to show them
together.
Example: a set of composite tracks or a mix of bigBed, bigWig and bam
superTrack on |
parent <superTrack> |
|
Example of a Supertrack
|
compositeTrack on |
parent <composite> [off/on] |
allButtonPair on |
centerLabelsDense <off/on> |
dragAndDrop on |
|
Example of a Composite track
|
container multiWig |
parent <containerTrack> |
aggregate <transparentOverlay/stacked/solidOverlay/none> |
showSubtrackColorOnUi on |
|
Example of an Aggregate track
|
Track Database Definition
How to declare Dataset Display Settings in the Genome Browser
Hub contributors should use the Hub Track specific version of this document.
This document describes how to declare dataset display characteristics in the Genome Browser through trackDb settings. Introducing new datasets for display in the Browser requires declaring the location and format of the data and defining initial display characteristics. In many cases, you may need to choose how the displayed data (aka "track") may be selected and configured. These settings are declared in a simple text file format and stored in a database called the "track database", or trackDb for short.
The text file format for trackDb settings follow the simple "ra" rules which establish a "record" as a set of related settings in a "stanza" delimited by blank lines. The first line of each stanza typically establishes the "key". Each line in a stanza will contain a single word "setting" name and one or more words or numbers that follow are the setting's "value". All trackDb stanzas are keyed by "track" and most will have certain common settings followed by track specific settings. Here is an example:
track myFirstTrack
type bed 6
shortLabel Example Data
longLabel The data in this track is format "bed 6".
Every track should have
these four settings. The key of this track (myFirstTrack)
is the name of the dataset. If the data is loaded into a MySQL
table then the track name is almost always the table name. If the
data is in one of the remote indexed file types (e.g. bigWig, bam,
etc.) then the name is typically the root file name. However, this
is a key to the track so it must be unique within the Genome Browser.
(Data hubs need only declare track names unique to their hub.)
After the "track" key, the most important setting for
defining a track is the "type". This tells the Browser
which format the data is in, defines how to display it, and determines
which options are available for fine control of that display.
Hub Track Database Definition
How to declare Dataset Display Settings in Genome Browser Hubs
This document describes how to declare dataset display characteristics in a Genome Browser Hub through trackDb settings (please note that hosting hub files on HTTP tends to work even better than FTP). Introducing datasets for display in the Browser requires declaring the location and format of the data and defining initial display characteristics. In many cases, you may need to choose how the displayed data (aka "track") may be selected and configured. These settings are declared in a simple text file format and loaded into the Browser's "track database", or trackDb for short.
The text file format for trackDb settings follow the simple "ra" rules which establish a "record" as a set of related settings in a "stanza" delimited by blank lines. The first line of each stanza typically establishes the "key". Each line in a stanza will contain a single word "setting" name and one or more words or numbers that follow are the setting's "value". All trackDb stanzas are keyed by "track" and most will have certain common settings followed by track specific settings. Here is an example:
track myFirstTrack
type bigBed 3
bigDataUrl myFirstTrack.bb
shortLabel Example Data
longLabel The data in this track is format "bigBed 3".
Every hub track should have these five settings.
The key of this track (myFirstTrack)
is the name of the dataset and is typically the root file name. However, this
is a key to the track so it must be unique within your data hub.
After the "track" key, the most important setting for
defining a track is the "type". This tells the Browser
which format the data is in, defines how to display it, and determines
which options are available for fine control of that display.
trackRequired: Yes
This is the name of
the dataset and must be unique within the Genome Browser or
dataHub. Typically this is the MySQL table name or remote data
file root name (without path or suffix). Must begin with a letter
and contain only the following chars:
[a-zA-Z0-9-_].
Example:
track myFirstTrack
typeRequired: Yes
Declares the format of the data and is used to determine display methods and options.
Valid settings:
altGraphX, bam, bed, bed5FloatScore, bedGraph, bedRnaElements, bigBed, bigWig, broadPeak, chain, clonePos, coloredExon, ctgPos, downloadsOnly, encodeFiveC, expRatio, factorSource, genePred, gvf, ld2, narrowPeak, netAlign, peptideMapping, psl, rmsk, snake, vcfTabix, wig, wigMaf
Detailed descriptions of each type can be found below. In many cases the type setting includes additional parameters to further specify the data format. Some track types have additional setting requirements, to be discussed below.
Example:
type bed 6 +
typeRequired: Yes
Declares the format of the data and is used to determine display methods and options.
Valid settings:
bam, bigBed, bigWig, vcfTabix,
Detailed descriptions of each type can be found below. In many cases the type setting includes additional parameters to further specify the data format. Some track types have additional setting requirements, to be discussed below.
Example:
type bigBed 6 +
shortLabelRequired: Yes
Specifies the track's "short label", which is used in a number of places in the Browser to identify the track. For example, the short label is displayed alongside the track in the Browser image. This label must be brief and is limited to 17 printable characters.
Example:
shortLabel Human mRNAs
longLabelRequired: Yes
Specifies the track's "long label", which is also used in numerous places in the Browser to identify a track. For instance, the long label is displayed above the track's data in the Browser image. This label should be descriptive enough to allow users to uniquely identify the track within the Browser. It is limited to 76 printable characters.
Example:
longLabel Human mRNAs from GenBank
visibilityRequired: No
Visibility (i.e. "display mode") specifies which of 5 modes (including 'hide') should be used to display the track within the Browser image. This setting is almost always dynamically customizable by each user. The exact configuration of the display for each mode depends upon the track's type, and some modes may not be supported for certain track types. Be sure to experiment with this setting to verify that it works as expected for your track type.
Valid settings:
hide: DEFAULT. The track is not displayed in the Browser image unless the user changes the display setting.dense: The track is displayed as a single line or ribbon. In many cases multiple items are summarized or drawn on top of one another, and the long labels are not displayed.squish: Each item is drawn individually, but at half height and without a label. (Not supported for all types.)pack: Items are displayed individually at full height, but in a much more compact vertical space than in full mode. (Not supported for all types.)full: Each item is displayed as a separate line in the Browser image. Graphed signals may be displayed in varying heights.
Example:
visibility dense
htmlRequired: No
Specifies a file that contains the complete description of a track in HTML format. The path of this file name is relative to the path of the trackDb file. The ".html" suffix is implied.
To be consisent with standard Genome Browser track descriptions, this description should contain several sections:
Description
A few sentences describing the contents of the track and what it attempts to show. The description can include additional paragraphs giving further details and can include links to outside sources.
Display Conventions and Configuration
A description of what the display represents. This includes a description of conventions for coloring and any special glyphs used in the track. It may describe how to interpret scores or full signal values. This section can also be used to describe how to customize the display by using configuration controls.
Methods
A description of how the data was generated, which may include how physical samples were treated as well as explanations of data-handling algorithms.
Credits
Names and institutions of those who performed the experiments and/or prepared the data as well as any funding sources. This section should include a contact email address for questions concerning the data.
References
References to any published work referring to or dependent upon this data as well as any sources upon which the work is based or can be understood.
Example:
html docs/myFirstTrack
Common, though less frequently used settings
The following settings are available for many or all track types but are less frequently used. Most are optional, but some may be required for specific track types or in specific situations.\' continuation characters. If the
setting is long or complex, break it into several lines using
terminating '\' characters to make it more readable.
bigDataUrl <url/relativePath>Required: For Hubs
The location of a remote data file containing the bulk of the data for the track. This setting is required for all data tracks in a track hub. It is currently not supported for local tracks.
The setting is either the full URL (including http: or another protocol)
or it is relative to the directory in which the trackDb file containing this setting
is located. The file must be in one of
the supported remote data file formats: bam, bigBed, bigWig or
vcfTabix. Note that bam and vcfTabix types require a separate
index file that must have the same name as the data file plus a
standard suffix (".bai" and ".tbi" respectively).
Example:
bigDataUrl http://vizhub.wustl.edu/VizHub/hg19/biBrainH3K4me1.bbor
bigDataUrl biBrainH3K4me1.bb
boxedCfg <on/off>Configuration controls can be placed inside a box on the configuration page. This setting is decorative only, but can make a busy page look more cohesive. Not all track types currently support this feature, but the most common types do, including wig, bigWig, bed, and bigBed. DEFAULT: off.
Example:
boxedCfg on
canPack <off/on>NOT FOR HUBS. Deprecated.
Most tracks can be displayed in all five
visibilities modes. However on some track types such as
wiggles, the squish and pack modes offer no real advantage
over the dense and full modes. By default, these tracks will
not offer the squish and pack vilibility settings.
Nevertheless, you can make your track offer
these visibilility choices by turning canPack on. Note: subtracks
of composites will always offer all five choices.
Example:
canPack on
color <red,green,blue>Many track types allow the color of the data displayed in the image to be specified with this setting. The setting accepts red, green and blue values, each in the range of 0-255 and delimited by commas. Though this setting is widely supported, some track types in certain display modes ignore it, such as the EST tracks in dense mode.
Example:
color 255,0,0
This example sets the color to red.
altColor <red,green,blue>Many track types allow setting a color range that varies from color to
altColor. For instance the CpG Island tracks use the altColor
setting to display the weaker islands, while the stronger ones are rendered in
color. If altColor is not specified, the system will
use a color halfway between that specified in the color tag
and white instead.
Example:
altColor 0,0,255
This example sets the alternate color to blue.
chromosomes <chr1,chr2,...>Some datasets do not contain data for all chromosomes of a genome. When this is true, use this setting as a comma-separated list of the chromosomes that are covered. The system displays a message that no data is available when the user browses chromosomes not included in this list.
Example:
chromosomes chr1,chr7,chr18,chr19,chr22,chrX,chrM
configureByPopup <on/off>NOT FOR HUBS.
Most track displays that can be configured by a user can also be configured from directly within the Browser image through a right-click option that pops up a configuration dialog. While this functionality works on the majority of track types, some configuration dialogs are too complex or have too much embedded javascript control to be reliably configured through a pop-up. To turn off the ability to configure the track via right-click, change this setting to "off". The user will still be able to configure the track on the track's configuration page. DEFAULT: on.
Example:
configureByPopup off
dataVersion <str>Many tracks undergo multiple revisions over time. In some cases, the older versions should be retained, but even if they are not, it can be useful to declare the current version of the track. Use this setting to display a version statement on the track configuration page and item details page of a track. The string will support limited HTML.
Example:
dataVersion May 2011 <em>beta</em>
directUrl <url>By default, items shown in the Browser image can be linked to a details page giving information about that item. The link can instead go to the URL declared here. The URL is formatted as a printf line including the following fields in this order:
- %s - item name
- %s - chromosome name
- %d - chromosome start position (relative to zero)
- %d - chromosome end position (relative to one)
- %s - track name
- %s - database name
Not all fields need be present, but those present must be in this order, and if a later field is present, all earlier fields must be used. The URL can either be a full external URL or local to the web site.
Examples:
directUrl http://mygenes.org/cgi-bin/geneView/%sor
directUrl /cgi-bin/hgGene?hgg_gene=%s&hgg_chrom=%s&hgg_start=%d&hgg_end=%d&hgg_type=%s&db=%s
hgsid onNOT FOR HUBS.
The "cart" is a hidden table that contains the persistent selections that users have made in the Genome Browser. To ensure your directUrl has access to these cart settings, include the user's Browser ID with this setting.
Example:
directUrl /cgi-bin/hgGene?hgg_gene=%s&hgg_chrom=%s&hgg_start=%d&hgg_end=%d&hgg_type=%s&db=%s
hgsid on
In this example the URL specified by directUrl will have the user's
Browser ID appended so that cart settings will be available.
iframeUrl <url>This setting allows integrating an external html page into the default details page, as an iframe. The usual replacement variables can be used within this URL:
- $$ - ID, will be replaced by the
nameof an item or other string id depending upon the fields in the given track's type. - $T - database table name
- $S - chromomosome name (scaffold name on scaffold assemblies)
- $[ - chromStart location (relative to zero)
- $] - chromEnd location (relative to one)
- $s - chromosome name without chr prefix (or without scaffold_ or Scaffold_ prefix on scaffold assemblies)
- $D - database name (e.g. "hg19")
- $P - item name portion before first : in name
- $p - item name portion after first : in name up to next colon
The URL can either be a full external URL or local to the web site.
In HTML, iframes cannot be resized easily, so the default static size is 1024 pixels. This can be changed with iframeOptions
Examples:
iframeUrl http://www.ncbi.nlm.nih.gov/nuccore/$$
iframeOptions height='600' width='1024'
iframeOptions <string>When iframeUrl is used, this statement specifies a string that is inserted literally into the HTML <iframe> tag. It can include options needed for iframe formatting, like width, height, scrolling, etc.
If the statement is not present, the default is width='100%' height='1024'.
Note: dynamic resizing of iframes is not trivial, as they have to be resized with javascript, across domains. We recommend keeping the size static and to use scrollbars. If dynamic resizing is required, the iframed page has to include a few lines of special HTML and javascript code and one has to modify its body-tag, like this (see stackoverflow):
... html header ...
<body onload="iframeResizePipe()">
<iframe id="helpframe" src='' height='0' width='0' frameborder='0'></iframe>
<script type="text/javascript">
function iframeResizePipe() {
var height = document.body.scrollHeight;
var pipe = document.getElementById('helpframe');
pipe.src = 'http://genome.ucsc.edu/inc/iframeHelper.html?height='+height+'&cacheb='+Math.random();
}
</script>
... rest of webpage ...
Example:
iframeOptions width='800' height='800' scrolling='yes'
This example fixes the size to 800x800 pixels and activates scrollbars.
directUrl <url>By default, items shown in the Browser image can be linked to a details page giving information about that item. The link can instead go to the URL declared here. The URL is formatted as a printf line including the following fields in this order:
- %s - item name
- %s - chromosome name
- %d - chromosome start position (relative to zero)
- %d - chromosome end position (relative to one)
- %s - track name
- %s - database name
Not all fields need be present, but those present must be in this order, and if a later field is present, all earlier fields must be used. The URL can either be a full external URL or local to the web site.
Example:
directUrl http://mygenes.org/cgi-bin/geneView/%s
otherDb <otherDb>Track types that show pairwise alignments often need to declare the other species/assembly included in the alignment. Types that use this setting include bed, chain, netAlign, psl and snake.
Example:
otherDb mm10
This example sets the second assembly in the alignment to the mouse mm10 assembly.
origAssembly <db>NOT FOR HUBS.
The original assembly version for which the dataset was generated. Datasets generated by mapping to one genome assembly may prove useful enough to map to a more recent assembly. Ideally datasets will be regenerated to map to the new assemblies coordinates, but sometimes this is not practical or expedient. Therefore, the dataset may have its genome coordinates "lifted over" to the more recent assembly. In some cases this results in an inferior but nevertheless useful representation. Such datasets should have their original assembly defined with this setting.
Example:
origAssembly hg18
pennantIcon <icon> [html [tip]]Certain tracks can be visually flagged in the Browser by use of an icon and a link to a description of the icon's meaning. The icon is displayed next to the track's short label in the track groups section below the Browser image, and on the track's description and configuration pages. This setting has three parts:
- icon - Currently must refer to an icon in the Browser's images directory in the Browser source tree.
- html - A relative or full html path to a description document explaining the icon's meaning. This page displays when the user clicks on the icon.
- Tip - A "quoted string" tip that will be seen when the user's mouse pointer hovers over the icon.
Example:
pennantIcon 18.jpg ../goldenPath/help/liftOver.html "lifted from hg18"
priority <float>The priority is used to define the order of a track within its track group or data hub, as well as its default order within the Browser image. The order within the image can be dynamically changed by the user and will always depend upon which other tracks are currently visible. Typically the priority is set only for tracks that are on by default in order to move them ahead of other tracks. Prioritized tracks within a group or data hub are displayed in ascending priority order, followed by unprioritized tracks sorted alphabetically by short label. Tracks of the same priority within a group or hub are sorted by short label. Priority is a floating point number. Default: 0.
Example:
priority 50
release <alpha/beta/public>[,beta/public]NOT FOR HUBS.
This specifies the version of the Browser where the track will be displayed. It can contain any combination of the three values:
- alpha - displayed on the alpha Browser (aka genome-test, hgwdev)
- beta - displayed on the beta Browser (aka hgwbeta)
- public - released on the public Browser (aka genome.ucsc.edu)
Default: alpha,beta,public (all three Browsers).
Example:
release alpha,beta
table <tableName>NOT FOR HUBS.
The track setting of most tracks is the same as
the table name. However, in some cases it is desirable to
reference the same table in more than one track.
An example of this is showing a table as a single signal track and
as part of a combination overlay track, as described later in this
document. For data contained in MySQL tables, this setting must be used
if the track setting is not the name of the table.
Example:
track mySecondTrack
table myFirstTable
tableBrowser <off/on> [table1 ...]NOT FOR HUBS.
The Table Browser typically allows querying and downloading of some or all of the raw data for a track. This setting can be used to block Table Browser access to datasets with restrictions (for example, those with confidentiality or licensing limitations). By naming additional tables in this setting, access to those tables can be denied as well.
Example:
tableBrowser off decipherRaw knownToDecipher
The table for this track, as well as the decipherRaw and knownToDecipher tables, are blocked from Table Browser access.
url <url>urlLabel <label>idInUrlSql <sql for id>Many tracks allow an external link when an individual track data item is examined. Use this setting to put a link to an external URL on the details page. The url may include wildcards that will be substituted with values from the track data or other Browser variables:
- $$ - ID, will be replaced by the
nameof an item or other string id depending upon the fields in the given track's type. - $T - database table name
- $S - chromomosome name (scaffold name on scaffold assemblies)
- $[ - chromStart location (relative to zero)
- $] - chromEnd location (relative to one)
- $s - chromosome name without chr prefix (or without scaffold_ or Scaffold_ prefix on scaffold assemblies)
- $D - database name (e.g. "hg19")
- $P - item name portion before first : in name
- $p - item name portion after first : in name up to next colon
The default prompt the user will see for this url is "outside link:". Use
urlLabel to provide a more informative prompt.
For local (non-hub) tracks, an additional setting can be used to find an ID
from another table based upon the item name or id from the track's
table. The value found will replace the "$$" token in the url.
Note that the format of this trackDb setting is a normal C
language format so that the item will replace the "%s"
token in the sql statement.
Example:
url http://www.ncbi.nlm.nih.gov/htbin-post/Entrez/query?form=4&db=n&term=$$
urlLabel NCBI Details:
idInUrlSql select name from sibTxGraph where id=%s
url <url>urlLabel <label>Many tracks allow an external link when an individual track data item is examined. Use this setting to put a link to an external URL on the details page. The url may include wildcards that will be substituted with values from the track data or other Browser variables:
- $$ - ID, will be replaced by the
nameof an item or other string id depending upon the fields in the given track's type. - $S - chromomosome name (scaffold name on scaffold assemblies)
- $[ - chromStart location (relative to zero)
- $] - chromEnd location (relative to one)
- $s - chromosome name without chr prefix (or without scaffold_ or Scaffold_ prefix on scaffold assemblies)
- $D - database name (e.g. "hg19")
- $P - item name portion before first : in name
- $p - item name portion after first : in name up to next colon
The default prompt the user will see for this url is "outside link:". Use
urlLabel to provide a more informative prompt.
Example:
url http://www.ncbi.nlm.nih.gov/htbin-post/Entrez/query?form=4&db=n&term=$$
urlLabel NCBI Details:
urls <fieldName1>="<url1>" <fieldName2>="<url2>" ...This is similar to the url tag, but allows urls on fields that are not the "name" field. Use this statement if you need multiple linkouts on the details page or if your linkout is not based on the name field.
Put the identifiers for these links into extended bigBed fields as explained in example 3 of the bigBed documentation. The field names from your .as file are the field names referenced in this statement. The urls in this statement support the same wildcards as the url statement. Make sure to enclose the URLs in double quotes. The default label for the identifier is the field description in the .as file (all text after the # mark).
Example:
urls pmid="http://www.ncbi.nlm.nih.gov/pubmed/$$" hgncId="http://www.genenames.org/data/hgnc_data.php?hgnc_id=$$"
mouseOverField <fieldName1>For bigBed files with more than 8 fields, this adds mouse over text that are different from the "name" field of a bigBed file. If the field is empty then the mouse over will fallback to the name field.
To make this work, create a bigBed file with at least 8 columns and put the text for the mouse over into extended an bigBed field as explained in example 3 of the bigBed documentation. The field name from your .as file is the field name referenced in this statement.
Example:
mouseOverField comment
wgEncode onNOT FOR HUBS.
This setting designates an ENCODE track. It activates the following special features:
- Special thumbnail (NHGRI helix) is displayed before the track label in the brower track menu
- ENCODE logo is displayed on track configuration page
- 'Downloads' and 'Preview' browser links shown in upper right portion of track configuration page
- Track description includes a note about data on preview browser
- 'downloads' and 'metadata' links appear after 'View table:' on track details page
Example:
wgEncode on
bed/bigBed: Item or region tracks
Some of the most common track types are those that highlight regions or items of varying size in a genome assembly. There are many variations to the "items" track, most of which are specified with a bed or bigBed format. These two formats are really a cluster of many formats all starting with three common fields (chromosome start end) and having optionally many more fields. For complete bed or bigBed format definitions please see the FAQ.
bigBed: Item or region tracks
Some of the most common track types are those that highlight regions or items of varying size in a genome assembly. There are many variations to the "items" track, most of which can be represented with a bigBed format. This format is really a cluster of many formats all starting with three common fields (chromosome start end) and having optionally many more fields. For complete bigBed format definitions please see the bigBed help page.
type bed <3-12> [+/.]type bigBed <3-12> [+/.]Both bed and bigBed
declare the number of standard bed fields in the data.
Additional fields may follow these standard ones. If so, the
type should end with a '+' (plus). Even if there are not
additional non-standard fields, the additional parameter '.' (dot)
is needed, if this track is meant to be configurable.
Examples can be found below.
type bigBed <3-12> [+/.]Type bigBed declares the number of standard "bed" fields in the data.
There may be additional fields following these standard ones. If so, the
type should end with a '+' (plus). Even if there are no
additional non-standard fields, the parameter '.' (dot)
must be specified if this track is meant to be configurable.
Examples can be found below.
type bed5FloatScoretype bedRnaElementstype broadPeaktype coloredExontype gvftype ld2type narrowPeaktype peptideMappingEach of these is a specialized variation of the bed format. Their specialized definitions should be sought elsewhere. However, these item tracks share many of the same configuration options available to bed tracks.
An example can be found below.
bigDataUrl <url/relativePath>This setting is for remote data file type tracks (e.g. bigWig) and is fully described in the "Common trackDb settings" portion of this document.
colorByStrand <red,green,blue> <red,green,blue>To color items
differently by the strand they align to, use the colorByStrand
setting. The first color will be used for plus strand alignments
and the second for the minus strand. This setting is incompatible with spectrum
and all items on the same strand will have the same color, regardless of the item's
score.
Example:
colorByStrand 255,0,0 0,0,255
Plus strand alignments will be colored red, and minus
strand alignments will be blue. This setting is incompatible with spectrum,
and therefore all items on the same strand will have the same color, regardless of the item's
score.
compareGenomeLinks <db[.table[.column]]=label>
[db[.table[.column] =label …]NOT FOR HUBS
Sometimes the
features that a bed track highlights in one genome are also
displayed in tracks of other genomes. If an item of the same name
exists in the bed tracks of two or more genomes, a bridge can be
readily made between them through links on the item's detail page. To establish
this association, the feature must have the same name in each genome, and the name
must be unique within the bed track of each genome. The components of this
setting are a genome assembly database, an optional table and column,
with a label for the link. If the column parameter is omitted, it is
assumed to be name. If the table is omitted, it
is assumed to be the same as the current table. Links to multiple
genomes can be established with this setting, as each pair is
joined by '=' and delimited by space. Be sure to use
'_' as a substitute for spaces in the labels.
Example:
compareGenomeLinks panTro2=Chimpanzee_(March_2006) rheMac2=Rhesus_(January_2006) \
mm9=Mouse_(July_2007) rn4=Rat_(November_2004) canFam2=Dog_(May_05) \
bosTau4=Cow_(October_2007)
In this example for the hg18 ENCODE bi-directional promoter track, each genome has a track of the same name, and the names are unique within each track. However, a named bi-directional promoter will not be found in every genome; therefore, only links to genomes where the name is actually found will be displayed.
denseCoverage <maxVal>bigBed specific
Type bigBed tracks in dense mode do a density plot based on maximum coverage seen at each pixel. The maxVal corresponds to the count at which the plot reaches maximum darkness. If maxVal is 0 then this will be calculated from the data itself.
Example:
denseCoverage 100
exonArrows <on/off>On tracks that show exons or blocks within features, exon arrows allow the user to jump to the next exon or block outside the image. Exon arrows are typically shown by default in these types of tracks, with the exception of tracks in the Regulation group. The arrows can be explicitly shown or hidden using this setting.
Example:
exonArrows off
<column>Filter <low>[:<high>]scoreFilter <low>[:<high>]pValueFilterqValueFiltersignalFilter<column>FilterLimits <low>[:<high>]<column>FilterByRange <off/on>
NOT FOR HUBS. Not yet supported by bigBeds
A number of
numerical filters are available for bed tracks. These are
conveniently named by the field that is filtered on. The most
common numerical filter is based on the standard bed field
score, and is thus controlled by the scoreFilter
setting. Other examples are pValueFilter, qValueFilter and
signalFilter, which are filters on non-standard bed fields defined
in the broadPeak and narrowPeak formats. These numerical filter
settings should include the default value. If the numeric field
is floating point, the default should contain at least one decimal
place.
By default the range
of values for a numeric filter is 0 to 1000. However, you
can explicitly set the upper and lower limits of the filter by
setting <column>FilterLimits.
The numeric filters
will exclude items that fall below the setting. That is, a
scoreFilter of 800 will exclude all items with a score below 800.
You can also filter for values within a range, by including the
<column>FilterByRange setting. For example, a
scoreFilter range of
800-900 will include only items with scores at or above 800 and
below 900.
Note: multiple filters of different fields are allowed.
Examples:
scoreFilter 100
In this example, the standard bed
field score, which is an integer, will be used to filter items
in the track. By default, items with scores below 100 will be
excluded. Also by default the limits of the scoreFilter are
0-1000.
pValueFilter 3.0:15.0
pValueFilterLimits 0.0:15.0
pValueFilterByRange on
The non-standard bed field pValue, which
is floating-point, will be filtered by range. The expected data
range is 0.0 to 15.0, and by default only items with pValues within the 3.0 to 15.0
range will be displayed.
scoreFilter <low>[:<high>]scoreFilterLimits <low>[:<high>]Type bigBed tracks can be filtered on the standard bed field
score. This numerical filter is requested by the
scoreFilter setting, which should include the default value.
By default the range
of values for a score filter is from 0 to 1000. However, you
can explicitly set the upper and lower limit of the filter by
setting scoreFilterLimits.
The score filter will exclude items that fall below the setting. That is, a scoreFilter of 800 will exclude all items with a score below 800.
Example:
scoreFilter 300
scoreFilterLimits 200:1000
The standard bed
field of score, which is an integer will be used to filter items
in the track. By default, items with scores below 300 will be
excluded. The filter cannot be set to less than 200 or more than 1000..
filterBy <field1:title=[+]opt1a...>
[field2:title=[+]opt2a...]NOT FOR HUBS. Not yet supported by bigBeds
Another method of
filtering items relies upon discrete values. One or more fields
such as name or score may contain a limited number
of discrete values that can be filtered on. These discrete values will be
displayed in a dropdown list from which the user can choose one or
more options. While the maximum number of options in the list is
not limited, displaying too many options can be confusing for the user.
Setting complexities:
- Because filters for different fields are delimited by whitespace, any
whitespace in titles and labels should be replaced by the '
_' (underscore) character. - Each field/option pair is joined by '
=' (equal sign). - The field portion
can have a title that is delimited from the field name by '
:(colon)'. - A single field filter will have multiple options delimited by commas.
- If the options are
a 1-based index (1,2,3...) then the option list can be preceded
with a '
+' (plus sign) and the options themselves are only labels. - Otherwise, each
option will be a value and optional label delimited by '
|' (vertical bar). Note that if one option has a label then all options of that filter must have a label. - Finally, options may have CSS style wrapped in {curly} brackets and appended to the end.
Because of this
complexity, please remember to use the '\' continuation line to
ensure the setting is readable:
filterBy {field1}[:{Title1}]=[+]\
option1a[|label1a[{style1a}]],\
option1b[|label1b[{style1b}]],... \
[{field2}[:{Title2}]=[+]\
option2a[|label2a[{style2a}]],,...]
It is probable that this setting will be redefined at some point, given that it is very complicated. However, this current format will be supported until entirely replaced.
- Avoid the use of the delimiter chars
,|:={}in titles and labels. (These characters can be included via HTML codes.) Spaces can be included by using the '_' character. - The option labels
can be in color or have other CSS style attributes. Append the style
enclosed in curly brackets and containing no spaces. For example:
Pull_Over{color:#AA0000;text-decoration:blink;}. If one option has CSS style, then all options of that filter must include a style definition. - The filterBy option is implemented in the code using an SQL
whereclause. For instance, filtering on thenamefield for "Fred" and "Ethyl" would result in an SQL where clause of "where name in ('Fred','Ethyl')". Intype genePredtracks, this knowledge is used to define filters on fields in a separate table! This is done by defining the field as{otherTableName}.{fieldName}.
The best way to understand this setting is with an example. This is an operational example in the hg19 "Open Chrom Synth" track.
Example:
filterBy color:Validation_Level=\
0|Validated_(OC_1){color:#000000},\
255|Open_Chromatin_(OC_2-3){color:#0000FF},\
39168|DNase_low_(OC_2){color:#009900},\
10027008|FAIRE_low_(OC_3){color:#990000},\
16711935|ChIP-seq_(OC_4){color:#FF00FF} \
ocCode:OC_Code=+\
One:_Validated_(all),\
Two:_DNase_(all),\
Three:_FAIRE_(all),\
Four:_ChIP_(all)
This setting sets up
two filters, one on the field "color" and a second for the
"ocCode" field. The color filter is given the title "Validation
Level". The second option has a value of "255" and a label
of "Open Chromatin (OC 2-3)". Note that it will appear
as blue in the list due to the {color:#0000FF} style definition.
Also notice that all options for this color field have a style
defined, even though the first option is black and would be so by
default. In this example, the only
whitespace within the setting value section immediately precedes the second filter
definition. The second filter, "ocCode", is titled by the
inscrutable "OC Code". It is a numeric index filter
(as declared by the '+'). The value of the second option is 2 and
only the label gets defined as "Two: Dnase (all)". Note
that the colon in the label is an HTML code.
The filterBy setting is very powerful. We recommend that you experiment with the settings to determine which work best for your case.
itemRgb onIn bed formats supporting
at least 9 standard bed fields, this setting can be used to activate
item coloring using the value in the ninth field, itemRgb. The
value of the item field must be an R,G,B triplet. When loaded
into a table, this field appears as an integer with the RGB values
in specific bits of the integer.
Example:
itemRgb on
maxItems <integer>Maximum number of items to display individually in full mode. When the maximum is
exceeded, the excess items are drawn on top of one another on the last line.
In packed mode this refers to the number of lines rather than number of items.
Default: 250. For type bigBed tracks, this setting can never
be larger than than 100,000.
Example:
maxItems 25
maxWindowToDraw <integer>When too many individual bed items are shown in the Browser image (such as
might occur when a large region of a chromosome is viewed), the
information is often better visualized as a summary in dense mode.
Depending on the current visibility of the
bed track and which other tracks are being shown concurrently, the
Browser may automatically reduce the display to pack or dense mode. This setting
allows you to force the data summarization at whatever display limit you consider
reasonable. Unlike the maxItems setting, which controls the display of
vertical space, this setting dictates the number of bases to be displayed horizontally
in a window before the track is forced into dense mode. There is no default for this
setting, but the maxItems setting will ultimately prevent too many items from
being displayed.
Example:
maxWindowToDraw 200000
Browser images that show more then 200,000 bases will result in the track being displayed in dense mode.
minGrayLevel <1-9>When a bed track contains the standard
field score, and when that score is used
to present items in gray or color scale (see
spectrum),
this setting specifies the lightest shade to be used.
This prevents the lowest scores from being displayed in too light of a color to easily
view. Set the value in the range 1 - 9, lightest to darkest.
Example:
minGrayLevel 4
This sets the lowest scores to slightly less than medium gray, while the highest scores appear black.
noScoreFilter onBy default, bed
tracks with 5 or more standard bed fields that contain either a '.' or
a '+' in the type setting will be filterable on score;
that is, they will have an assumed setting of "scoreFilter 0". To turn
this old-style default off, include the "noScoreFilter" setting.
Example:
type bigBed 6 +
noScoreFilter on
spectrum onscoreMax <integer>scoreMin <integer>Replaces useScore.
If your track is a
bed 5 or greater, then the standard bed score
field exists. This score, which is expected to vary from 0-1000,
can be used to control the shading of bed items drawn in the Browser
image. To activate this feature, set spectrum on.
Lower scores will be shaded in light gray by default, while higher
scores will trend towards black. This can be modified in a number of ways:
-
colorcan be used to replace gray scale with a color scale -
altColorwithcolorcan vary items from color to altColor minGrayLevelcan be used to set the level of the lightest shade-
scoreMinandscoreMaxcan be used to define the lower and upper limits of the range that will receive graded shading
Example:
spectrum on
scoreMin 700
scoreMax 900
color 0,0,128
In this example, the track items will be displayed in blue. Items with scores less than or equal to 700 will be shown in very light blue, those with scores between 700 and 900 will display in increasingly darker shades of blue, and items with scores greater than or equal to 900 above will display in dark blue.
searchIndex <str>Specifies the list of field names on which a index has been made. When a user enters a string in the position search box of the browser, this index will be searched to find that name, and if the string is in the index, the user will either be navigated to that position in the browser, or if there are more than one matches of that string, will be give a list of the positions to choose from. See HERE for instructions on how to build an index for a bigBed file.
Example:
searchIndex name
searchTrix <url/relativePath>Specifies the URL to a TRIX file that maps free text to a set of indices that are assumed to have indicies in the associated bigBed file. See HERE for instructions on how to build a TRIX file.
Example:
searchTrix url or relative path
thickDrawItem <off/on>In bed tracks that have 8 or more standard bed fields, portions of items in tracks such as gene models can be drawn thicker to differentiate exon regions from introns. When data is displayed at different scales, the items and the thick portions of the items should scale proportionally. However, it may be more important to see the existence of the thick regions than it is to attempt to maintain the proportion. By setting thickDrawItem on, the thick display regions of items are always drawn at a minimum of 3 pixels, even when zoomed out greatly.
Example:
thickDrawItem on
bedFilter onFOR BEDS ONLY
Activating this setting provides the bed filter type controls that allow you to filter bed items by name with wildcard matching.
Example:
bedFilter on
The bed track will be be filterable by the bed item names.
bedNameLabel <label>When a user clicks on a bed track item in the Browser image, the item detail page is shown. This setting specifies an alternate label for the item name on that page. Without this setting, the label will be "Item:".
Example:
bedNameLabel Gene Id
baseColorUseSequence < <extFile {seqTable} <extFile> /
hgPcrResult / lfExtra / nameIsSequence / seq1Seq2 / ss >NOT FOR HUBS. Not yet supported by bigBeds
Specifies where item sequence can be found (if any) so that item sequence, or differences from genomic sequence, can be drawn when viewing a sufficiently small region.
- If
extFileis specified, two additional parameters are required, the name of the seq table followed by the name of the extFile table to use in looking up the sequence. These tables are loaded by hgLoadSeq. - If
hgPcrResultis specified than a PCR result is used. - If
lfExtrais specified then the sequence of an item is found in the last column of the table or remote file. - If
nameIsSequenceis specified then the 4th column (nameorsequence) contains the sequence. (see hg/lib/encode/tagAlign.as) - If
seq1Seq2is specified then the 7th & 8th columns (seq1andseq2) contain the left and right pairs of the sequence. (see hg/lib/encode/pairedTagAlign.as) - If
ssis specified then a user provided a user provided blat sequence fole is looked for.
baseColorUseCds <given/table <table>>NOT FOR HUBS. Not yet supported by bigBeds
Specifies where coding sequence (CDS)
coordinates can be found (if any) so that codons can be drawn
when viewing a sufficiently small region. If table is
specified, an additional parameter of a table name, in cdsSpec
format, is required.
baseColorDefault
<diffBases/diffCodons/itemBases/itemCodons/genomicCodons>NOT FOR HUBS. Not yet supported by bigBeds
Specifies the default drawing mode.
The itemBases, itemCodons, diffBases and
diffCodons options are applicable only if the track has sequence, as
specified by the baseColorUseSequence setting.
The genomicCodons, itemCodons and diffCodons are
applicable only if the track has CDS info, as specified by the baseColorUseCds
setting.
baseColorTickColor <lighterShade/contrastingColor>NOT FOR HUBS. Not yet supported by bigBeds
Choose a contrastingColor (this is often
white) or lighterShade of color. This should be the
same color as would be chosen for the base text if the user were
zoomed in to base level.
showDiffBasesAllScales onNOT FOR HUBS. Not yet supported by bigBeds
Show base differences for all zoom levels.
showDiffBasesMaxZoom <basesPerPixel>NOT FOR HUBS. Not yet supported by bigBeds
Show annotations highlighting base or codon differences
only if current zoom level does not exceed
basesPerPixel (a float). showDiffBasesAllScales
should also be set to make this useful.
showCdsAllScales onNOT FOR HUBS. Not yet supported by bigBeds
Show CDS for PSL tracks at all zoom levels.
showCdsMaxZoom <basesPerPixel>NOT FOR HUBS. Not yet supported by bigBeds
Use this setting (a float) to specify the maximum zoom-out allowed for displaying the CDS
for psl tracks.
In conjunction with this setting, showCdsAllScales must be set on and
showDiffBasesMaxZoom
should be set to a value not more than showCdsMaxZoom to make this
display configuration useful.
Examples:
baseColorDefault genomicCodons
baseColorUseCds given
showDiffBasesMaxZoom 10000.0
showCdsMaxZoom 10000.0
baseColorUseCds table hgFixed.transMapGeneUcscGenes
baseColorUseSequence lfExtra
baseColorDefault diffCodons
baseColorTickColor lighterShade
showDiffBasesAllScales .
showCdsAllScales .
exonArrowsDense <off/on>On tracks that show exons or blocks within items, exon arrows allow the user to jump to the next exon/block outside the image. Use this setting to display exon arrows even when the track is in dense mode.
itemDetailsHtmlTable <table>NOT FOR HUBS. Supplemental table must be in local database.
Use this setting to specify a table, indexed by item name, that contains an optional HTML fragment to display on the details page for this item. The expected columns in the table are "name" and "html".
Example:
itemDetailsHtmlTable pseudoGeneDetails
itemImagePath <path> <suffix>itemBigImagePath <path> <suffix>Items can be
associated with images and the images can be made visible with
these two settings. The itemImagepath specifies a
URL path to a directory with image files named in the format
{name}.{suffix}. The name is retrieved from the table or remote data
file. This image will be displayed on the item detaiIs page. If
itemBigImagePath is also supplied, then a link to a
larger image will be provided. If the path provided is local to
the browser then the path should be relative.
Example:
itemImagePath images/myTrackImages png
itemBigImagePath http://bigImages.com/myTrackImages jpg
When the user clicks
on a item named fred, then the item details page will show
the image images/myTrackImages/fred.png and will also
provide a link to a larger image at
http://bigImages.com/myTrackImages/fred.jpg.
mafTrack <trackName>NOT FOR HUBS
By specifying a multiple alignments track, the item details page will illustrate the differences for that item across a number of species.
Example:
mafTrack multiz46way
nextExonText <str>prevExonText <str>For tracks that offer multiple block items such as gene models, the next/previous exon arrows are usually displayed by default in the Browser. The functionality of these tiny arrows is described by mouse-over "tool tips" that default to "Next Exon" and "Prev Exon". If the blocks do not represent exons, you can adjust the tool tip text to the appropriate information with these two settings.
Example:
nextExonText "Next Match"
prevExonText "Previous Match"
showTopScorers #Use this setting to show a list of some number of top-scoring items in a region of the genome, when looking at an individual item in the item details page. The region will cover the current browser window coordinates. Currently this setting is not configurable.
Example:
showTopScorers 20
type bed 3
The simplest bed format, with nothing more than a chromosome and the start and stop coordinates for each bed item. There is nothing to configure.
type bed 6 +
colorByStrand 255,0,0 0,0,255
...
type bigBed 6 +
colorByStrand 255,0,0 0,0,255
...
The type setting for
a bed and a bigBed are nearly identical. Here, both type settings
specify a track with the first 6 standard bed fields defined
(up to strand) and with additional fields defined
after those 6 (indicated by the '+'). The
colorByStrand setting configures the plus strand items
to be colored red, while the minus strand items are blue.
type bigBed 8 .
scoreFilter 700
scoreFilterLimits 100:1000
thickDrawItem on
spectrum on
scoreMin 700
scoreMax 900
color 0,0,128
minGrayLevel 4
...
A bigBed track with
the first 8 standard bed fields (through thickEnd),
and no additional fields. The '.' tells
the Browser that the user may configure this track. The score
filter is explicitly declared to default to 700, and the defined
range of 100 - 1000 suggests there are no values of interest below 100.
This example also colors the items blue and presents
a spectrum or gradation of darkness based upon the score range.
Items with a score or 700 or less are displayed as the lightest shade of
blue, and items with a score of 900 or more are the darkest blue. Finally,
the minGrayLevel ensures that the lightest shade is visible
to the user. No doubt the value of '4' was chosen after experimentation
with the Browser display.
type broadPeak
pValueFilter 2.0
pValueFilterLimits 0.0:300.0
This track is a essentially a bed 6+3 format dataset, but it has been defined with special features for ENCODE. The pValueFilter applies to a field named pValue which is one of the 3 additional fields after the standard 6.
type bigBed 6 +
colorByStrand 255,0,0 0,0,255
...
The type setting for
a bed and a bigBed are nearly identical. Here, both type settings
would define a track with the first 6 standard bed fields defined
(up to strand) and with additional fields defined
after those 6. Notice that plus strand items are colored red,
while minus strand items are blue.
type bigBed 8 .
scoreFilter 700
scoreFilterLimits 100:1000
thickDrawItem on
spectrum on
scoreMin 700
scoreMax 900
color 0,0,255
minGrayLevel 4
...
A bigBed track with
the first 8 standard bed fields (through thickEnd),
and no additional fields. The '.' is required to tell
the Browser that the user may configure this track. The score
filter is explicitly declared to default to 700, and an allowable
range for the score suggests there are no values below 100 worth
looking at. This example also sets the items to blue and presents
a spectrum or gradation of darkness based upon the score range.
Items with score 700 or less are the lightest, and items with
score 900 or more are the darkest blue. Finally the lightest
shade set to be not too light with the poorly named minGrayLevel
setting. No doubt 4 was chosen after experimentation to see how
it actually looks in the Browser.
wig, bigWig, and bedGraph: Signal graphing tracks
Another set of common track types is one that graphs a density signal along
the genome. The graph can be a continuously varying density plot or
one that displays a density signal in only certain regions. The
oldest and simplest of these is of wig format. This type has been
improved as a bedGraph and then greatly enhanced as a bigWig.
While there are differences among the formats, all support the basic
graph configuration controls. For detailed specifications of each
type and how to prepare them for display in the Genome Browser please
see the FAQ.
bigWig: Signal graphing tracks
Another set of common track types are those that graph a density signal along
the genome. The graph can be a continuously varying density plot or
one that displays a density signal in only certain regions. For data hubs
the most common signal track type is bigWig.
For detailed specifications of the bigWig remote data
file format and how to prepare it for display in the Genome Browser please
see:
http://genome.ucsc.edu/goldenPath/help/bigWig.html.
type wig <low#> <high#>type bigWig <#> <#>MySQL tables of type
wig and remote data files of type bigWig
must declare the expected signal range for
the data.
Examples can be found below.
type bigWig <#> <#>The remote data files of type bigWig
must declare the expected signal range for
the data.
Examples can be found below.
type bedGraph <field>minLimit <#>maxLimit<#>The bedGraph type
track has the same file format as a bed file, but is loaded into
the MySQL database in a form that can be graphed. By default the
value to be graphed is the fifth standard bed field,
score; however, you can specify a different field to use.
Typically only the first 3 standard bed fields are included
(chrom, start, stop) and the fourth field
contains the signal value. The bedGraph track offers
a couple of important improvements over the wig track. In wig
tracks, the value of the signal is truncated into a single byte,
which is effective for graphing but fails at data storage. Also
the wig type was originally designed for fixed-size windowing, though
variations were added. The bedGraph type allows for variable
windowing and defining values even down to the base level. To be
clear, bigWig tracks are as versatile as bedGraphs. It is
only the wig format that suffers from these limitations.
On the other hand the storage density of wig, particularly the fixed step variant, is vastly denser than bedGraph. In cases where the data is solely meant for display, the 256 levels supported by wig more than suffice. For single-base or even 10-base level resolutions, bedGraph is generally not practical genome-wide. Note also that wigs converted to bigWigs do not suffer the reduced precision of wigs loaded directly into the database. A bigWig based on fixedStep wigs is the best way to represent dense graphs over the genome.
Note that the lower and upper limits of the bedGraph signal are not declared in the type,
but rather are declared with 2 separate settings, minLimit and
maxLimit.
Examples can be found below.
alwaysZero <off/on>When autoScale is set to "on" in the signal track,
additionally setting alwaysZero to "on" will ensure that the y=0
value will be in view at all times. Default: off.
autoScale <off/on>The graph of the
data displayed in the Browser image is usually scaled on the y
axis in absolute coordinates. However, you can display the data
in autoScale which will ensure that the high score in the current
viewing window will peak at the top of the graph. Like most graph settings,
this is configurable by the user. Setting it to "on" in trackDb will default
the track to autoScale. Default: off.
NOTE: this option should be avoided if it will lead to display regions in which a low signal erroneously appears as significant because there is no high signal in the view window.
Example:
autoScale on
graphTypeDefault pointsThe signal can be
graphed as either "points" displayed at the signal
value, or the default space-filling "bars".
Example:
graphTypeDefault points
maxHeightPixels <max:default:min>The amount of vertical viewing space for your signal track should be declared, though it is configurable by the user. Typically it is set to no more than 100 pixels and no less than 8, with a default of 16 or 32 pixels.
Example:
maxHeightPixels 100:16:8
The browser will display the track as 16 pixels high, but the user can scale it up to 100 pixels.
maxWindowToQuery <integer>For bigWigs only
When signal data is clicked in the Browser image, the details of the signal in the current viewing window are displayed. For bigWigs that reference remote data, the query can be a very expensive operation if the current window is large. To avoid overburdening the Browser, the size of the window to query should be limited. The value of this setting is the maximum window size in bases that should be queried to give the detailed signal numbers.
spanList <s1>[,s2…]NOT FOR HUBS. For wig tracks only.
Sets the data point span to just be the first span in table or list of spans in the loaded table you can find the spans by doing: "select span from <table> group by span".
Typically spanList is only one as the example shows. Rarely there may be
more: "
spanList 1,1000".
Special efforts must be made to load extra
spans into the table for special purposes.
Example:
spanList 1
smoothingWindow <off/1-16>Often signal information is chunky, because a single value is given for a number of bases. The graph can smooth the chunky data, presenting a display more reflective of the actual biology it is meant to illustrate. The numerical value of this setting determines how much surrounding data to use for smoothing: the larger the number, the less abrupt the curves will be. The setting is user-configurable. Default: off.
Example:
smoothingWindow 4
transformFunc <NONE/LOG>The track's signal can be presented in log scale with this user-configurable setting. Default: NONE.
Example:
transformFunc LOG
viewLimits <lower:upper>viewLimitsMax <lower:upper>The data of most interest in a graph track may be contained within a narrow range. Typically high outlier values can skew a graph and very low values may represent uninteresting data. Use viewLimits to set the default viewing range. Also use viewLimitsMax as suggested outer bounds.
Example:
viewLimits 5:20
viewLimitsMax0:100
Any data points of 20 or above will be shown as the peak of the graph. Data points that are below 5 will not be displayed. Even though the full data range extends to 100, these settings suggest that scores of 20 or more are all considered highly relevant.
wigColorBy <bedTable>NOT FOR HUBS. For wig tracks only.
Regions of the
graphed signal may be highlighted by color. Use a bed
table and the color settings to shade regions of the wig
track.
Example:
wigColorBy myBed
color 175,150,128
altColor 255,128,0
The bed-type table "myBed" is used to highlight regions of graphed signal based upon the scores in that table. The table may itself be a visible track, or may exist only for the purpose of highlighting the signal track.
windowingFunction <mean/mean+whiskers/maximum/minimum>Depending upon how large of a genomic region
is displayed in the Browser image, it may be necessary to summarize
the actual signal. This user-configurable setting controls how the Browser
collapses the signal from (for example) 100 or 100 thousand bases down to
a single pixel. By default
the single pixel represents the mean of the data, though the
maximum or minimum can alternatively be displayed. A more informative
option is often mean+whiskers. This setting displays the
mean, max and one standard deviation above mean, differentiated by shading.
The mean is displayed as the darkest shade, one stdDev above mean as
slightly lighter, and the max as the lightest shade.
This subtle shading can quickly indicate if the
condensed data is hiding important information that can
be adequately evaluated only by zooming in.
Example:
windowingFunction mean+whiskers
When zoomed out, this track will show the mean signal but include shading representing higher scores. The user may change this setting.
yLineMark <#>yLineOnOff <off/on>gridDefault onIt can be useful to
draw a line across the track's signal graph at some fixed y
coordinate. Do this by setting yLineOnOff to "on" and specifying the
y coordinate with yLineMark. These two settings are
configurable by the user. Defaults: off and 0.0.
Often confused with
these configurable settings is the gridDefault, which simply draws a
a line at y=0 across your entire track. This setting might be
useful if the lack of data is equivalent to a 0 signal.
Example:
yLineOnOff on
yLineMark 2.5
gridDefault on
The signal is graphed with a default solid line at zero, suggesting that any gaps in data should be interpreted as zero signal. There will also be a line at the signal height of 2.5 that may be used to emphasize which peaks in the signal reach this critical height.
type wig 0 100
windowingFunction maximum
viewLimits 5:20
viewLimitsMax 0:100
maxHeightPixels 100:16:8
spanList 1
wigColorBy myBed
...
This wiggle track is composed of a MySQL table and binary "wib" files that are referenced in the table. The default windowing function is the maximum signal in each window (under each pixel) shown. The span of bases covered by each row in the table is identical and can be gathered from the first row in the table. The wiggle has colors supplied by the bed table, myBed.
type bigWig -0.25 37.6
windowingFunction mean+whiskers
viewLimits 5:20
viewLimitsMax 0:37.6
maxHeightPixels 100:32:8
yLineOnOff on
yLineMark 15
gridDefault on
color 128,0,128
...
This bigWig format signal is held in a data file (which may be remote). The more informative mean+whiskers windowing function is used by default in this track, and the signal will be 32 pixels high in the Browser image display. Note that even though the signal value may be less than zero, that portion of the signal will not be displayed. The Browser will display a line at y=0 and another at y=15, which may be a threshold value for this signal. The track will be colored purple.
bedGraph 4
minLimit 0
maxLimt 20
viewLimits 5:8
viewLimitsMax 0:20
maxHeightPixels 100:16:8
...
This bedGraph style signal track is composed of a MySQL table of items, each with a score defined in the fourth column. While a wiggle track is usually composed of fixed interval windows of signal (e.g. 200 bp), the bedGraph table may define a signal in varying granularities of windows with or without gaps.
type bigWig -0.25 37.6
windowingFunction mean+whiskers
viewLimits 5:20
viewLimitsMax 0:37.6
maxHeightPixels 100:32:8
yLineOnOff on
yLineMark 15
gridDefault on
color 128,0,128
...
This bigWig format signal is held in a data file (which may be remote). The more informative mean+whiskers windowing function is used by default in this track, and the signal will be 32 pixels high in the Browser image display. Notice that even though the signal value may be less than zero, that portion of the signal will not be displayed. The Browser will display a line at y=0 and another at y=15, which may be a threshold value for this signal. The track will be colored purple.
genePred: Gene models and predictions
NOT FOR HUBS. (None of the settings in this section apply to hubs.)
genePred is a variation of item-based tracks
designed especially for displaying gene
models. Gene models can be represented in bed 12 or bigBed 12
type tracks, but the genePred table format allows for more detail,
such as distinguishing between transcript, coding region, and coding
vs. non-coding exons. Please refer to the
FAQ
for information on how to prepare genePred tables for inclusion in
the Genome Browser.
type genePred [pepTable [mrnaTable]]This type of track, based on MySQL tables, is for gene models and predictions.
- pepTable - Optional protein sequence table
- mrnaTable - Optional representative mRNA table
Note that missing
options can be filled with a '.' dot. Additional settings
described below allow the grouping of gene models into classes and
the coloring and filtering of the models by class.
Examples can be found below.
geneClasses <cl1 cl2...>Genes can be grouped into classes for the
purposes of coloring and filtering. The trick is how to
associate each named gene with its class. Use geneClasses to create a
list of all gene class names delimited by white space.
gClass_<xxx> <red,green,blue>Declare an RGB color for a named class.
itemClassTbl <table>Declare a MySQL table that will link classes to named gene models.
itemClassNameColumn <col>Optionally declare the column of the
itemClassTbl that will hold the genePred names. Default:
name.
itemClassClassColumn <col>Optionally declare the column of the
itemClassTbl that will hold the class. Default: class.
Example:
geneClasses rRNA tRNA snRNA
gClass_rRNA 255,0,0
gClass_tRNA 0,255,0
gClass_snRNA 0,0,255
itemClassTbl rnaTypes
itemClassNameColumn rnaName
itemClassClassColumn rnaType
In this genePred type track, RNA gene models are divided into 3 classes that are colored red, green or blue. The association of named gene models in the genePred table with the three classes is defined in the "rnaType" table. That table holds the RNA type in the "rnaType" column and the gene name in the "rnaName" column.
filterBy <field1:title=[+]option1a...>
[field2:title=[+]opt2a...]Filtering gene models by table column or even
itemClassTbl column can be achieved by this setting. Complete
description of this setting can be found in the
bed/bigBed item-based track settings. Here is an example for
referencing the class as found in the table defined by itemClassTbl. Not all
track types will support externally referenced tables using filterBy
as genePred type does. But if you understand the CGI code that
performs the table select, then filterBy can provide a powerful extension to
the SQL selection used.
Example:
geneClasses rRNA tRNA snRNA
gClass_rRNA 255,0,0
gClass_tRNA 0,255,0
gClass_snRNA 0,0,255
itemClassTbl rnaTypes
itemClassClassColumn rnaType
filterBy rnaTypes.rnaType:Class=\
rRNA|Ribosomal_RNA{color:#FF0000},\
tRNA|Transfer_RNA{color:#00FF00},\
snRNA|Small_Nuclear_RNA{color:#0000FF}
When gene models are
selected from the genePred table for display in the Browser,
their class is also selected from the "rnaTypes" table. Using the
filterBy setting creates a user selectable drop-down list box of
3 choices or "all". When the user filters by tRNA and snRNA (the
green and blue choices), the mySQL select statement used by the
Browser will be limited by the where clause "where
rnaTypes.rnaType in ('tRNA','snRNA')".
autoTranslate 0By default, a
predicted protein translation is generated for a gene model when
a user views it on the details page. This feature may be blocked
by setting autoTranslate to zero.
Example:
autoTranslate 0
The genPred track will NOT show auto-generated protein sequence, perhaps because this track is for RNA genes.
intronGap <#bases>In drawing gene models, it can be useful to see "exon arrows" when the transcript extends beyond the current window. This setting, which defaults to zero, ensures that these arrows will not be drawn if the interceding intron gap is less than the stated number of bases.
Example:
intronGap 12
Don't draw exon arrows when the gap between exons is 12 bases or less.
defaultLinkedTables <table1>[,table2...]In hgTables, when selecting output fields, display these all.joiner-linked tables by default.
Example:
defaultLinkedTables kgXref
idXref <idColumn> <altIdColumn>By using this setting you can link alternative names to the gene models found in a genePred. This is used by the Table Browser to establish links to other tables.
Example:
track knownGenes
idXref kgAlias kgID alias
The ID in the name column of the knownGenes table is related to the alias found in the kgAlias table.
oldToNew <tableName>In successive versions of gene models, it can be helpful to map older genes to their newer models. This can be done by providing a MySQL table that maps the change, and then using this setting to ensure the gene details page shows any changes.
Example:
track knownGeneOld5
oldToNew kg5ToKg6
The older version of UCSC Genes references changes that are seen in the newer version.
type genePred
oldToNew kg5ToKg6
baseColorUseCds given
baseColorDefault genomicCodons
geneClasses coding nonCoding pseudo
itemClassTbl myClasses
gClass_coding 12,12,120
gClass_nonCoding 0,153,0
gClass_pseudo 255,51,255
filterBy myClasses.transcriptClass:Class=\
coding{color:#0C0C78},\
nonCoding{color:#009900},\
pseudo{color:#FF33FF}
...
Gene model track with defined classes and the option to filter by the color-coded classes. Note the base level coloring option.
type genePred . mrna
url http://www.ncbi.nlm.nih.gov/IEB/Research/Acembly/av.cgi?db=hg17&l=$$
urlLabel AceView Gene Summary:
This gene prediction track has associated representative mRNAs found in the "mrna" table. There is also an "AceView Gene Summary" url presented on the details page.
bam: Compressed Sequence Alignment/Map tracks
The bam format is an indexed compressed data format for sequence alignments. It is ideal for remote access of high-throughput sequence tags and is a native output format for some high-throughput sequencing (HTS) aligners. The format of bam data is data-file pairs, with an index in a separate file. These are frequently remote datasets, not residing on the UCSC server. Please refer to the BAM track format page and the SAMtools website for information on how to create and deploy these remote data files for inclusion in the Genome Browser.
type bamDeclares configuration settings for a track of type bam. If the bigDataUrl
setting is included, that data at the location specified by that URL will be
displayed. Otherwise, a database table with a single column fileName
can specify the location of a local file or a URL.
If the database table includes a column seqName, a different
BAM file or URL can be specified for each assembly sequence.
Example can be found below.
bamColorMode <strand/gray/tag/off>There are numerous ways to color bam tracks to highlight certain aspects of the data. All of these are user-configurable.
Possible settings:
strand: (Default) When colored by strand, mismatched bases are highlighted in bright red, alignments on the reverse strand are colored dark red, and alignments on the forward strand are colored dark blue.gray: When colored in grayscale, items are shaded according to the method specified bybamGrayMode: alignment quality, base qualities, or unpaired ends.tag: Colors are specified in "user-defined tags". SAM/BAM may include user-defined tags, the names of which begin with X, Y or Z and include one other letter or number. The user-defined tag named here specifies red, green and blue (RGB) intensities as a zero-terminated string (tag type Z) containing comma-separated triples of numbers from 0-255. For example, if a SAM/BAM record includes the tag YC:Z:255,0,0, then the item is colored red; YC:Z:0,0,255 makes the item blue. By default, the tag is "YC" unless changed using thebamColorTagsetting.off: No additional coloring.
bamGrayMode <aliQual/baseQual/unpaired>aliQualRange <min:max>baseQualRange <min:max>When bamColorMode is set to "gray", you
can highlight one of the following:
aliQual: (Default) The "alignment qualities" of the items are shaded on a scale of 0 (lightest) to 99 (darkest). UsealiQualRangeto specify a default range.baseQual: "Base qualities" are shaded on a scale of 0 (lightest) to 40 (darkest). UsebaseQualRangeto specify a default range.unpaired: When "unpaired ends" is selected, an item that was paired in sequencing but whose mate was not mapped is colored gray, while singletons and properly paired items are colored black.
Refer to the SAM format details for a discussion of these values.
bamColorTag <XX>You can also use RGB data associated with
individual tags within the bam file itself. Refer to the
SAM documentation
to understand how the RGB values are included.
When the bamColorMode is set to "tag", the standard "YC" tag
is used as the default. The default may be overridden with this setting.
noColorTag .The bam coloring options are all user-configurable within the browser. If your bam dataset contains no color tags, this setting should be included to block the Browser from offering the option to color tags by an embedded RGB value.
Examples:
bamColorMode strand
noColorTag
Sets the bam to use the default coloring scheme based on strand alignment. At the same time, the bam track will not offer the option to color the tags by RGB values, perhaps because this bam has no RGB values.
bamColorMode gray
bamGrayMode aliQual
aliQualRange 20:80
These settings will highlight tags by alignment quality score. If the score is at 80 or above, the tag is shaded black; if it is less than 20, the tag is shaded very light gray.
bamColorMode tag
bamColorTag YC
The bam file includes RGB values in the YC field that will be used to color tags.
bamSkipPrintQualScore .Any bam tag can be displayed on the details page by clicking on it in the Browser image. The details include quality scores by default. If these scores are not relevant for this particular bam, they may be excluded from the details page with this setting.
Example:
bamSkipPrintQualScore .
indelDoubleInsert <off/on>indelQueryInsert <off/on>indelPolyA <off/on>Insertion and deletion differences between tag sequences and the reference genome can be highlighted with the use of these settings. These options may be set by the user.
-
indelDoubleInsert: Use to highlight alignment gaps in both the target (reference) and query (tag) sequence with double (=) lines. -
indelQueryInsert: Use to highlight an insert in the query sequence only by drawing an orange (|) or purple (|) vertical line. Orange lines show unalignable regions in the middle of a sequence, and purple highlights regions at the end of the query sequence. indelPolyA: Use to highlight an apparently valid poly-a tail by drawing a vertical green line (|).
Example:
baseColorUseSequence genbank
indelDoubleInsert on
indelQueryInsert on
indelPolyA on
minAliQual <#>When the Browser image is zoomed in to the level where individual tags are visible, the tags in a bam file can be filtered to show only those with a minimum alignment quality score. This is a user-configurable setting. Default: 0.
Example:
minAliQual 20
pairEndsByName .Some high-throughput sequencing technologies result in "paired end" tags, which are two individual bam records joined by their name. If this is the case with your dataset, include this setting.
pairSearchRange <#>Searching to join pairs of tags by name will be limited to a maximum distance (default: 20,000 bases). Use a larger range to increase the likelihood that both reads in a pair will be found even when only one read is in the viewed region. Use a smaller range to speed image rendering.
Example:
pairedEndsByName .
pairSearchRange 5000
The dataset includes paired end tags. The maximum search range to join tag pairs by name is capped at 5000.
showNames <on/off>When the Browser image is zoomed in to the level where individual tags are viewable, the query name for each tag is shown by default. Use this setting to hide this name.
Example:
showNames off
type bam
bigDataUrl http://hgdownload/ucsc.edu/goldenPath/hg19/bambam/barneysSon.bam
pairEndsByName on
showNames off
bamColorMode off
bamGrayMode aliQual
indelDoubleInsert on
indelQueryInsert on
maxWindowToDraw 10000
...
The bam data is held in the file "barneysSon.bam" which is at an
internet-accessible location. In addition to the data file, an
associated index file must reside at the same location. The index file must have the
same name as the data file, with ".bai" appended (e.g. barneysSon.bam.bai).
psl: Sequence alignments
NOT FOR HUBS. (None of the settings in this section are available for hubs, although it is likely that hub support will be added in the future.)
PSL is an alignment format in which the data is typically taken from files generated by BLAT or psLayout. For further information about this format please refer to the FAQ and BLAT documentation.
type psl <subtype> [otherDb]The psl type tracks
require the specification of a subtype: est, mrna,
protein or xeno. The default, which is
represented as ".", is regular human mRNA. When the xeno subtype
is selected, an additional optional parameter may be set to specify the other species
assembly. If present, the alignments can be color-coded by
chromosome, and the chromosome and position (in kilobases) are shown
in the alignments label.
Examples can be found below.
blastRef <assembly.table>Include a blastRef to an assembly and table that contains geneId and position retrievable by accession id. This information will be displayed in the item name.
Example:
blastRef hg17.blastKGRef02
colorChromDefault offFor psl tracks of
subtype xeno, the alignments may be colored to indicated their
location in the other species. This setting is turned on by default
when the other species is specified in the type psl
setting. Use this setting to turn off chromosome coloring by default,
offering the user the choice to turn it on.
Example:
type psl xeno loxAfr1
otherDb loxAfr1
colorChromDefault off
pred <assembly.table>Use the pred setting to name an assembly and table containing protein sequence data for the named alignments.
Example:
pred hg18.blastKGPep04
pslSequence <no/all/different>This setting specifies some display configuration options for psl tracks that also have sequence loaded.
all: Display nucleotide labels on all bases.different: Label only base differences.no: Allow the user to select which of the other two options is preferred.
Example:
pslSequence different
transMapGene <assembly.table>transMapInfo <table>transMapSrc <assembly.table>transMapTypeDesc <label>For alignment tracks generated using the TransMap cross-species alignment algorithm, these settings are used to connect the transMap detailed information with the alignments.
transMapInfo: Use to name the table in the current assembly that ties an alignment with the source assembly and feature.transMapSrc: Use to name the table in the source species assembly that contains the details of the feature's source location.transMapGene: Use to name the table mapping the alignment to gene names in the relevant species. Note that tables that are common to multiple species should be put in thehgFixeddatabase.transMapTypeDesc: Use to set a label for the type of transMapping that the alignment covers.Example:
transMapInfo transMapInfoUcscGenes transMapSrc hgFixed.transMapSrcUcscGenes transMapGene hgFixed.transMapGeneUcscGenes transMapTypeDesc UCSC Gene baseColorUseCds table hgFixed.transMapGeneUcscGenes baseColorUseSequence extFile hgFixed.transMapSeqUcscGenesNote that several of the named tables are in
hgFixed, which is a database containing tables that are shared by multiple species and assemblies. Also notice that the same table that was named intransMapGeneis also used in this example forbaseColorUseCds.
ucscRetroInfoFor alignments illustrating retrotransposition, use this setting to name a table with details of the source location.
Example:
ucscRetroInfo ucscRetroInfo1
track ucscRetroAli1
type psl
ucscRetroInfo ucscRetroInfo1
baseColorDefault diffCodons
baseColorUseCds table ucscRetroCds
baseColorUseSequence extFile ucscRetroSeq1 ucscRetroExtFile1
indelDoubleInsert on
indelQueryInsert on
showDiffBasesAllScales .
showDiffBasesMaxZoom 10000.0
...
In this example of retroposed genes, mature mRNA has been aligned to the genome. Notice there is a ucscRetroInfo table that describes the non-transposed gene location. Also notice the use of the baseColor settings for coloring the coding sequence (CDS).
track protBlat
color 0,100,0
altColor 255,240,200
type psl protein
...
In this example of protein sequence blat results, the color of matching sequence is green, while indels (in this case introns) are highlighted with yellow.
track rgdEst
spectrum on
color 12,12,120
type psl est
...
This expressed
sequence tag example will have colored alignments that are graded
by a score thanks to "spectrum on". Though psl tracks do not have
a score column as part of the format, a score is
generated based upon matches and mismatches in the alignment. The
shading is even more subtle in that the weight given to inserts
varies depending upon whether the alignment is to the same or a
different species.
track blastzTetNig1
color 0,0,0
altColor 50,128,50
spectrum on
type psl xeno tetNig1
otherDb tetNig1
...
This psl track is for foreign species or "xeno" alignments, in this case the sequence reads of a species of fish aligned to human.
chain and netAlign: paired species alignments
NOT FOR HUBS. Nor are any of the settings in this section.
While "chain" and
"netAlign" formats are different, they often are paired to show two
different views of the same data.
Chain tracks show alignments of a "query" species to a "target" genome assembly. For example, a chimp panTro2 can be aligned to the human hg19 genome. The chain format allows for gaps in both sequences simultaneously. When chains are viewed in the Browser, they show solid boxes for alignments, separated by either single or double lines. The single lines appear when an insertion occurs in the target or a deletion occurs in the querying species. Double lines represent gaps in both species that could result from a number of causes (e.g. an inversion in one species). For more information on the "chain" format, please refer to http://genome.ucsc.edu/goldenPath/help/chain.html.
A netAlign track represents the best chain for each region in the target genome. The net track will show the largest, highest scoring chains that span a region. When these chains have gaps, they may be filled in with additional chains, shown at a lower level, and gaps in these chains may in turn be filled at an even lower level. These levels help in visualizing genome rearrangements such as inversions and retroposed elements. For more information on the netAlign format, please refer to http://genome.ucsc.edu/goldenPath/help/net.html.
type chain <otherDb>otherDb <otherDb>Tracks of type chain show sequence alignments
from another species to the reference genome. This type
requires the assembly database of the other species to be named in both the
type setting and in the "otherDb" setting.
Example can be found below.
type netAlign <otherDb> <otherChainTable>otherDb <otherDb>Tracks of type netAlign show the best chains of
sequence alignments from another species to the reference genome.
Gaps are filled in levels, where possible. This type requires the
assembly database of the other species to be named in both the type setting and
in the "otherDb" setting.
Example can be found below.
chainColor <scheme>By default chains are colored by the alignment chromosome of the query species. This can be overridden with this setting. The three options are:
Chromosome- defaultNormalized Score- chains are colored by scoreBlack- no coloring occurs
This setting affects
chain but not netAlign type tracks.
Example:
chainColor Black
chainLinearGap <loose/medium>The chainLinearGap setting should reflect the
"-linearGap" parameter used in axtChain to generate
the track. It represents the gap scoring matrix used and will be
either:
loose- chicken/human linear gap costsmedium- mouse/human linear gap costs
This setting is for both chain and netAlign
type tracks.
Example:
chainLinearGap medium
chainMinScore <#>The chainMinScore setting should reflect the
"-minScore" parameter used in axtChain to generate the
track. It represents the score threshold for chains to be
included in the set. Default is 1000. This setting is for both
chain and netAlign type tracks.
Example:
chainMinScore 5000
chainNormScoreAvailable <yes/no>A given chain or netAlign track may or may not
have a populated normScore column. If the column exists, then
its value can be displayed in the item details page of the
Browser by setting chainNormScoreAvailable to yes.
Item coloring based upon score as selected by the
chainColor Normalized Score setting also requires
this setting to be yes.
Example:
chainNormScoreAvailable yes
chainColor Normalized Score
matrix <size> <#,#,#,#,…>matrixHeader <b1,b2,b3,b4>$matrix token in html.The method for scoring and selecting chains and generating netAligns relies upon a matrix of costs for base substitutions. The matrix used in the generation of any given paired alignment can vary depending upon such things as evolutionary distance and the species involved. The matrix used can be dynamically included in the HTML description using three elements:
- The HTML description must have the
$matrixtoken in it. - The
matrixto be used must be defined with this trackDb setting. The format of this setting is the cell size of the matrix which for DNA alignments is 16. This size is separated by a space from the comma-delimited array of all the values as the matrix cells are filled in left to right and top to bottom. - The
matrixHeadersetting should be used to define the order of base transitions in the matrix. Typically it is “A,C,G,T “.
Example:
html chainNet
matrixHeader A,C,G,T
matrix 16 91,-114,-31,-123,\
-114,100,-125,-31,\
-31,-125,100,-114,\
-123,-31,-114,91
Here the $matrix token found in the
chainNet.html file will be replaced by the following matrix:
| A | C | G | T | |
|---|---|---|---|---|
| A | 91 | -114 | -31 | -123 |
| C | -114 | 100 | -125 | -31 |
| T | -31 | -125 | 100 | -114 |
| G | -123 | -31 | -114 | 91 |
track chainRheMac2
type chain rheMac2
otherDb rheMac2
color 0,0,0
altColor 100,50,0
matrix 16 91,-114,-31,-123,-114,100,-125,-31,-31,-125,100,-114,-123,-31,-114,91
matrixHeader A,C,G,T
chainMinScore 3000
chainLinearGap medium
html chainNet
...
track netRheMac1
type netAlign rheMac1 chainRheMac2
otherDb rheMac2
matrix 16 91,-114,-31,-123,-114,100,-125,-31,-31,-125,100,-114,-123,-31,-114,91
matrixHeader A,C,G,T
chainMinScore 3000
chainLinearGap medium
html chainNet
...
Both the chain and netAlign tracks above are
for alignments of the query species/assembly rheMac2
against the target species determined by the database this trackDb
belongs to (e.g., human/hg19). Because the netAlign track is
based upon the data in the chain track, it references the track in its
type setting. Both tracks use the same matrix, chainMinScore and
linear gap settings. Methods to group these two tracks into a
single set that share settings are described later in this
document.
wigMaf: Multiple alignments
NOT (currently) FOR HUBS. Nor are any of the settings in this section.
Multiple pairwise
alignments can be displayed with "wigMaf" type tracks. Tracks of
this type may actually be composed of multiple tables and data files.
The type setting will name the one MAF format table (with an
associated "maf" file in /gbdb). The optional "wiggle" setting will
name one or more wig format tables (with an associated "wib" files)
that contain conservation signals. Please refer to the
FAQ
for information on how to prepare multiple alignment format datasets.
type wigMaf <minVal> <maxVal>A wigMaf type track is composed both of MAF format alignment (loaded with hgLoadMaf). The track may optionally include one or more conservation signals. The signals must be within the same data range defined with the min and max values in the type setting.
Examples can be found below.
frames <table>A wigMaf track can display gene codon translation. The reading frame may differ between species. By providing the reading frames information in a separate table, the user can choose which frame to use when viewing the data.
Example:
frames myCodonFrames
irows offBy default, gaps in the non-reference species are filled with the placeholder character:
- Single Line '
-': No bases in the aligned species. Possibly due to a lineage-specific insertion between the aligned blocks in the human genome or a lineage-specific deletion between the aligned blocks in the aligning species. - Double line '
=': Aligning species has one or more unalignable bases in the gap region. Possibly due to excessive evolutionary distance between species or independent indels in the region between the aligned blocks in both species. - Pale yellow coloring: Aligning species has Ns in the gap region. Reflects uncertainty in the relationship between the DNA of both species, due to lack of sequence in relevant portions of the aligning species.
irows to "off".
Example:
irows off
itemFirstCharCase noChangeThis controls if
species names in the multiple alignment should be capitalized in
the pairwise display. Set "noChange" to avoid forcing
the first letter to lower case.
Example:
itemFirstCharCase noChange
pairwiseHeight <#>A wigMaf display in the Browser image is a stacked set of pairwise alignments to the target genome. Using this setting, you can change the height of each pairwise signal in the image.
Example:
pairwiseHeight 10
speciesCodonDefault <species>This setting, which is used with "frames", declares the default species for the codon reading frame.
Example:
speciesCodonDefault hg19
frames myCodonFrames
speciesDefaultOff <species1> [species2 ...]To control which of
the stacked pairwise alignments are displayed or hidden by default, use
speciesDefaultOff to list the species alignments that will not be
displayed. Each species is specified as in the MAF
file Organism names except embedded dots and/or spaces
are replaced with underscores (e.g. C. elegans ->
c_elegans).
Example:
speciesDefaultOff galGal2 fr1 danRer1
speciesOrder <species1> [species2 …]Use speciesOrder to declare the order of the
stacked alignments. If there are many species in your track,
it may make sense to use the speciesGroups setting instead.
speciesGroups <sgroup1> [sgroup2 …]sGroup_<sgroupN> <species1> [species2 …]You can include a list of "clades"
to group the species into. This option is an alternative to
speciesOrder, used when there are many species. Each
speciesGroup in the list must have its own setting
(sGroup_<group>), followed by a list of species,
specified as for speciesOrder.
Examples:
speciesOrder panTro1 canFam1 mm5 rn3 \
galGal2 fr1 danRer1
speciesGroups Mammal Vertebrate
sGroup_Mammal mm9 rn4
sGroup_Vertebrate galGal2 fr1 danRer1
Choose one of these two alternatives to display species.
speciesUseFile <fileName>Deprecated
Much more rarely used, this setting can
replace speciesOrder and speciesGroups.
Set the speciesUseFile to a path relative to the apache cgi-bin.
The file should contain a single species name as the first word of each line.
Example:
speciesUseFile speciesLists/conserved8Way.txt
summary <tableName>This setting contains table name of MAF summary table. The summary
view is used when the browser display is zoomed out to contain a million
or more basepairs. A summary table is created from a multiple alignment MAF
file using the utility hgLoadMafSummary.
Example:
summary hg17Maf8waySummary
treeImage <imageFile>The phylogenetic tree can used to show the relations of the species in the multiple alignment should be included as an image file. This path is relative to the htdocs images directory (usually /images).
Example:
treeImage phylo/hg17Maf8way.jpg
wiggle <table1> <leftLabel1> <uiLabel1>
[table2 leftLabel2 uiLabelN ...]Optionally more than
one conservation signal can be included with your MAF display by
using this setting. When you include conservation wiggles, you
can also include the standard settings for controlling signal type
tracks. The setting includes three parts, then (optionally)
additional sets of three, all delimited by white space. The first
table is the default. The leftLabel is used to
prefix the label "Cons" in the left label area of the Browser
image. The uiLabel is displayed in the track
configuration page. If only one table is listed, and no label is
present, the default label "Conservation" will be
displayed. The labels cannot contain spaces, but underscores (_)
will be translated to spaces in the display.
Note: directly pairing the conservation signals within the wigMaf track is an older way of doing things. It is easier to give users control of what they want to see, by including your wigMaf track and separate signal type tracks as subtracks within a composite track. See the composite track description below.
Example:
wiggle phastCons8wayMammal Mammal Placental_Mammal \
phastCons8way Vertebrate Vertebrate
track hg17Maf8way
type wigMaf 0.0 1.0
summary hg17Maf8waySummary
wiggle phastCons
treeImage phylo/hg17Maf8way.jpg
speciesOrder panTro1 canFam1 mm5 rn3 galGal2 fr1 danRer1
speciesDefaultOff galGal2 fr1 danRer1
irows off
pairwiseHeight 10
maxHeightPixels 100:16:8
viewLimits 0.5:0.9
viewLimitsMax 0.0:1.0
...
This 8-way multi-alignment for the hg17 human assembly is defined to include a summary table, tree image and one wiggle table containing the conservation score for the 8 species. Notice that the pairwise alignments for the last three species are turned off by default, and each pairwise alignment will have a height of 10 pixels. With few species displayed by default, irows defaults to "off" as well, which will result in a cleaner display. Since there is a conservation wiggle, there are additional settings for that signal.
track multiz46way
type wigMaf 0.0 1.0
summary multiz46waySummary
frames multiz46wayFrames
speciesCodonDefault hg19
itemFirstCharCase noChange
treeImage phylo/hg19_46way.gif
speciesGroups Primate Placental_Mammal Vertebrate
sGroup_Primate panTro2 gorGor1 ponAbe2 rheMac2 papHam1 calJac1 tarSyr1 micMur1 otoGar1
sGroup_Placental_Mammal tupBel1 mm9 rn4 …
sGroup_Vertebrate macEug1 monDom5 ornAna1 …
speciesDefaultOff panTro2 gorGor1 ponAbe2 papHam1 …
pairwiseHeight 10
...
For this wigMaf
track, there is no wiggle defined. In this actual
example taken from the hg19 Genome Browser, the several conservation signals
displayed in concert with this multiple alignment are separate
signal-type tracks defined as part of the "Conservation"
composite track (see discussion of composites below). Notice
that the 46 species in this alignment are organized into clades
using the "speciesGroups" setting. Each clade has its
own "sGroup" setting to declare the order within (not
all species shown).
expRatio: Microarray expression data
NOT FOR HUBS. Nor are any of the settings in this section.
Though many microarray experiments have been superseded by high-throughput sequencing (e.g., ChIP-seq) experiments, several microarray tracks still exist. Further, microarray experiments can be the economical or practical choice in many instances. The datasets for the built-in microarray tracks in the Genome Browser are stored in bed 12+3 (bed 15) format that includes three additional fields: expCount, expIds, and expScores. To display correctly in the Genome Browser, microarray tracks require the setting of several attributes in the trackDb file associated with the track's genome assembly. Each microarray track set must also have an associated microarrayGroups.ra configuration file that contains additional information about the data in each of the arrays. Please refer to the microarray track section of the UCSC genomewiki for information on how to prepare microarray tracks. In particular, that document describes the format of the groupings.ra file that must be associated with an expRatio track.
Note: The expRatio data formats are reused for the
factorSource type.
type expRatioMicroarray data is
displayed in the Browser by expRatio type tracks.
The type requires additional settings: expScale, expStep and
groupings.
Example can be found below.
expDrawExons onIf microarray data
includes gene model or blocks within items, then the data can
be viewed as exons and introns by setting expDrawExons
to on. The setting is configurable by the user.
Example:
expDrawExons on
expScale <#>Maximum expression value.
Example:
expScale 3.0
expStep <#>Amount to step in
visible expression scale. A round number close to expScale divided
by 8 is best.
Example:
expScale 3.0
expStep 0.5
expTable <tableName>This setting specifies
the name of a table in the common hgFixed
database that contains names of experiments, etc.
groupings <fileName>A microarray dataset
must refer to a specific set of configurations to load from the
microArrayGroups.ra file. Please refer to the
microarray track
section of the UCSC genomewiki
for detailed instructions on the location of this file and its
format. Use the "groupings" setting to point to a stanza keyed on
"name" in that file.
Example:
groupings gnfHumanAtlas2Groups
track sestanBrainAtlas
type expRatio
expScale 3.0
expStep 0.5
expTable sestanBrainAtlasExps
groupings sestanBrainAtlasGroups
...
This microarray dataset refers to groupings
defined in the "gnfHumanAtlas2Groups" stanza of the
makeDb/hgCgiData/Human/microarrayGroups.ra file.
snpNNN: specialized subclass of BED 6 for dbSNP variants
NOT FOR HUBS. Nor are any of the settings in this section.
This particular variant of bed 6, identified by table name, is for UCSC's subset of dbSNP, NCBI's database of short genetic variants.
type bed 6 + # Track name starts with "snp"
followed by the 3-digit dbSNP build number UCSC's subset of dbSNP could be described as "bed 6 + 19" and is produced by a complex process starting with downloading several database dump files and fasta files from dbSNP, and ending with the creation of snpNNN and several auxiliary data tables. This type is not supported as a custom track type.
chimpDb <db>If chimp chains/nets were used to identify the chimp reference
assembly allele at the location homologous to the human SNP, this
specifies which chimp genome assembly was used, e.g. panTro2.
chimpMacaqueOrthoTable <table>If chains/nets from chimp and rhesus macaque were use to identify the chimp or macaque reference assembly allele at the location homologous to the human SNP, this specifies the database table that contains the mapped alleles.
chimpOrangMacOrthoTable <table>If chains/nets from chimp, orangutan and rhesus macaque were use to identify the chimp/orangutan/macaque reference assembly allele at the location homologous to the human SNP, this specifies the database table that contains the mapped alleles.
codingAnnoLabel_<table> <text>Deprecated; will probably be removed. This specifies a text label for display of <table>'s predictions of a SNP's effect on a protein-coding gene.
codingAnnotations <table>[,table]Deprecated; will probably be removed. This specifies one or more tables containing predictions of SNP effects on protein-coding genes.
defaultGeneTracks <genesTrack>[,genesTrack]The details page of a SNP can display the predicted functional affect on a gene from any genePred track. Since there are often many gene tracks and models, the prediction will depend upon the gene model used. The user has a chance to choose from those available, but this setting establishes a default gene track or tracks to base predictions on.
Example:
defaultGeneTracks knownGenes
defaultMaxWeight <1|2|3>dbSNP assigns a weight of 1, 2 or 3 to each variant, depending
on how many distinct mappings a variant's flanking sequences have
to the genome.
If this is set to 1, only uniquely mapped variants will
be displayed by default. If 2, only uniquely mapped
variants and variants with a small number of duplicate mappings will
be displayed. If 3, all variants will be shown regardless
of weight. Note: some tables such as snpNNNCommon and
snpNNNFlagged contain only uniquely mapped variants, so this
setting has no effect on those tables.
hapmapPhase <II|III>The SNP details page looks for the SNP's ID in HapMap track tables that have different names and contents depending on whether they were loaded from HapMap phase II or HapMap phase III data. (This setting is also used by HapMap SNPs tracks.)
macaqueDb <db>If macaque chains/nets were used to identify the macaque reference
assembly allele at the location homologous to the human SNP, this
specifies which macaque genome assembly was used, e.g. rheMac2.
orangDb <db>If orangutan chains/nets were used to identify the orangutan reference
assembly allele at the location homologous to the human SNP, this
specifies which orangutan genome assembly was used, e.g. ponAbe2.
snpExceptions <table>This specifies an auxiliary table that contains annotations of unusual properties of variants. This setting applies only to versions prior to dbSNP build 132; starting with build 132, exceptions are incorporated into the main snpNNN table and an auxiliary table is no longer needed.
snpExceptionDesc <table>This specifies an auxiliary table that maps exception keywords to one-sentence descriptions.
snpSeq <table>This specifies an auxiliary table that maps variant IDs to file offsets at which flanking sequences are stored.
snpSeqFile <path>This specifies an auxiliary file that contains the flanking sequences of each variant's representative submitted SNP.
track snp135Common
shortLabel Common SNPs(135)
longLabel Simple Nucleotide Polymorphisms (dbSNP 135) Found in >= 1% of Samples
group varRep
priority 99.0911
visibility dense
url http://www.ncbi.nlm.nih.gov/SNP/snp_ref.cgi?type=rs&rs=$$
urlLabel dbSNP:
snpSeq snp135Seq
snpExceptionDesc snp135ExceptionDesc
defaultGeneTracks knownGene
maxWindowToDraw 10000000
type bed 6 +
This track displays variants from dbSNP build 135 with Minor Allele Frequency (MAF) of at least 1%. Flanking sequence file offsets come from the snp135Seq table, descriptions of unusual properties are taken from the snp135ExceptionDesc table, and effects of variants on protein-coding genes are shown with respect to the table knownGene (UCSC Genes track) by default. If the viewed region is more than 10,000,000 base pairs, the data will not be loaded and drawn.
vcfTabix: Variant Call Format indexed by tabix
Variant Call Format (VCF) is a flexible and extendable line-oriented text format developed by the 1000 Genomes Project for releases of single nucleotide variants, indels, copy number variants and structural variants discovered by the project. The format has been subsequently adopted by other large projects. When a VCF file is compressed and indexed using tabix and then made web-accessible, the Browser will fetch only the portions of the file necessary to display items in the viewed region. In other words, this is a remote data file format, as are the BAM, bigBed and bigWig formats. Please refer to the VCF and tabix track format page for a complete description of how to prepare and display VCF data.
type vcfTabixIf the bigDataUrl setting is included, the data at the location
specified by that URL will be
displayed. Otherwise, a database table with a single column fileName
can specify the location of a local file or a URL.
If the database table includes a column seqName, a different
VCF file or URL can be specified for each assembly sequence.
Example can be found below.
track myVcf
type vcfTabix
bigDataUrl http://myorg.edu/mylab/myVcf.gz
maxWindowToDraw 3000000
...
The data for this VCF track is stored in the remote file, "myVcf.gz". That file is paired with a tabix-generated index file named "myVcf.gz.tbi" found in the same remote location.
pgSnp: Personal Genome SNP format
NOT FOR HUBS. (None of the settings in this section apply to hubs.)
This format is used to display SNPs from personal genomes. It is used for the Genome Variants and Population Variants tracks. Please refer to the FAQ for information on how to prepare personal genome SNP datasets.
type pgSnpPersonal Genome SNP
type tracks are essentially in "bed 4 + 3" format.
The fourth column, name, is filled with one or more variants
(including insertions and deletions) delimited with a '/'
character. The fifth column contains the number of variants found
in the name column, while the sixth and seventh columns contain
comma-delimited arrays of frequencies and scores respectively.
Files in this format can be loaded into MySQL with hgLoadBed using
the "pgSnp.sql" schema.
The browser image displays variants as stacked boxes that show the frequency for each variant, if that information is in the table. The details page for each variant item computes any amino acid change if the variant is in a coding region.
pgPolyphenPredTab <table>Not supported for custom tracks
Auxiliary table with likelihoods of variant damage to proteins from polyPhen.
pgSiftPredTab <table>Not supported for custom tracks
Auxiliary table with likelihood of variant damage to proteins from SIFT.
track mySnps
type pgSnp
...
A personal genome SNPs track displaying single nucleotide polymorphisms from the reference genome.
altGraphX: Alternate splicing gene model tracks
NOT FOR HUBS.
Gene models with alternate splicing can be displayed in the Browser with this type of track. It supports no trackDb settings beyond the common ones.
type altGraphXAlternate slicing gene models specialized track used to show genome coverage.
track sibTxGraph
shortLabel SIB Alt-Splicing
type altGraphX
url http://ccg.vital-it.ch/cgi-bin/tromer/tromergraph2draw.pl?species=H.+sapiens&tromer=$$
urlLabel SIB link:
idInUrlSql select name from sibTxGraph where id=%s
...
The Swiss Institute of Biology's
alternative splicing track provides an external link via the url
setting. But the actual "tromer" term in the value
will be filled in with the results of a query to the sibTxGraph
table. With enough obscure settings, the Browser accomplishes
subtle things.
bedDetail: Text extended bed track
NOT FOR HUBS.
This is an extension of BED format. BED detail uses the first 4 to 12 columns of BED format, plus 2 additional fields that are used to enhance the track details pages. The first additional field is an ID, which can be used in place of the name field for creating links from the details pages. The second additional field is a description of the item, which can be a long description and can consist of html, including tables and lists.
type bedDetail <#>Extended bed type
format that has a text description embedded in the table for each
item. The format can vary between 4 and 12 standard bed columns
plus two additional ones. The number of columns (including the 2
bedDetail specific columns) must follow the "bedDetail" term in
the type setting.
Example can be found below.
track microattrLoci
type bedDetail 14
itemRgb on
url http://www.ncbi.nlm.nih.gov/entrez/viewer.fcgi?db=nucleotide&sendto=t&extrafeatpresent=1&list_uids=$$
...
This bedDetail contains details for each item formatted for HTML display. In addition each item has an "id" as distinct from the "name" and that id is used in the outside link url displayed in the item details page.
clonePos: Genome coverage tracks
NOT FOR HUBS.
This is a specialized format track that is only used for showing the coverage in the human genome. It supports no trackDb settings beyond the common ones.
type clonePosA specialized track used to show genome coverage.
track clonePos
shortLabel Coverage
longLabel Clone Coverage/Fragment Position
type clonePos
altColor 180,180,180
...
The Coverage track for the human genome will vary in color between black and light gray, based upon the cloned sequence coverage depth.
ctgPos: Physical map contigs tracks
NOT FOR HUBS.
This is a specialized format track that is used for "physical map contigs" on the human genome. It supports no trackDb settings beyond the common ones.
type ctgPosA specialized track used to show the locations of contigs on the physical map.
track ctgPos2
shortLabel GRC Map Contigs
type ctgPos
url none
...
The GCR Map Contigs track would normally generate a URL to NCBI, but in this case, the URL has been explicitly blocked.
downloadsOnly: Specialized track that contains only downloadable files
NOT FOR HUBS.
The ENCODE tracks all
have a special directory and CGI support for downloading files. This
can be very helpful for organizing access to the often very large
number of downloadble files associated with an ENCODE track. There
are a handful of datasets that don't readily lend themselves for
visualization in our Browser but are nonetheless a necessary
component of the ENCODE data as a whole. Therefore, downloadsOnly
type was developed to provide easy access to these sets of
downloadable files.
type downloadsOnlyA specialized track that provides access to a set of downloadable files, and is currently ENCODE only. A downloadsOnly type track does not get visualized in the Browser.
Example can be found below.
fileSortOrder ...The fileSortOrder setting is required for
downloadsOnly type tracks. A complete description can be found in
composite tracks section of this document. It requires each file
to be defined as an object in the metaDb and each of those objects
to refer to a "composite" which will be the name of this track and
the directory name where the files are located. The
"fileSortOrder" defines the column and default sort order. The
user will be able to sort and filter the list of files.
track wgEncodeUmassWengTfbsValid
type downloadsOnly
fileSortOrder cell=Cell_Line \
dccAccession=UCSC_Accession \
fileSize=Size \
fileType=File_Type \
dateSubmitted=Submitted \
dateUnrestricted=RESTRICTED<BR>Until
wgEncode 1
...
The Browser will not provide visualization of
this track but will provide access to downloading any number of
files organized into a single group. The downloads page
presents those files in a table with a number of columns that are
sortable and possibly filterable. Much of the presentation and
organization relies upon settings established in the metaDb for
this track. However, the fileSortOrder setting has requested six
specific columns to be presented in the desired order.
encodeFiveC: Five C Chromatin interaction track
NOT FOR HUBS.
This is a specialized
format track that was used for displaying long distance
chromatin/chromatin interaction evidence. Essentially a "bed"
type track displaying locations in the genome. The details page of
each location presents a list of other locations within the genome
that may have functional interactions.
type encodeFiveCA specialized track that was used to show the locations where chromatin may have interactions with other chromatin locations.
interTable <tableName>Each location found in the track's main table should have associated regions defined in the interactions table named with this setting. The interactions table format is essentially a "bed 7 + 1".
interTableKind <label>The table of interactions is presented on each item's details page and is titled as "Top ___ interactions"
track encodeUw5cGM06990dS9013DhsLoci
type encodeFiveC
color 200,100,0
interTable encodeUw5cGM06990dS9013DhsInter
interTableKind TSS
...
This Five C interactions track will be displayed as colored items. The associated chromatin regions are drawn from a second table. The kind of associations are transcription start sites.
factorSource: Combined items tracks
NOT FOR HUBS.
Factor source is not a
group track, but a track that is made from a group of sources, which
may themselves be Browser tracks. This is a specialized type of
"item" based track of "bed 15" format, the same format
used for type expRatio. Its purpose is to
display transcription factors as detected in multiple cell lines,
though it might be adaptable for any type of item that piles up
into overlapping locations and will belong to one of several
categories. However, this type was specifically designed for
combining transcription factor (TF) binding evidence from multiple
cell lines into a single track. As a bed type track, it consists of
items or regions where there is evidence of TF binding. To the left
of each item, the factor name is displayed, while to the right a
coded list of cell types where the evidence has been found is
displayed. Unlike most item-based tracks, a second table is required
to describe the cell lines. Use the program hgBedsToBedExp to create
the tables from a collection of simpler beds, one for each
transcription factor/cell interaction.
type factorSourceA bed 15 based table format with overlapping items. This is a specialized track type designed for holding transcription factor binding evidence across multiple cell lines. The format is the same as used for microarray expression.
Example can be found below.
sourceTable <table>The factorSource type tracks need a secondary table that holds descriptions of the sources. This is where cell line abbreviations are declared and associated with actual cell lines.
inputTrackTable <table>When viewing the details for a factorSource
track item (typically a TF binding site), additional information
about the cell line evidence can be displayed. This setting names
a table that will hold the additional information. It is used in
conjunction with the inputTableFieldDisplay setting.
inputTableFieldDisplay <f1> [f2...]If there is an inputTrackTable defined with
your track, the fields that are to be displayed should be declared
with this associated setting.
filterBy <field1:title=[+]option1a...>
[field2:title=[+]opt2a...]This setting provides user filtering of factorSource items by factor name. The simplest use is to include a comma-separated list of all factor names in the track as an argument to the setting. A complete description of this setting can be found in the bed/bigBed item-based track settings.
motifTable <table>
A bed 6 table that holds motif regions
to highlight within factorSource items.
motifMapTable <table> If motif names differ from or are not unique for factorSource item names
in the motifTable, this table can used to remap the names.
This table has a simple 2 column format: char(255) factor, char(255) motif.
motifPwmTable <table>When viewing the details of a factorSource track item containing
a binding motif in the motifTable, the
consensus motif sequence and sequence logo image can be displayed.
This setting names the table holding the position weight matrices
that provide this information.
motifMaxWindow <integer>Display of highlighted motifs in a factorSource track can be limited using this setting. In large genomic regions motifs are not well distinguished in the display, and performance is improved by suppressing the feature.
motifDrawDefault <on/off>If a factorSource track has a motifTable, this setting controls whether motifs are drawn by default. It is also configurable by the user.
track tfbsByCellLines
type factorSource
sourceTable myCellLines
inputTrackTable myCellLineAssociations
inputTableFieldDisplay cellType treatment lab
motifTable transfacMotif
motifPwmTable transfacMotifPwm
motifMapTable transfacMotifTarget
motifMaxWindow 30000
motifDrawDefault on
...
This track will show transcription factor (TF)
binding evidence found in multiple cell lines. Each item represents
a particular TF, along with the cell lines that show
evidence of binding in that location. The secondary sourceTable
holds the definitions of each cell line abbreviation. A third
table is declared with inputTrackTable and carries details for
each cell line that should be seen in the Browser. When viewed in
item detail, 3 fields (cellType, treatment and lab) will be seen
for each cell associated with the particular TF binding location.
rmsk: Repeat masking tracks
NOT FOR HUBS.
This is a specialized format track that is used only for the repeat-masking track. For completeness it is being briefly described here. These tracks are created created by using Arian Smit's RepeatMasker program, which screens DNA sequences for interspersed repeats and low complexity DNA sequences.
type rmskThe repeat masker tracks contain uniquely formattted data for the special function of repeat-masking.
Example can be found below.
track rmsk
spectrum on
type rmsk
maxWindowToDraw 10000000
...
The repeat masker track will have individual repeat items shaded by a measure of how exact a repeated element is withing the stretch of repetition. This track is restricted to display at less than 10 million base resolution.
snake: Self referencing alignment tracks - EXPERIMENTAL
NOT FOR HUBS.
This is a specialized format track that shows the snaking course of bi-directional and overlapping alignments. This format can help illustrate inversion-type rearrangements that align to the plus strand, then the minus strand, and again to the plus strand. It can also be used to illustrate overlapping alignments, such as when a duplication has occurred compared to the reference genome.
type snake <db>otherDb <otherDb>A specialized track used to show the path of snaking alignments that represent chromosomal rearrangements, duplications and inversions. Since this type is almost always a mapping between two species or two assemblies of the same species, the type must also declare that species/assembly by database name.
As with chains and netAligns, which typically show mappings between two assemblies,
the "otherDb" setting is also needed to declare which other genome and assembly
the data in this track represents.
track snakeMm9
type snake mm9
otherDb mm9
color 100,50,0
altColor 255,240,200
spectrum on
...
This snake track will illustrate chromosome rearrangements that have occurred on the mouse mm9 genome as seen when it is aligned to the human genome.
Predefined major track groupings
NOT FOR HUBS.
The simplest grouping:
group <groupId>All tracks belong to one of several groups. Hub tracks belong to the group that encompasses their hub. Other tracks belong to one of the predefined groups. For hg19 the following groups are defined:
map- "Mapping and Sequence"phenDis- "Phenotype and Disease Associations"genes- "Genes and Gene Prediction"rna- "mRNA and EST"expression- "Expression"regulation- "Regulation"compGeno- "Comparative Genomics"neandertal- "Neandertal Assembly and Analysis"varRep- "Variation and Repeats"
If no group is set for a built-in track, then the track will end up in the Experimental Tracks section at the bottom.
track myTrack
group regulation
...
Supertrack settings
The first hierarchical container is called the supertrack, which may be thought of as a folder that holds other tracks. The Browser currently supports only one level of supertrack folders. Generally the subtracks of a supertrack are of differing types. If all the children are of the same type, it is often better to use the "compositeTrack" grouping described below. If all of the children are wig or bigWig tracks, it may be of interest to use a signal overlay "container multiWig" grouping. Signal overlay tracks display the signal data from several subtracks as colored transparencies, making it possible to see the data of several tracks together in a condensed view. See the multiWig section for more information.
Supertracks can contain composite tracks and container multiWigs, but not vice versa. With supertracks, composite tracks, and container multiWigs, children will inherit the settings from their parents, but can override their parent settings within their own stanzas.
superTrack onTo declare a supertrack, simply add this
setting to a track definition that will hold a few standard
settings. To set a supertrack to display as default add the word show,
superTrack on show, to the end of the statement.
When attempting to debug visibility settings, it may be
helpful to read the note about
inheritance found below.
parent <superTrack>Membership in a supertrack, composite, or aggregate track is declared by the child, not the supertrack itself. Any number of children may belong to one supertrack, but ten is a suggested maximum number for usability considerations. Stylistically, children's stanzas within the trackDB typically are indented directly under the stanza of the parent. However, this is less frequently the case with supertracks, because the children are often scattered in other places within the trackDb file, or the supertrack children are themselves composites containing additional indentation that makes enforcement of the supertrack indentation impractical.
track myFolder
superTrack on
group regulation
shortLabel My Folder
longLabel My folder keeps my tracks together
...
track myFirstTrack
parent myFolder
visibility dense
...
track mySecondTrack
parent myFolder
visibility none
...
The supertrack called "My Folder" contains two children. All will be grouped under "regulation". Notice that the first track is visible by default (if the supertrack itself is visible), but the second track is not.
Composite Tracks
Composite tracks are
another level of hierarchy and are meant to group very similar tracks
(called "subtracks") together such that they can all
share the same configuration settings. In its simplest form a
composite holds tracks all of the same type (such as bigBed).
Initially, all track within the set are configured identically.
Usually only some of the subtracks are visible by default, and these
will have the same display mode (e.g., dense)
and optional settings (e.g., viewLimits).
While default settings cover the entire composite of related tracks,
in most cases individual subtracks can be configured by the user
independently of the composite settings. However, once individual
subtrack settings are made, they can be overridden by new choices made at
the composite level. It may be helpful to read the "Note about
inheritance" found below.
Currently only the following track types can be organized into a composite: item-based tracks (bed, bigBeg, broadPeaks, etc.), signal-based tracks (wig, bigWig, etc.), other remote file-based tracks (bams, vcf, etc.), chains/nets, genePred, psl, and wigMaf-type tracks.
Composite Tracks
Composite tracks are
another level of hierarchy and are meant to group very similar tracks
(called "subtracks") together such that they can all
share the same configuration settings. In its simplest form a
composite holds tracks all of the same type (such as bigBed).
Initially, all track within the set are configured identically.
Usually only some of the subtracks are visible by default, and these
will have the same display mode (e.g., dense)
and optional settings (e.g., viewLimits).
While default settings cover the entire composite of related tracks,
in most cases individual subtracks can be configured by the user
independently of the composite settings. However, once individual
subtrack settings are made, they can be overridden by new choices made at
the composite level. It may be helpful to read the "Note about
inheritance" found below.
compositeTrack onTo declare a composite, simply add this setting to a track definition, along with a few standard settings. The subtrack stanzas always follow immediately after the composite track delaration and are indented from it.
Note that since children of composites inherit their parent's settings, many more trackDb settings will be found at the composite level than at the supertrack level.parent <composite> [off/on]Membership in a composite is declared by the
subtrack child, not the composite itself, through this setting. Any number of subtracks may
belong to one composite, but display performance degrades significantly beyond a
few hundred. Set the parent setting to "on" to
indicate whether a subtrack should be visible (checked, selected) by default.
allButtonPair onWhen a simple composite track presents a short list of
subtracks, it can be convenient for the user to have an easy way to select or
deselect all of them. Include this setting to display an "All
"
(plus and minus button pair) for the user's convenience. If
the list contains more than 10 subtracks, other methods may be
more useful for organizing and selecting subtracks (described below).
centerLabelsDense <off/on>By default, only the composite track's single center label is shown when the
subtracks are displayed together in the Browser dense mode.
If centerLabelsDense is set to "on", the Browser will display a center
label for each subtrack.
dragAndDrop onThe subtrack list in the configuration page can be rearranged by setting a sortOrder, as described below, or by allowing the user to drag and drop the subtracks to a new order if enabled with this setting. The changed order will also be seen in the track image. However, the order of tracks can always be rearranged through drag and drop, directly in the image. Reordering subtracks in the image will not be reflected in the configuration page. Note: This setting will not work correctly if 'container multiWig' is specified.
track myComposite
compositeTrack on
parent myFolder
shortLabel My Composite
type bigWig 0 1.0
viewLimits 0.0:0.2
allButtonPair on
dragAndDrop on
...
track myFirstSubtrack
parent myComposite on
...
track mySecondSubtrack
parent myComposite
...
The composite with two subtracks shown. All
subtracks are of type bigWig and all have a default viewLimits of 0 - 0.2.
Notice the first subtrack is checked by default, but the second is not
(parent setting). However, the Browser will display two buttons
(allButtonPair setting) that allow the user to
select all subtracks, or deselect all of them and then check only those of
interest. The user may reorder the subtracks by dragging them on the composite
configuration page (dragAndDrop setting). Note: The dragAndDrop setting
will not work correctly if 'container multiWig' is specified.
Subgroups
Within a composite track, two different grouping styles can be used to allow the user to select tracks for display in the Browser. This section describes the configuration of "subgroups"; "views" are discussed in a subsequent section.
The subgroup can be used for selecting sets of subtracks for display based on certain characteristics of the data. For instance, if "cell" and "antibody" are defined as subgroups within a composite track, the user will be able to select subtracks based on specific cell types and antibodies to display in the Browser. Up to 9 subgroup types can be defined for a composite. However, to minimize the complexity, it is strongly recommended that only two subgroups be defined for a given composite track. These will be presented in a simple X/Y matrix that is easy for the user to understand and navigate. It is possible to define more subgroups in additional "abc" dimensions that will be presented to the user as drop-down multi-select dialogs, but use of these should be avoided or minimized.
subGroup1 <gTag1> <gTitle1> <mTag1a=mTitle1a>
[mTag1b=mTitle1b…]subGroup2 <gTag2> <gTitle2> <mTag2a=mTitle2a>
[mTag2b= mTitle2b…]Up to 9 subgroups may be declared, one per line. Each subgroup declaration
must include a whitespace-delimited tag, title, and one or more tag/title
membership pairs joined by an '=' equals sign.
-
tag: Used in the code to select and sort subtracks based upon their membership. Tag names must be alphanumeric, begin with a letter, and be formed such that the desired sort order of the member subtracks will result. -
title: Label of the subgroup as it appears on the selection matrix that is displayed to the user, e.g.,"Antibody". Spaces within titles must be replaced by '_'. A limited amount of HTML is allowed in titles, such as the insertion of Greek letters using an HTML code. Any use of HTML should be tested to ensure that it displays correctly.
Because subgroup settings are often lengthy, it is recommended that the
'\' line continuation character be used to break up the setting over
multiple lines for easier reading.
subGroups <gTag1=mTag1?> [gTag2= mTag2?]The subtracks themselves declare their
membership in a group with the subGroups setting.
Each subtrack must declare its membership in all of its
composite's subgroups. Notice that membership is declared
by pairs of tags: the group tag (e.g. gTag1) is paired with that
group's member tag (e.g. mTag1b) as gTag1=mTag1b (cell=K562).
dimensions <dimX=gTag#> [dimY=gTag#] [dimA=gTag# ...]In order to define the type of UI desired for selecting subtracks based upon groups, additional settings are needed at the composite level. For a one- or two-dimensional array of checkboxes, declare the dimensions X and Y. Additional dimensions (called "abc") can be declared with this setting as dimA, dimB, etc.
Note that the order of the subgroups in a dimension is exactly the same as
the order they appear in the subGroup# setting, regardless of whether
the subtrack list is sorted by tags.
filterComposite <dim[A/B/C][=one]> [dimB dimC ...]For the "abc"
dimensions, rows of checkboxes will be shown by default. However, this
UI can be confusing, especially combined with a one- or two-dimensional matrix.
Instead, it is recommended that you organize "abc"
dimensions as drop-down multi-selects, often referred to as
"filter" boxes due to their similarity to the
filterBy setting discussed
above. Declare the subtrack filter boxes with the filterComposite
setting. Filter composites may work with or without the X/Y
matrix, but are restricted to the "abc" dimensions.
By default, the filter box for selecting
subtracks is multi-select, meaning more than one choice is
allowed. It is possible to restrict this to a single choice by
adding the "=one" option to the filter box definition.
This might make sense when there are only 2 choices. The choice
of "all" is always available, while choosing nothing is an invalid
case.
dimension<?>checked <mTag1a>
[mTag1b …]One more complication in the selection process is determining which subgroup options are selected by default. In the case of the X/Y matrix this can be determined by what subtracks are currently checked. But, "abc" dimensions must have their selected state declared explicitly using the dimension<?>checked setting.
controlledVocabulary <pathToFile> <gTag#=mdbVar>
[gTag#=mdbVar …]NOT FOR HUBS. Currently used only by ENCODE
In ENCODE, subgroups are often based on metadata terms declared in the metaDb table and defined in the "controlled vocabulary", which is stored as an ra file. In this situation, the labels of these terms, as they are displayed in the track configuration page, can be linked to the controlled vocabulary definitions. These links can be quite useful, as the term definition may include protocol documents and validation evidence. In order to establish the links, each subGroup's tag must be tied to the actual metaDb term.
sortOrder <gTag#=+/-> [gTag#=- …]When declaring subgroups, it is often useful to
sort the subtrack list by those subgroups. By including a
sortOrder setting, long sets of subtracks are more easily
organized and navigated by the user. If there are only a few
subtracks in the composite, sorting may be of little value and
dragAndDrop may be a better option.
Currently only subgroups can be defined in the sortOrder, but it
is anticipated that this will expand to include short and long
labels as well. Sorting will occur on the tag values defined in the
subGroup# and subGroups settings. By sorting
on tags, non-alphanumeric orders can be defined.
fileSortOrder <var=val> [var=val ...]NOT FOR HUBS. Currently used only by ENCODE
Some composite track sets have their own
directories of downloadable files and a special CGI for accessing
those files. In order to see the CGI interface for the download
directory, the composite needs an object for each file defined in
the metaDb. The trackDb stanza for the composite also needs to
have the fileSortOrder setting defined. The setting is defined as
a set of variable=value pairs, which defines the default sort
order on metaDb variables. The "var" portion of the each pair is
a term defined in the metaDb for all of the file objects in the
directory. The "var" may also be "fileType" or "fileSize",
which are not defined in the metaDb. The "val" is the title that the
user will see as the column header for the sortable table of
files. This value can contain and '_' for spaces and limited HTML
codes and special characters. As always, you are encouraged to
experiment. The '\' continuation character should be used to
break up this long setting into readable lines.
track myComposite
compositeTrack on
subGroup1 cellLine Cell_Line \
A1GM12=GM12878 \
CD14=CD14+ …
subGroup2 ab Antibody \
H3K04ME3=H3K4me3 \
H3K36ME3=H3K36me3 …
dimensions dimX=ab dimY=cellLine
sortOrder cell=+ ab=+
...
track myFirstSubtrack
parent myComposite on
subGroups cellLine=CD14 ab=H3K04ME3
...
This examples shows a composite with
one subtrack and two subgroups. The
dimensions setting declares X and Y dimensions, which will display
a 2D matrix on the composite's configuration page. Notice that the
title of the cellLine subgroup contains a blank space filled in
with '_'. The second cell line, "CD14+", includes an HTML encoding
for '+' in its title, The two subgroups participate in the default
sort order of subtracks, but they each have non-standard sort orders. In the
cellLine subgroup, GM12878 sorts first by starting its tag with "A". The
antibodies have numbers in their titles, but the tags expand
the number with "0" to pad the spacing. This ensures
H3K4me3 sorts before H3K36me3.
track myCompositeIs3D
compositeTrack on
subGroup1 cellLine Cell_Line \
A1GM12=GM12878 \
CD14=CD14+ …
subGroup2 ab Antibody \
H3K04ME3=H3K4me3 \
H3K36ME3=H3K36me3 …
subGroup3 treat Treatment \
TNFA=TNF-alpha \
ZNONE=None …
dimensions dimX=ab dimY=cellLine dimA=treat
filterComposite dimA
dimensionAchecked ZNONE
controlledVocabulary encode/cv.ra cellLine=cell \
ab=antibody \
treat=treatment
sortOrder cell=+ ab=+ treat=-
fileSortOrder cell=Cell_Line \
antibody=Antibody \
fileSize=Size
...
track myFirstSubtrackIn3D
parent myCompositeIs3D on
subGroups cellLine=CD14 ab=H3K04ME3 treat=ZNONE
...
In this second example composite, one subtrack and three subgroups are shown. As in the previous example, the dimensions setting declares X and Y dimensions, resulting in a 2D matrix of "Antibody" and "Cell Line" options. A third "Treatment" subgroup is declared as the "A" dimension; the user will be able to select subtracks for this dimension via a dropdown multi-select filter box. All three subgroups participate in the default sort order of subtracks, and the treatment subgroup is sorted in reverse order by default. The "None" treatment sorts before all others (in reverse order) by beginning the tag with a "Z". Note that for this "A" dimension, the "None" treatment will be selected by default. By declaring the proper settings, using subGroups to organize a composite can be quite powerful.
This example illustrates that subgroups, dimensions, and (in the case of ENCODE) controlled vocabulary and metadata all must be linked together for the composite to fully work. Further, the actual terms, programmatic "tags" and user visible titles all have different constraints and roles to play in establishing this cohesion. Subgroup tags are used to organize subtracks, while lettered dimensions organize the configuration page to more easily select subgroups of subtracks. For ENCODE tracks, the subgroups may be represented as metadata "terms" (distinct from tags) that are often carefully defined by a controlled vocabulary. In the example above, the tag "ab" is used to organize subtracks into subgroups but is also tied to dimension X. This ensures that antibodies will appear as the horizontal dimension in the 2D matrix on the configuration page, and the selection of an antibody will select the associated subtracks. Of course the user does not see the antibody as "ab" but "Antibody". Going further, the term as defined in controlled vocabulary is "antibody", so that for all the tables and files associated with this composite track, their metaDb objects should contain an "antibody" var and a given antibody (e.g. H3K4me3) will be found in the controlled vocabulary with a validation document. All the relationships can be confusing, but the trackDb settings, if done correctly, can tie all these elements together in a nice cohesive package.
track myComposite
compositeTrack on
subGroup1 cellLine Cell_Line \
A1GM12=GM12878 \
CD14=CD14+ …
subGroup2 ab Antibody \
H3K04ME3=H3K4me3 \
H3K36ME3=H3K36me3 …
dimensions dimX=ab dimY=cellLine
sortOrder cell=+ ab=+
...
track myFirstSubtrack
parent myComposite on
subGroups cellLine=CD14 ab=H3K04ME3
...
This examples shows a composite with
one subtrack and two subgroups. The
dimensions setting declares X and Y dimensions, which will display
a 2D matrix on the composite's configuration page. Notice that the
title of the cellLine subgroup contains a blank space filled in
with '_'. The second cell line, "CD14+", includes an HTML encoding
for '+' in its title, The two subgroups participate in the default
sort order of subtracks, but they each have non-standard sort orders. In the
cellLine subgroup, GM12878 sorts first by starting its tag with "A". The
antibodies have numbers in their titles, but the tags expand
the number with "0" to pad the spacing. This ensures
H3K4me3 sorts before H3K36me3.
track myCompositeIs3D
compositeTrack on
subGroup1 cellLine Cell_Line \
A1GM12=GM12878 \
CD14=CD14+ …
subGroup2 ab Antibody \
H3K04ME3=H3K4me3 \
H3K36ME3=H3K36me3 …
subGroup3 treat Treatment \
TNFA=TNF-alpha \
ZNONE=None …
dimensions dimX=ab dimY=cellLine dimA=treat
filterComposite dimA
dimensionAchecked ZNONE
sortOrder cell=+ ab=+ treat=-
...
track myFirstSubtrackIn3D
parent myCompositeIs3D on
subGroups cellLine=CD14 ab=H3K04ME3 treat=ZNONE
...
In this second example composite, one subtrack and three subgroups are shown. As in the previous example, the dimensions setting declares X and Y dimensions, resulting in a 2D matrix of "Antibody" and "Cell Line" options. A third "Treatment" subgroup is declared as the "A" dimension; the user will be able to select subtracks for this dimension via a dropdown multi-select filter box. All three subgroups participate in the default sort order of subtracks, and the treatment subgroup is sorted in reverse order by default. The "None" treatment sorts before all others (in reverse order) by beginning the tag with a "Z". Note that for this "A" dimension, the "None" treatment will be selected by default. By declaring the proper settings, using subGroups to organize a composite can be quite powerful.
Views
In addition to subgroups, a single
composite can be divided into multiple "views". Recall
that a composite should be made up of subtracks of the same type.
However, different types of subtracks can be combined into the same
composite track if they are in separate "views". While
views are like subgroups in many ways, they can carry their own
settings. This is necessary because the views within a composite may be for different
types that have their own distinct configuration settings, for example bigBeds and
bigWigs.
The "view" (or "multi-view") organization is typically used when the same basic data is stored in multiple formats and granularities. For example, a collection of views may include short read sequence alignments (type bam), signals representing pile-ups of aligned reads (type bigWig), and the peaks (type bigBed) that are called in regions where the evidence of experimental result is deemed significant. These three "views" of the same experimental data can be seen more informatively as a cohesive set within a multi-view composite track.
Views are declared both as a subgroup and as a separate track stanza. A composite with multiple views has only views as children, and each view will have one or more subtracks as children. The three levels must be defined together with indenting to make the hierarchy obvious.
An anomaly within the inheritance scheme is the "
visibility" (display mode)
setting. Unlike other settings, visibility is cumulatively restrictive from the
supertrack level. That is, if the parent has a visibility of "dense" and the
child's visibility is
"pack", the child will be displayed as "dense". If the parent is
subsequently changed to "full" display mode, the child will now be shown in
"pack" mode. At the trackDb
level, default visibility is always cumulatively restrictive.
However, when a user explicitly changes a subtrack visibility to be
greater than what was inherited from parents, that subtrack's
visibility will override the inheritance. While the subtleties of
inheritance can be hard to explain, they are often intuitive in
practice.subGroup1 view <Views> <vTag1a=vTitle1a> [vTag1b=vTitle1b…]track <viewName>view <viewTag>A view is always declared both as a subgroup
and in a track stanza itself. The subgroup declaration is like
previous declarations, but the view subgroup must have the tag
view and be declared as the first subgroup. Note
that the view stanza follows the composite stanza with one level
of indentation. Subtracks will follow their view with an
additional level of indentation.
subGroups view=<vTag1>…parent <viewName> [off/on]A subtrack declares its membership in a view both as subgroup membership and with a parent setting that refers to the view track name. Note that a track can only have one parent. When the subtrack's parent is a view, the composite track is its implicit grandparent.
viewUi onIf subtracks within a view are configurable, then the view will have the configuration controls for it in a box beneath the view's visibility drop down. That box filled with configuration controls is hidden by default so that the UI is not too cluttered. The user must first open the box before its contents are seen. If there is only one view with configuration settings, or if the view is the most important one, the box can be open by default. Use this setting in the view stanza of settings to default the configuration box as open.
configurable <off/on>Tracks are configurable by default if their track type supports this, and views and composites are configurable if their children's track type supports this. Finally individual subtracks are configurable by default if their track type supports it. Sometimes it is desirable to turn off configuration. Configuration may be turned back on when it has been turned off at a higher level. For example, this might be useful in a situation with a multi-view composite where the composite level would normally be configurable, but you want only one of the views and not all of the children of that view to be configurable. While this setting might be rarely needed, it can help restrict the user from viewing your data in inappropriate ways.
track myMultiViewComposite
compositeTrack on
visibility dense
subGroup1 view Views PK=Peaks SIG=Signals
subGroup2 cell Cell_Line \
A1GM12=GM12878 \
CD14=CD14+ …
subGroup3 ab Antibody \
H3K04ME3=H3K4me3 \
H3K36ME3=H3K36me3 …
dimensions dimX=ab dimY=cell
sortOrder cell=+ ab=+ view=+
type bed 3
...
track myViewPeaks
parent myMultiViewComposite
shortLabel Peaks
view PK
visibility pack
type bigBed 6 +
scoreFilter 0
scoreFilterLimits 0:1000
viewUi on
...
track myFirstPeakSubtrack
parent myViewPeaks on
subGroups cell=CD14 ab=H3K04ME3 view=PK
...
The composite has two views, one of which is shown, along with a single subtrack belonging to that view. Notice that the view does not participate in the dimensions setting, as it is an implicit dimension controlled by a row of visibility dialogs at the top of the composite configuration page. Notice that the view does participate in the sortOrder setting like other subgroups. In this example, the peaks view contains bigBed subtracks that all share the scoreFilter defaults defined at the view level. Almost any setting that is common to the whole tree can be defined at the composite level; any setting that is common to the view can be set at the view level; and any setting that is specific to one subtrack should be set at that level. Remembering inheritance, we can see that the subtrack shown inherits its track type from the view, but has its default visibility limited by the composite. That is, it inherits packed visibility from the view but the composite will show all visible subtracks as dense.
One additional thing to note is that this composite track is
"type bed 3". Composites do not need a type to define
their data format, since all data is associated with subtracks. Further,
multi-view composites almost always have multiple data formats.
But the "type" also controls what configuration options may be offered
for a track. Typically, a single level composite has the same type as
all of its subtracks and offers user configuration options at the top
level. But a multi-view composite is most often given the bare-bones
"type bed 3", and offers user configuration options at
the view level. Exceptions to this pattern do exist but they are rare.
Aggregate or Overlay Tracks: multiWig
In some instances, data from multiple tracks is so closely
related that it makes sense to view it as a single track. The
premiere example of this is the signal overlay
track (i.e. "multiWig"). Signal overlay tracks display the signal
data from several subtracks combined in several different ways, making it
possible to see the data of several tracks together in a condensed
view. The default overlay method for multiWigs is as colored transparencies,
in which all the graphs are drawn on top of one other in such a way
that overlapping regions are a different color. Another choice
is solid overlay, where all the graphs are still drawn overlapping each
other, but without transparency. A third choice is stacked
where the values of the subtracks are stacked on top of one another with
no overlap such that the total height of the wiggle is the sum of
all the values in the subtracks.
The value of the overlay track surpasses simply condensing the
image. Occasionally this is the most effective way to identify
hidden relationships in the underlying data. The overlay track
should not be overused, however. Attempts to overlay too many
subtracks can hide important information as regions with many layered
signals become too dark to interpret. More than eight subtracks in a
single overlay may prove less than ideal. As with composites,
it is important for the multiWig tracks to have the same data dimensions,
i.e. a signal height of 100 should be interpretable in the same
way for the whole set of tracks. While this is true for a composite
or view, it is especially important for overlay tracks. You cannot
reasonably overlay a signal from 0-1 with another signal from 0-1000.
container multiWigSignal overlay tracks are declared much like
simple composites. However, instead of a "composite"
setting, they declare themselves as a "container" of
"type multiWig". Like simple composites, all subtrack
types should be identical and the container itself should be
declared as the same type (e.g. "bigWig"). Also like a composite,
the container parent should have common settings for all children.
Unlike composites, containers can have neither subgroups nor
views. Additionally, all subtracks within a container are configured as one;
there is no independent configuration of individual subtracks. Even when the user
sets the overlay method to none and the subtracks are viewed as
separate signals, they are still configured as a set.
parent <containerTrack>Membership in a container track is declared at the subtrack level. The subtracks should be defined with indent beneath their container parent.
aggregate <transparentOverlay/stacked/solidOverlay/none>It is important to declare an aggregation method; otherwise, this set of tracks displays
as a composite would, with additional restrictions. Of the four options, the preferred
setting is transparentOverlay. The setting stacked
will draw the graphs in stacked mode.
The setting solidOverlay should not be used if there
are more than a couple of tracks, and none should never be the
default. The aggregation method is a configurable option,
however, so the user may wish to temporarily set it to none in
order to see subtleties hidden in overlay mode.
showSubtrackColorOnUi onSubtracks in an overlay have individual colors. Use this setting to show the color associated with each on the track configuration page.
track myMultiWig
container multiWig
aggregate transparentOverlay
showSubtrackColorOnUi on
type bigWig 0 1000
viewLimits 0:10
maxHeighPixels 100:32:8
...
track myFirstOverlaySig
table myFirstWig
parent myMultiWig
color 255,128,128
wig 0 1139
...
track myFirstBigWig
parent myMultiWig
color 120,235,204
...
This container is for a transparent overlay of
signal tracks with 2 subtracks shown. The tracks are
of type "bigWig", though the first subtrack is a wig.
Such mixtures are allowed. Notice that the wig has a slightly
larger range than the others. The signal dimensions are close
enough in this case, and the default viewLimit applied to all
subtracks suggests that any signal above 10 is interpreted as
strong. Note that each subtrack must define its color, and
in this example, that color will be seen in the track
configuration page as well as in the image. Also notice that the
first subtrack declares a table as distinct from its track name.
Usually the table (or remote file root) name is the same as the
track name. The track name is a unique key. But it is frequently
the case that a table or remote data file may be displayed as an
individual track or subtrack, as well as part of a signal overlay
track. Setting the table name here suggests that a track named
"myFirstWig" also exists and is displaying the same data used in
this overlay track.
track myMultiWig
container multiWig
aggregate transparentOverlay
showSubtrackColorOnUi on
type bigWig 0 1000
viewLimits 0:10
maxHeighPixels 100:32:8
...
track myFirstOverlaySig
parent myMultiWig
color 255,128,128
type bigWig 0 1139
...
track myFirstBigWig
parent myMultiWig
color 120,235,204
...
This container is for a transparent overlay of
signal tracks with 2 subtracks shown. The tracks are
of type "bigWig". Notice that the first subtrack has a slightly
larger range than the others. The signal dimensions are close
enough in this case, and the default viewLimit applied to all
subtracks suggests that any signal above 10 is interpreted as
strong. Note that each subtrack must define its color, and
in this example, that color will be seen in the track
configuration page as well as in the image.
Custom Tracks
NOT FOR HUBS.
Custom tracks are tracks that get loaded into the Browser through the hgCustom CGI. Unlike locally hosted tracks, or even Data Hub tracks, they do not have a trackDb.ra stanza to define their format and behavior in the Browser. Nevertheless, they will support most of the settings as a locally hosted track of the same type. There are a few additional settings that are needed to fully support custom tracks.
genomeFilled with genome/assembly db name.
offsetUsed only once, to apply an offset to bed type data of a custom track.
browserLinesInternal only – user does not set. Filled with all trackDb.ra style lines from hgCustom input.
dataUrlInternal only – user does not set. Filled if custom tracks is loaded via URL.
dbTrackTypeInternal only – user does not set.
Not sure how it is distinguished from tdbType.
fieldCountInternal only – user does not set. Filled with number of bed columns as determined in hgCustom CGI.
firstItemPosInternal only – user does not set. Filled with first bed item in bedList in hgCustom CGI.
htmlFileInternal only – user does not set. Filled with name if trash file that contains HTML description for custom track.
htmlUrlInternal only – user does not set. Filled with user entered URL for track description in hgCustom CGI.
initialPosInternal only – user does not set. Filled with position from hgCustom input.
inputTypeInternal only – user does not set. Filled with custom factory name as determined in hgCustom CGI.
itemCountInternal only – user does not set. Filled with bed item slCount in hgCustom CGI.
mafFileInternal only – user does not set. Filled with name of trash file that contains maf data as loaded in hgCustom CGI.
maxChromNameInternal only – user does not set. Obsolete: Filled with minimum index size for db that won't "smoosh" together chromNames.
origTrackLineInternal only – user does not set. Filled with "track" line as entered by user in hgCustom CGI.
tdbTypeInternal only – user does not set.
Holds the type that should go into tdb->type.
wibFileInternal only – user does not set. Filled with name of trash file that contains wib binary data as loaded in hgCustom CGI.
wigFileInternal only – user does not set. Filled with name of trash file that contains wig data as loaded in hgCustom CGI.