38fc33c4bbf6c8b960af709cb17a2467d6b6cac2
lrnassar
Tue Sep 29 15:40:59 2026 -0700
The description page variables section claimed shell and awk examples were safe from substitution, which is wrong twice over: parseVarNameMaybe accepts a bare $db as readily as ${db}, so an example using $db or $track as its own shell variable gets the value put in, and $$ still collapses to a single $. Say that instead, and document $$ as the way to write a literal dollar. The section also renders on trackDbDoc.html, which is the native trackDb doc, where "other trackDb settings are not available" is false, so it is now scoped to a hub's description page. Caught in code review of 8d05f42. refs #38283
diff --git src/hg/htdocs/goldenPath/help/trackDb/trackDbSettings.yaml src/hg/htdocs/goldenPath/help/trackDb/trackDbSettings.yaml
index 5c463de48d2..c7c98be761e 100644
--- src/hg/htdocs/goldenPath/help/trackDb/trackDbSettings.yaml
+++ src/hg/htdocs/goldenPath/help/trackDb/trackDbSettings.yaml
@@ -1,6222 +1,6230 @@
# Generated by trackDbSettingsGen.py --import, which rewrites the whole file.
# Edit the trackDb help docs instead, then run 'make settings'.
# 'roles' is a guess from which doc table a setting sits in; check the
# container-only ones.
- name: track
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings
context: trackDb
level: required
required: true
summary: This is the name of the dataset and must be unique within the Genome Browser or dataHub.
description: 'This is the name of the dataset and must be unique within the Genome Browser or dataHub.
Typically this is the MariaDB 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_- ].'
format: track
examples:
- track myFirstTrack
- name: type_for_hubs
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings
context: trackDb
level: required
required: true
summary: Declares the format of the data and is used to determine display methods and options.
description: 'Declares the format of the data and is used to determine display methods and options.
Valid settings for a hub:
bam/cram , bigBarChart , bigBed , bigChain , bigGenePred , bigInteract , bigLolly , bigMaf , bigNarrowPeak
, bigNet , bigPsl , bigWig , halSnake , hic , vcfTabix , vcfPhasedTrio .
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.'
format: type
examples:
- type bigBed 6 +
- name: shortLabel
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings
context: trackDb
level: required
required: true
summary: Specifies the track's "short label", which is used in a number of places in the Browser to
identify the track.
description: 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. Some special characters
are allowed in the shortLabel.
format: shortLabel
examples:
- shortLabel Human mRNAs
- name: longLabel
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings
context: trackDb
level: required
required: true
summary: Specifies the track's "long label", which is also used in numerous places in the Browser to
identify a track.
description: 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. Some special characters are allowed in the
longLabel.
format: longLabel
examples:
- longLabel Human mRNAs from GenBank
- name: bigDataUrl
types:
- bigBarChart
- bigBed
- bigChain
- bigInteract
- bigLolly
- bigMaf
- bigNet
- bigPsl
- bigWig
- bam
- hic
- vcfTabix
- vcfPhasedTrio
roles:
- super
- composite
- view
- leaf
category: Common Settings
context: trackDb
level: required
required: true
summary: The location of a remote data file containing the bulk of the data for the track.
description: '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.
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/cram, bigBarChart, bigBed, bigChain, bigLolly, bigInteract,
bigMaf, bigNet, bigPsl, bigGenePred, bigMethyl, bigNarrowPeak, bigWig, vcfTabix, or hic. Note that
bam/cram and vcfTabix/vcfPhasedTrio types require a separate index file that must have the same name
as the data file plus a standard suffix (".bai" and ".tbi" respectively), unless bigDataIndex is used.
All occurrences of the string $D in the URL will be substituted with the genome assembly database
name. This allows a trackDb entry to be used with for multiple assemblies. $D substitution is not
implemented for track hubs.'
format: bigDataUrl <url/relativePath>
examples:
- bigDataUrl http://vizhub.wustl.edu/VizHub/hg19/biBrainH3K4me1.bb
- bigDataUrl biBrainH3K4me1.bb
- name: html
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings
context: trackDb
level: base
required: false
summary: Use the html path/to/explain.html to specify the file that contains the complete description
of a track in HTML format.
description: 'Use the html path/to/explain.html to specify the 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,
or it can be a full URL. It is also possible to have the ".html" suffix implied, for instance just
have html explainFile . To further simplify trackDb, if there is a file, nameOfTrack.html , in the
same directory as the trackDb matching the name of the track, track nameOfTrack , then the html file
does not need to be declared. To help users understand Public Hub data, we request you provide a web
page that explains what your Track Hub is presenting. Adding an html page for your Track Hub is also
useful to instruct people on how to cite your data. To be consistent with standard Genome Browser
track descriptions, html for tracks should contain several sections as seen below. Here is a link
to an example template that you can use. Description A few sentences describing the track. Display
Conventions and Configuration If the track has colors, or unusual display properties, explain them
in this section, or how to configure special settings. Methods This section can explain data-handling
algorithms, or the significance of scores if generated in a special fashion. Credits This section
helps people find the contacts for questions about the data. Please include an email or laboratory
web page. References Relevant publications regarding the data. Example: html docs/myFirstTrack.html
- Or with full path: html https://path/to/location/docs/explainMyData.html Variables in the description
- page The description page may use the variables below, written in the form ${name} . They are replaced
- when the page is shown, both on the track settings page and on the item details page. ${db} the assembly
- the track is being viewed on, for example hg38 ${organism} the organism in lower case, for example
- human ${Organism} the organism with an initial capital, for example Human ${ORGANISM} the organism
- in upper case, for example HUMAN ${date} the release description of the assembly, for example Dec.
- 2013 (GRCh38/hg38) ${track} the name of this track ${parentTrack} the name of the container this track
- sits in, either a compositeTrack or a superTrack . A view is skipped, since a view has no description
- page of its own. For a track that is not inside a container, this is the same as ${track} . ${downloadsServer}
- hgdownload.soe.ucsc.edu ${track} and ${parentTrack} come out with the prefix the Genome Browser gives
- a hub track''s name, so they can be used to build a link back into the Browser. This is how the page
- of a track inside a container links to the container''s own page: <a href="hgTrackUi?db=${db}&g=${parentTrack}">Back
- to the container</a> Nothing else is replaced. A dollar sign followed by anything other than the names
- listed above is left alone, so shell, awk and JavaScript examples elsewhere on the page are safe.
- Other trackDb settings are not available as variables, and neither is the session id.
+ Or with full path: html https://path/to/location/docs/explainMyData.html Variables in a hub''s description
+ page A hub''s description page may use the variables below, written in the form ${name} . They are
+ replaced when the page is shown, both on the track settings page and on the item details page. ${db}
+ the assembly the track is being viewed on, for example hg38 ${organism} the organism in lower case,
+ for example human ${Organism} the organism with an initial capital, for example Human ${ORGANISM}
+ the organism in upper case, for example HUMAN ${date} the release description of the assembly, for
+ example Dec. 2013 (GRCh38/hg38) ${track} the name of this track ${parentTrack} the name of the container
+ this track sits in, either a compositeTrack or a superTrack . A view is skipped, since a view has
+ no description page of its own. For a track that is not inside a container, this is the same as ${track}
+ . ${downloadsServer} hgdownload.soe.ucsc.edu ${track} and ${parentTrack} come out with the prefix
+ the Genome Browser gives a hub track''s name, so they can be used to build a link back into the Browser.
+ This is how the page of a track inside a container links to the container''s own page: <a href="hgTrackUi?db=${db}&g=${parentTrack}">Back
+ to the container</a> These are the only names a hub''s description page can use. Other trackDb settings
+ are not available as variables, and neither is the session id. UCSC''s own description pages are substituted
+ when trackDb is loaded and follow different rules. Take care with a dollar sign that is not meant
+ as a variable. The bare form $db is recognised as well as ${db} , so a shell or awk example that happens
+ to use $db or $track as its own variable will come out with the value substituted in. Write $$ for
+ a literal dollar sign: $$db is shown as $db , and $$ on its own is shown as $ .
To help users understand Public Hub data, we request you provide a web page that explains what your
Track Hub is presenting. Adding an html page for your Track Hub is also useful to instruct people
on how to cite your data.
To be consistent with standard Genome Browser track descriptions, html for tracks should contain several
sections as seen below. Here is a link to an example template that you can use.
Description
A few sentences describing the track.
Display Conventions and Configuration
If the track has colors, or unusual display properties, explain them in this section, or how to configure
special settings.
Methods
This section can explain data-handling algorithms, or the significance of scores if generated in a
special fashion.
Credits
This section helps people find the contacts for questions about the data. Please include an email
or laboratory web page.
References
Relevant publications regarding the data.
- Variables in the description page
+ Variables in a hub''s description page
- The description page may use the variables below, written in the form ${name} . They are replaced
+ A hub''s description page may use the variables below, written in the form ${name} . They are replaced
when the page is shown, both on the track settings page and on the item details page.
${track} and ${parentTrack} come out with the prefix the Genome Browser gives a hub track''s name,
so they can be used to build a link back into the Browser. This is how the page of a track inside
a container links to the container''s own page:
<a href="hgTrackUi?db=${db}&g=${parentTrack}">Back to the container</a>
- Nothing else is replaced. A dollar sign followed by anything other than the names listed above is
- left alone, so shell, awk and JavaScript examples elsewhere on the page are safe. Other trackDb settings
- are not available as variables, and neither is the session id.'
+ These are the only names a hub''s description page can use. Other trackDb settings are not available
+ as variables, and neither is the session id. UCSC''s own description pages are substituted when trackDb
+ is loaded and follow different rules.
+
+ Take care with a dollar sign that is not meant as a variable. The bare form $db is recognised as well
+ as ${db} , so a shell or awk example that happens to use $db or $track as its own variable will come
+ out with the value substituted in. Write $$ for a literal dollar sign: $$db is shown as $db , and
+ $$ on its own is shown as $ .'
format: html
examples:
- html docs/myFirstTrack.html
- html https://path/to/location/docs/explainMyData.html
- name: visibility
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings
context: trackDb
level: required
required: false
summary: Visibility (i.e.
description: '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. Please note visibility settings in composite
subtracks are directly inherited from the parent. Therefore, any visibility lines added at the subtrack
level of a composite will be ignored. The one exception is a faceted composite , where the parent''s
visibility is a maximum rather than a value the subtracks inherit, and subtrack visibility lines are
honored up to that maximum. Be sure to experiment with this setting to verify that it works as expected
for your track type and track structure.
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.'
format: visibility
examples:
- visibility dense
- name: meta
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings
context: trackDb
level: full
required: false
summary: Meta specifies the metadata tag for this track.
description: Meta specifies the metadata tag for this track. This tag is a key into the metadata table
specified in either metaDb or metaTab in the genomes.txt file. The meta tag can be any alphanumeric
string. Each meta tag should appear in a trackDb stanza AND in either the tab-separated file specified
by metaTab, or tagStorm file specified by metaDb in the hub's genomes.txt file. Examples on how to
include metadata in your hubs can be found on the following metadata guide .
format: meta
examples: []
- name: color
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: base
required: false
summary: Many track types allow the color of the data displayed in the image to be specified with this
setting.
description: '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.
This example sets the color to red.'
format: color <red,green,blue>
examples:
- color 255,0,0
- name: priority
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: base
required: false
summary: 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.
description: '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.'
format: priority <float>
examples:
- priority 50
- name: canPack
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: deprecated
required: false
summary: Deprecated.
description: 'Deprecated. The track type usually implies whether pack and squish are offered, so this
setting is rarely needed.
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 visibility choices by turning canPack on. Note: subtracks of composites will always offer
all five choices.'
format: canPack <off/on>
examples:
- canPack on
- name: configureByPopup
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: 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...
description: '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.'
format: configureByPopup <on/off>
examples:
- configureByPopup off
- name: origAssembly
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: The original assembly version for which the dataset was generated.
description: 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.
format: origAssembly <db>
examples:
- origAssembly hg18
- name: altColor
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: Many track types allow setting a color range that varies from color to altColor .
description: '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. Tracks using altColor with the windowing function
"mean+whiskers" will see the shading of colors impacted, with lighter shades for values within a standard
deviation around the mean, most noticeable when zoomed out and average calculations are taking place.
This example sets the alternate color to blue.'
format: altColor <red,green,blue>
examples:
- altColor 0,0,255
- name: boxedCfg
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: Configuration controls can be placed inside a box on the configuration page.
description: '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.'
format: boxedCfg <on/off>
examples:
- boxedCfg on
- name: chromosomes
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: Some datasets do not contain data for all chromosomes of a genome.
description: 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.
format: chromosomes <chr1,chr2,...>
examples:
- chromosomes chr1,chr7,chr18,chr19,chr22,chrX,chrM
- name: darkerLabels
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: If this setting is "on", the color of the left labels on the track display will have a somewhat
darker color than the track display itself.
description: If this setting is "on", the color of the left labels on the track display will have a
somewhat darker color than the track display itself. This can be useful where the track color (which
may have been chosen to adhere to external conventions) is too light for readable labels.
format: darkerLabels on
examples: []
- name: dataVersion
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: Many tracks undergo multiple revisions over time.
description: 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. For native tracks, not track hubs, this setting
can also be a local absolute filename to read the version string from.
format: dataVersion <str>
examples:
- dataVersion May 2011 <em>beta</em>
- name: directUrl_for_hubs
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: By default, items shown in the Browser image can be linked to a details page giving information
about that item.
description: '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.'
format: directUrl <url>
examples:
- directUrl http://mygenes.org/cgi-bin/geneView/%s
- name: downloadUrl
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: While description HTML pages can contain download instructions, having external file download
links directly specified in trackDb makes it possible show thes...
description: 'While description HTML pages can contain download instructions, having external file download
links directly specified in trackDb makes it possible show these links outside the description HTML
pages. The URLs here are shown above the description page, right under the "data format" link. The
label can be any string and the URL should be absolute, including the server. Either one can contain
spaces, but they must be double-quoted then.
This is one of the few statements that can be specified multiple times. In this case, all statements
must have a .number suffix, e.g. .1, .2, ...'
format: downloadUrl <label> <URL>
examples:
- downloadUrl GFF https://mywebsite.com/ucscTrack.gff.gz
- downloadUrl.1 "GFF Format" https://mywebsite.com/ucscTrack.gff.gz
- downloadUrl.2 "BED Format" https://mywebsite.com/ucscTrack.bed.gz
- name: iframeUrl
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: This setting allows integrating an external html page into the default details page, as an
iframe.
description: '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 name of 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)
- $[ - left-most position of current viewing window (relative to zero)
- $] - right-most position of current viewing window (relative to one)
- ${ - start location of clicked item (relative to zero)
- $} - end location of clicked item (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
- $taxId - NCBI Taxon ID of current organism (from hgCentral.dbDb)
- $n - Scientific Name of current organism (from hgCentral.dbDb)
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'
format: iframeUrl <url>
examples:
- "iframeUrl https://www.ncbi.nlm.nih.gov/nuccore/$$\n iframeOptions height='600' width='1024'"
- name: iframeOptions
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: When iframeUrl is used, this statement specifies a string that is inserted literally into the
HTML <iframe> tag.
description: '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. Example: iframeOptions width=''800''
height=''800'' scrolling=''yes'' This example fixes the size to 800x800 pixels and activates scrollbars.
This example fixes the size to 800x800 pixels and activates scrollbars.'
format: iframeOptions <string>
examples:
- iframeOptions width='800' height='800' scrolling='yes'
- name: mouseOver
types:
- bigBed
- bigPsl
- bigChain
- bigMaf
- bigMethyl
- bigNarrowPeak
- bigGenePred
- bigLolly
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: For bigBed files with more than 8 fields (not counting any extra bigBed fields), this adds
mouse over text from a pattern based on the values of fields in th...
description: For bigBed files with more than 8 fields (not counting any extra bigBed fields), this adds
mouse over text from a pattern based on the values of fields in the file. The pattern is constructed
with fieldnames from the .as file, preceded by the dollar sign ($) and optional curly braces ({}),
and can include arbitrary text between the field names. When field names may be prefixes or overlap
with one another, as in the below example, curly braces can be used to more clearly define the field
name to be used.
format: mouseOver <pattern>
examples:
- mouseOver variant $name/$chrom:${chromStart} value $score
- name: mouseOverField
types:
- bigBed
- bigPsl
- bigChain
- bigMaf
- bigMethyl
- bigNarrowPeak
- bigGenePred
- bigLolly
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: For bigBed files with more than 8 fields (not counting any extra bigBed fields), this adds
mouse over text that are different from the "name" field of a bigB...
description: 'For bigBed files with more than 8 fields (not counting any extra bigBed 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 an extra bigBed field as explained in example 3 of the bigBed documentation . The field name
from your .as file is the field name for this statement.'
format: mouseOverField <fieldName1>
examples:
- mouseOverField comment
- name: multiRegionsBedUrl
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: null
required: false
summary: This setting causes a link to appear on the track configuration and items details pages to
launch a multi-region custom regions view , where the regions are...
description: This setting causes a link to appear on the track configuration and items details pages
to launch a multi-region custom regions view , where the regions are defined by the file supplied
as an argument to the setting. It is useful for tracks with sparse annotations in the genome. The
file must be BED format , and should contain a limited number (e.g. 2 to 10) regions of interest for
the track. It can be BED 3 format (chrom, start, end), but may have any number of additional fields.
When the link is clicked, a companion custom track is also created in order to highlight and title
the displayed regions. If the name field (field 4) is present in the BED file, the name for each region
will be displayed in the custom track. Example multiRegionsBedUrl covidMuts.regions.bed
format: multiRegionsBedUrl <url/relativePath>
examples:
- multiRegionsBedUrl covidMuts.regions.bed
- name: onlyVisibility
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: new
required: false
summary: Restricts a track to a single display mode.
description: 'Restricts a track to a single display mode. The visibility dropdowns and the right-click
menu offer only hide and the named mode, so the track either displays that way or is hidden; an unrecognized
mode is treated as dense . Use this for a track that is only meaningful in one mode - to pick a starting
mode that the user can then change, use visibility instead.
This setting is also read from the subtracks of a faceted composite , whose own visibility is a maximum
for its subtracks rather than a value they inherit. Display modes rank from least to most detailed
as hide , dense , squish , pack , full .
- A subtrack with neither setting of its own displays at whatever the parent allows, just as in a
conventional composite.
- A subtrack with its own visibility displays in that mode, or at the parent''s maximum if its own
setting is the more detailed of the two.
- A subtrack with onlyVisibility is pinned to that single mode. It displays if that mode is within
the parent''s maximum, and is not displayed at all otherwise.
Both visibility and onlyVisibility are read only from the subtrack''s own stanza and are not inherited
from the parent; an onlyVisibility line on the faceted composite itself restricts the container''s
own maximum instead. Changing the maximum does not discard the display modes set on individual subtracks,
so restoring a more detailed maximum brings them back as they were.'
format: onlyVisibility <dense|squish|pack|full>
examples:
- "track coverage\n onlyVisibility dense"
- "track methylation\n compositeTrack faceted\n visibility pack\n\n track methylation_SRX172462_levels\n\
\ parent methylation off\n visibility full\n\n track methylation_SRX172462_reads\n\
\ parent methylation off\n onlyVisibility dense"
- name: otherDb
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: Track types that show pairwise alignments often need to declare the other species/assembly
included in the alignment.
description: '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.
This example sets the second assembly in the alignment to the mouse mm10 assembly.'
format: otherDb <otherDb>
examples:
- otherDb mm10
- name: otherTwoBitUrl
types:
- chain
- bigChain
- psl
- bigPsl
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: new
required: false
summary: For pairwise alignment tracks this can specify where to find the query sequence This setting
can be used in psl, bigPsl, chain, and bigChain tracks.
description: For pairwise alignment tracks this can specify where to find the query sequence This setting
can be used in psl, bigPsl, chain, and bigChain tracks.
format: otherTwoBitUrl <url/relativePath>
examples:
- otherTwoBitUrl https://hgdownload.gi.ucsc.edu/goldenPath/hg38/bigZips/hg38.2bit
- name: pennantIcon
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: Certain tracks can be visually flagged in the Browser menu by use of an icon or text label
and a link to a description of the flags meaning.
description: 'Certain tracks can be visually flagged in the Browser menu by use of an icon or text label
and a link to a description of the flags 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. Multiple pennantIcons can be added on a single track by separating each entry with a semicolon
'';''. This setting has three parts:
- icon - Can be fully qualified URL (http, https, ftp) to an image file, or the name of an image in
the Browser''s images directory in the Browser source tree.
- text - A single word label. Case is ignored; the label is displayed capitalized lower case.
- color - An HTML color name to color the text label
- 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.'
format: "pennantIcon <iconFile>/<text color> [html [tip]] \n[; <iconFile>/<text color> [html [tip]]]"
examples:
- pennantIcon 18.jpg ../goldenPath/help/liftOver.html "lifted from hg18"
- pennantIcon New red ../goldenPath/releaseLog.html "Released October 19, 2017"
- pennantIcon 19.jpg liftOver.html "lifted hg19"; p12 black http://genome.ucsc.edu/patches/ "annotations
patch"
- name: tableBrowser
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: null
required: false
summary: The Table Browser (and REST API ) typically allow querying and downloading of some or all of
the raw data for a track.
description: 'The Table Browser (and REST API ) typically allow querying and downloading of some or
all of the raw data for a track. The off value blocks all API getData operations and Table Browser
access to datasets with restrictions (for example, those with confidentiality or licensing limitations).
The tbNoGenome value allows unrestricted API getData operations, while limiting the table browser
queries within specific genomic regions, but not genome-wide. The noGenome value prohibits API getData
operations, while allowing table browser queries within specific genomic regions, but not genome-wide.
By naming additional tables in this setting, access to those tables can be denied as well.
The table for this track, as well as the decipherRaw and knownToDecipher tables, are blocked from
Table Browser access.
Genome-wide queries are disabled for the track table as well as omimAv and omimAvRepl. Queries on
genomic regions are permitted.'
format: tableBrowser <off/on/noGenome/tbNoGenome> [table1 ...]
examples:
- tableBrowser off decipherRaw knownToDecipher
- tableBrowser noGenome omimAv omimAvRepl
- name: url_for_hubs
types:
- all
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: Many tracks allow an external link when an individual track data item is examined.
description: '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 name of 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)
- $[ - left-most position of current viewing window (relative to zero)
- $] - right-most position of current viewing window (relative to one)
- ${ - start location of clicked item (relative to zero)
- $} - end location of clicked item (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
- $taxId - NCBI Taxon ID of current organism (from hgCentral.dbDb)
- $n - Scientific Name of current organism (from hgCentral.dbDb)
- $<fieldName> - For bigBed based tracks only (so excluding vcf, vcfPhasedTrio, bam/cram and hic),
substitute the <fieldName> value from the bigBed for this item. Note the preceding ''$'' before the
brackets.
The default prompt the user will see for this url is "outside link:". Use urlLabel to provide a more
informative prompt.'
format: url <url>
examples:
- "url https://www.ncbi.nlm.nih.gov/htbin-post/Entrez/query?form=4&db=$n&term=$$&extra=$<field2>\n \
\ urlLabel NCBI Details:"
- name: urls
types:
- bigBed
- bigBarChart
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: This is similar to the url tag, but allows urls on fields that are not the "name" field.
description: '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).
The field can contain multiple values, separated by a comma "," where multiple links will then be
created on each item. For instance, a "pmid" field with an entry "11932250,34718705" would create
two links.
If an entry of comma-separated values contains a "|" symbol, the part before the pipe symbol is used
to replace the $$ wildcard and the part after it is used as the label, as opposed to the default label
description in the .as file. This pipe substitution is similar to how Wikipedia markup encodes links.
In the example below, a value for the field pmid of "11932250|W James Kent" would create a link with
the URL https://www.ncbi.nlm.nih.gov/pubmed/11932250 and the label "W James Kent".'
format: urls <fieldName1>="<url1>" <fieldName2>="<url2>" ...
examples:
- urls pmid="https://www.ncbi.nlm.nih.gov/pubmed/$$" spId="http://www.uniprot.org/uniprot/$$"
- name: skipEmptyFields
types:
- bigBed
- bigPsl
- bigGenePred
- bigMethyl
- bigNarrowPeak
- bigMaf
- bigChain
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: If this setting is "on", the item details page will not show fields that have empty values.
description: If this setting is "on", the item details page will not show fields that have empty values.
This can be useful when you have numerous extra fields but only few of them have a value.
format: skipEmptyFields on
examples: []
- name: skipFields
types:
- bigBed
- bigPsl
- bigGenePred
- bigMethyl
- bigNarrowPeak
- bigMaf
- bigChain
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: This setting can be used to suppress extra fields on the item details page.
description: This setting can be used to suppress extra fields on the item details page. It can be useful
if you do not want to show fields that are only used for mouseOvers or labels.
format: skipFields <fieldName1>,<fieldName2> ...
examples:
- skipFields mouseOver,labelField,hiddenField
- name: sepFields
types:
- bigBed
- bigPsl
- bigGenePred
- bigMethyl
- bigNarrowPeak
- bigMaf
- bigChain
roles:
- super
- composite
- view
- leaf
category: Common Settings - less frequent
context: trackDb
level: full
required: false
summary: This setting changes the item details page and splits the table used for showing extra fields
before any of the specified fields.
description: This setting changes the item details page and splits the table used for showing extra
fields before any of the specified fields. It can be useful to visually separate extra fields into
logical categories.
format: sepFields fieldName1,fieldName2 ...
examples:
- sepFields pmid,spId
- name: bam
types:
- bam
roles:
- leaf
category: bam - Compressed Alignment Track Settings
context: trackDb
level: null
required: false
summary: Declares configuration settings for a track of type bam.
description: Declares 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.
format: type bam
examples: []
- name: refUrl
types:
- bam
roles:
- leaf
category: bam - Compressed Alignment Track Settings
context: trackDb
level: full
required: false
summary: ''
description: ''
format: refUrl <url>/%s
examples: []
- name: bigDataIndex
types:
- bam
- vcfTabix
- vcfPhasedTrio
roles:
- leaf
category: bam - Compressed Alignment Track Settings
context: trackDb
level: full
required: false
summary: The location of a remote data file containing the index.
description: 'The location of a remote data file containing the index. This setting can be used when
the index cannot be placed alongside the big data file, e.g. because of restricted access permissions
or due to file name constraints. 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 index data file formats: bai (BAM index) or tbi (tabix index).
Example: bigDataIndex http://vizhub.wustl.edu/VizHub/hg19/biBrainH3K4me1.bam.bai
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 index data file formats: bai (BAM index) or tbi (tabix index).'
format: bigDataIndex <url/relativePath>
examples:
- bigDataIndex http://vizhub.wustl.edu/VizHub/hg19/biBrainH3K4me1.bam.bai
- name: bamColorMode
types:
- bam
roles:
- leaf
category: bam - Compressed Alignment Track Settings
context: trackDb
level: full
required: false
summary: There are numerous ways to color bam tracks to highlight certain aspects of the data.
description: '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 by bamGrayMode
: 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 the bamColorTag setting.
- off : No additional coloring.'
format: bamColorMode <strand/gray/tag/off>
examples: []
- name: bamGrayMode
types:
- bam
roles:
- leaf
category: bam - Compressed Alignment Track Settings
context: trackDb
level: full
required: false
summary: '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 scal...'
description: '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). Use aliQualRange to specify a default range.
- baseQual : "Base qualities" are shaded on a scale of 0 (lightest) to 40 (darkest). Use baseQualRange
to 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.'
format: bamGrayMode <aliQual/baseQual/unpaired>
examples: []
- name: bamColorTag
types:
- bam
roles:
- leaf
category: bam - Compressed Alignment Track Settings
context: trackDb
level: full
required: false
summary: You can also use RGB data associated with individual tags within the bam file itself.
description: 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.
format: bamColorTag <XX>
examples: []
- name: noColorTag
types:
- bam
roles:
- leaf
category: bam - Compressed Alignment Track Settings
context: trackDb
level: full
required: false
summary: The bam coloring options are all user-configurable within the browser.
description: '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.
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.
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.
The bam file includes RGB values in the YC field that will be used to color tags.
No special coloring will be applied to items.'
format: noColorTag .
examples:
- "bamColorMode strand\n noColorTag"
- "bamColorMode gray\n bamGrayMode aliQual\n aliQualRange 20:80"
- "bamColorMode tag\n bamColorTag YC"
- bamColorMode off
- name: bamSkipPrintQualScore
types:
- bam
roles:
- leaf
category: bam - Compressed Alignment Track Settings
context: trackDb
level: full
required: false
summary: Any bam tag can be displayed on the details page by clicking on it in the Browser image.
description: 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.
format: bamSkipPrintQualScore .
examples:
- bamSkipPrintQualScore .
- name: indelDoubleInsert
types:
- bam
- psl
- bigPsl
roles:
- leaf
category: bam - Compressed Alignment Track Settings
context: trackDb
level: full
required: false
summary: Insertion and deletion differences between tag sequences and the reference genome can be highlighted
with the use of these settings.
description: '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 (
| ).'
format: indelDoubleInsert <off/on>
examples:
- "baseColorUseSequence genbank\n indelDoubleInsert on\n indelQueryInsert on\n indelPolyA on"
- name: minAliQual
types:
- bam
roles:
- leaf
category: bam - Compressed Alignment Track Settings
context: trackDb
level: full
required: false
summary: 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...
description: '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.'
format: minAliQual <#>
examples:
- minAliQual 20
- name: pairEndsByName
types:
- bam
roles:
- leaf
category: bam - Compressed Alignment Track Settings
context: trackDb
level: full
required: false
summary: Some high-throughput sequencing technologies result in "paired end" tags, which are two individual
bam records joined by their name.
description: 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.
format: pairEndsByName .
examples: []
- name: pairSearchRange
types:
- bam
roles:
- leaf
category: bam - Compressed Alignment Track Settings
context: trackDb
level: full
required: false
summary: 'Searching to join pairs of tags by name will be limited to a maximum distance (default: 20,000
bases).'
description: '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.
The dataset includes paired end tags. The maximum search range to join tag pairs by name is capped
at 5000.'
format: pairSearchRange <#>
examples:
- "pairedEndsByName .\n pairSearchRange 5000"
- name: showNames
types:
- bam
roles:
- leaf
category: bam - Compressed Alignment Track Settings
context: trackDb
level: full
required: false
summary: 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.
description: 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.
format: showNames <on/off>
examples:
- showNames off
- name: doWiggle
types:
- bam
roles:
- leaf
category: bam - Compressed Alignment Track Settings
context: trackDb
level: full
required: false
summary: The doWiggle setting enables the BAM data to be displayed as a bar graph where the height is
proportional to the number of reads mapped to each genomic posit...
description: The doWiggle setting enables the BAM data to be displayed as a bar graph where the height
is proportional to the number of reads mapped to each genomic position. Through dynamic calculation
of items in the current window, this feature plots a line similar to a wiggle graph that can be customized
with a number of graph-based configuration options such as drawing indicator lines, smoothing plots,
adjusting graph height and vertical range, and switching from bars to points. Please note that the
feature is best displayed with "Display mode" set to full and that the default "Data view scaling"
is "auto-scale to data view."
format: doWiggle on
examples:
- doWiggle on
- name: bigBarChart
types:
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: null
required: false
summary: ''
description: ''
format: type bigBarChart
examples: []
- name: barChartBars
types:
- barChart
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: full
required: false
summary: This setting is a list of labels for the categorical variables (bars).
description: This setting is a list of labels for the categorical variables (bars). It is required for
this track type.
format: barChartBars <label1 label2...>
examples: []
- name: barChartColors
types:
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: full
required: false
summary: This setting is a list of colors, one for each category (bar).
description: 'This setting is a list of colors, one for each category (bar). Colors are specified as
RGB values (255,255,255 or #FFFFFF) or by name (the 16 HTML color names defined in HTML 4.01). The
named HTML colors are: black, silver, gray, white, maroon, red, purple, fuchsia, green, lime, olive,
yellow, navy, blue, teal, aqua.'
format: barChartColors <color1 color2...>
examples: []
- name: barChartLabel
types:
- barChart
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: full
required: false
summary: This setting provides a label for the category selection list.
description: This setting provides a label for the category selection list.
format: barChartLabel <label>
examples: []
- name: barChartMaxSize
types:
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: full
required: false
summary: BarChart track display selects one of three sizes (small, medium, or large) to display barCharts,
based on size of the genomic region in the current window.
description: BarChart track display selects one of three sizes (small, medium, or large) to display
barCharts, based on size of the genomic region in the current window. For dense data, it is helpful
to reduce the barChart sizes, even when in relatively small genomic regions. This setting limits the
size of the largest barChart to the selected value. When unset, the default value is "large".
format: barChartMaxSize <small/medium/large>
examples: []
- name: barChartSizeWindows
types:
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: full
required: false
summary: This setting provides a way to choose the basepair thresholds which determine the barChart
sizes (small, medium, or large charts).
description: 'This setting provides a way to choose the basepair thresholds which determine the barChart
sizes (small, medium, or large charts). The default basepair window size is 50000 and 500000 bases,
which is intended for one chart per gene in vertebrate genomes. This setting can be used to flexibly
customize chart sizes based on the basepair window size being visualized when densely annotating a
sequence.
In this example, used when displaying barCharts on a 30,000 basepair viral genome, large charts appear
in windows up to 499 bases, medium in windows from 500 to 7999 in size, and small when 8000 or more
bases are shown in browser window.'
format: barChartSizeWindows <largeMax> <smallMin>
examples:
- barChartSizeWindows 500 8000
- name: barChartStretchToItem
types:
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: new
required: false
summary: This setting extends the barCharts to cover the entire horizontal space available in the graph.
description: This setting extends the barCharts to cover the entire horizontal space available in the
graph. This setting is typically used with bar charts with large number of bars so that it is possible
to zoom in to see better the individual bars.
format: barChartStretchToItem on
examples: []
- name: barChartFacets
types:
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: new
required: false
summary: This setting turns on the faceted selection on the track details and configure page which is
useful for selecting which bars out of a large number to display.
description: This setting turns on the faceted selection on the track details and configure page which
is useful for selecting which bars out of a large number to display. It works with the barChartStatsUrl.
The comma-separated list of columns refer to column names in the tab-separated-value file specified
by barChartStatsUrl. See an example with images of barChartFacets on the barChart help page .
format: barChartFacets <column1,column2,...columnN>
examples: []
- name: barChartMatrixUrl
types:
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: full
required: false
summary: Specifies a data matrix file that provides data values for all samples.
description: Specifies a data matrix file that provides data values for all samples. Used together with
barChartSampleUrl to generate a box plot on the details page.
format: barChartMatrixUrl <url>
examples: []
- name: barChartStatsUrl
types:
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: new
required: false
summary: This setting associates a table in tab-separated-values with the barchart, with one line per
bar.
description: 'This setting associates a table in tab-separated-values with the barchart, with one line
per bar. The first line of the file contains the table column names. The first column contains the
name of the bar. The other columns can be in any order. If a color column is present it will be used
for the colors of the bars using the hexadecimal #RRGGBB format. (Currently the same names and colors
should also be specified in a URL associated with barChartCategoriesUrl tag.) The count column is
required, and contains the number of samples represented in the bar. Other columns can contain additional
data associated with each bar. Typically these are used in coordination with the barChartsFacets tag
to specify metadata such as cell types or tissue of origin. See an example with images of barChartStatsUrl
on the barChart help page .'
format: barChartStatsUrl <url>
examples: []
- name: singleCellColumnNames
types:
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: new
required: false
summary: This setting changes cell count to count in the track details page for the column named count
in the facets file specified by barChartStatsUrl .
description: This setting changes cell count to count in the track details page for the column named
count in the facets file specified by barChartStatsUrl . This setting is useful for non-single-cell
datasets such as bulk RNA-seq, where count represents the number of samples or replicates rather than
cells. See an example with images of barChartStatsUrl on the barChart help page .
format: singleCellColumnNames off
examples: []
- name: barChartMerge
types:
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: new
required: false
summary: This setting enables the merge button inside of the faceted selections.
description: This setting enables the merge button inside of the faceted selections. It is particularly
useful when there are many bars and many facets. It allows bars that differ only in that one facet
to be merged together. See an example with images of barChartMerge on the barChart help page .
format: barChartMerge on
examples: []
- name: barChartMetric
types:
- barChart
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: full
required: false
summary: This setting provides a label for details page information about the barChart values presented.
description: This setting provides a label for details page information about the barChart values presented.
These are typically summary values, derived from many samples (often the median value).
format: barChartMetric <metric>
examples: []
- name: barChartUnit
types:
- barChart
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: full
required: false
summary: The unit label is attached to values in the display, charts and plots of the track.
description: The unit label is attached to values in the display, charts and plots of the track.
format: barChartUnit <unit>
examples: []
- name: barChartCategoryUrl
types:
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: full
required: false
summary: Specifies a tab-separated file that provides labels and optionally colors for the categories
(bars).
description: Specifies a tab-separated file that provides labels and optionally colors for the categories
(bars). This setting can replace the barChartBars and barChartColors settings, and is particularly
useful for tracks with large numbers of categories.
format: barChartCategoryUrl <url>
examples: []
- name: barChartSampleUrl
types:
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: full
required: false
summary: Specifies a tab-separated file that provides categories for samples in the barChartMatrixUrl
file.
description: Specifies a tab-separated file that provides categories for samples in the barChartMatrixUrl
file. Used for generating a box plot on the details page.
format: barChartSampleUrl <url>
examples: []
- name: barChartBarMinPadding
types:
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: new
required: false
summary: Sets the minimum pixel width between bars to <num> pixels.
description: Sets the minimum pixel width between bars to <num> pixels. Typically, this padding is a
dynamic calculation dependent on the current window size, the width of the item, and the number of
bars for the item. If present, the maximum of this setting and the dynamically calculated padding
is used for the display. See an example with images of barChartBarMinPadding on the barChart help
page .
format: barChartBarMinPadding <num>
examples: []
- name: barChartBarMinWidth
types:
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: new
required: false
summary: Sets the minimum pixel width of the bars in the chart to <num> pixels.
description: Sets the minimum pixel width of the bars in the chart to <num> pixels. Typically, this
width is a dynamic calculation dependent on the current window size, the width of the item, and the
number of bars for the item. If present, the maximum of this setting and the dynamically calculated
width is used for the display. See an example with images of barChartBarMinWidth on the barChart help
page .
format: barChartBarMinWidth <num>
examples: []
- name: maxLimit
types:
- bedGraph
- bigBarChart
roles:
- leaf
category: bigBarChart
context: trackDb
level: full
required: false
summary: The upper limit of the data range in a track is specified with this setting.
description: The upper limit of the data range in a track is specified with this setting.
format: maxLimit <#>
examples:
- maxLimit 5000
- name: bigBed
types:
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: null
required: false
summary: Type bigBed declares the number of standard "bed" fields in the data.
description: 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.
format: type bigBed <3-12> [+/.]
examples:
- type bigBed 9 +
- name: itemRgb
types:
- bed
- bigBed
- bedDetail
- bedGraph
- bedLogR
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: base
required: false
summary: In 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 .
description: 'In 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. To observe this field, specify the type as, type bigBed 9 , or, type
bigBed 9+ , for additional non-standard columns , in the trackDb stanza for the bigBed file.
Note that the display of color is affected by the maxItems option. When the track is zoomed to the
point that the number of items to display exceeds maxItems , the track is forced into dense mode and
the items are drawn from the bigBed summary in the default track color rather than using the itemRgb
column .
Whether the items are drawn from the itemRgb column also depends on the color setting. Both settings
are inherited from a track''s parent , and an explicit itemRgb wins wherever it is set:
- itemRgb on : items take the colors in the file. A color setting still colors the track label, but
it does not override the items.
- itemRgb off : items take the color setting, or black if there is none.
- color with no itemRgb : items take the color setting.
- Neither setting: items take the colors in the file. This is the default on genome.ucsc.edu.'
format: itemRgb on
examples:
- itemRgb on
- name: colorFields
types:
- bigBed
- bigGenePred
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: new
required: false
summary: 'Enables a Color by: dropdown in the track controls that lets the user switch among multiple
pre-computed color schemes without leaving the track display.'
description: 'Enables a Color by: dropdown in the track controls that lets the user switch among multiple
pre-computed color schemes without leaving the track display.
Each entry is a fieldName="Human Label" pair. The field name must be an extra bigBed field (defined
in the track''s .as file) that contains a pre-computed R,G,B color string, the same format as the
standard itemRgb field. The label in double quotes is shown in the dropdown; if omitted, a label is
derived automatically by stripping a leading colorBy prefix and replacing underscores with spaces.
The special name default (with an optional label) represents the track''s existing itemRgb field (column
9) and is placed first in the dropdown. When no default= entry is given, an unlabeled "Default" option
is added automatically.
Item coloring must be active for colorFields to work. It is active by default on bigBed tracks with
more than 9 fields. It is suppressed by itemRgb off , or by a color setting when neither the track
nor its parent says itemRgb on . The currently selected scheme is stored in the cart variable <trackName>.colorField
. When a non-default scheme is active, the track long label gains a (Coloring by: <label>) suffix.
This creates a three-option dropdown. colorByEvidence and colorByHlaClass must be extra fields in
the bigBed whose values are R,G,B strings.'
format: colorFields default="<label>" <fieldName1>="<label1>" <fieldName2>="<label2>" ...
examples:
- colorFields default="Kozak strength" colorByEvidence="Evidence type" colorByHlaClass="HLA class"
- name: colorByStrand
types:
- bed
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: base
required: false
summary: To color items differently by the strand they align to, use the colorByStrand setting.
description: '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 .
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 .'
format: colorByStrand <red,green,blue> <red,green,blue>
examples:
- colorByStrand 255,0,0 0,0,255
- name: denseClick
types:
- bed
- bigBed
- genePred
- bigGenePred
- psl
- bigPsl
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: new
required: false
summary: In dense mode the whole track row is normally one link that switches the track to pack, so
a click cannot reach an item.
description: 'In dense mode the whole track row is normally one link that switches the track to pack,
so a click cannot reach an item. With denseClick on each item on the dense row gets its own link to
its details page, and its own mouseover. A click on a part of the row that holds no item still switches
the track to pack, as does a click on the center label or the visibility menu you get by right-clicking
the row.
Items are still drawn the way dense always draws them, all on one row, so the track keeps its height.
This is the difference from squish , which also gives every item a link but puts overlapping items
on separate rows.
Where several items fall under the same pixel only the first one can be clicked, and at most one link
is made per pixel of the row. A track drawn from summary data rather than from items, which is what
a bigBed does when zoomed out far enough, has nothing to link and is unaffected.
The setting is inherited, so putting it on a composite turns it on for every subtrack.'
format: denseClick <on/off>
examples:
- denseClick on
- name: denseCoverage
types:
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: bigBed specific Type bigBed tracks in dense mode do a density plot based on maximum coverage
seen at each pixel.
description: '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.'
format: denseCoverage <maxVal>
examples:
- denseCoverage 100
- name: labelOnFeature
types:
- bed
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: Usually, labels (the BED name field) are drawn next to the features.
description: Usually, labels (the BED name field) are drawn next to the features. This statement tries
to draw the feature label over the exon blocks. The effect depends on the size of the feature on the
screen, which in turn depends on the zoom level. If there is not enough space for 4 characters, no
label is drawn at all. If there is more space, the label is drawn with a contrasting color onto the
exon-like blocks. If they are too short for the text, it is trimmed to fit into the available space
and the suffix "..." appended. Note that features should not have too long thin (UTR) regions, as
the text might be hard to read in these parts. To keep the text readable, the arrows that indicate
the strand are shown over introns, but suppressed on blocks, so the statement should be used for tracks
where strand is not of primary importance, not defined in the BED strand field or deactivated with
exonArrows .
format: labelOnFeature <on/off>
examples:
- labelOnFeature on
- name: extraDetailsTable
types:
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: deprecated
required: false
summary: This setting was renamed June 2022.
description: 'This setting was renamed June 2022. Please use detailsStaticTable instead.
Provides a template to a tab separated text file where $<fieldName> strings will be substituted for
data in the bigBed and displayed as an HTML table. For an example of this, please see the following
text file: http://hgdownload.gi.ucsc.edu/gbdb/hg38/gnomAD/v3.1/variants/v3.1.genomes.popTable.txt
, where the strings such as "${AC_afr}" will be substituted for the data in that field for the particular
item from the bigBed.
Note that the same size table is displayed for every item of the bigBed, even if there is missing
data in that field for a particular item. For variable size tables, please see detailsDynamicTable
.'
format: extraDetailsTable <url/relativePath>
examples: []
- name: extraTableFields
types:
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: deprecated
required: false
summary: This setting was renamed June 2022.
description: 'This setting was renamed June 2022. Please use detailsDynamicTable instead.
Tells the system that the data in <fieldName1,...> contains an encoded table that should be turned
into a standard HTML table on the details page for that item. If the <fieldName> starts with "_json"
or "json", then the system expects the data in <fieldName> to be valid JSON. If the field name starts
with anything else, then the table is formatted using "|" and ";" as field and new row separators.
The "table title" part of the statment is optional, if present it will be used as the title for the
table, if not, then the title will be taken from the autoSql description of the field name, or if
there is no autoSql because the data is from an external file, then the field name will be used. An
example of both formats is shown below, along with the corresponding trackDb statements: trackDb line:
extraTableFields _jsonField1|JSON Title Example,tableField2|NON-JSON Title Example the two columns
from the bigBed (or external file): _jsonField1 tableField2 {key:val, key1: val1, key2: val2} key|val;key1|val1;key2|val2
And when clicking on an item in the browser, the following would be displayed: JSON Title Example
key val key1 val1 key2 val2 NON-JSON Title Example key val key1 val1 key2 val2 Note that the number
of columns and rows is variable per item, meaning some items can have different sized tables than
other items, contrasting with the extraDetailsTable statement, which enforces the same table size
per item. For instance, in the above example, a 3 rows by 2 columns table is created for each field,
but if our JSON was instead: {"transcript1": {annot1: val1, annot2: val2}, "transcript2": {annot3:
val3}} then the following nested table would be shown on the details page: JSON Title Example transcript1
annot1 val1 annot2 val2 transcript2 annot3 val3
An example of both formats is shown below, along with the corresponding trackDb statements: trackDb
line: extraTableFields _jsonField1|JSON Title Example,tableField2|NON-JSON Title Example the two columns
from the bigBed (or external file): _jsonField1 tableField2 {key:val, key1: val1, key2: val2} key|val;key1|val1;key2|val2
And when clicking on an item in the browser, the following would be displayed: JSON Title Example
key val key1 val1 key2 val2 NON-JSON Title Example key val key1 val1 key2 val2 Note that the number
of columns and rows is variable per item, meaning some items can have different sized tables than
other items, contrasting with the extraDetailsTable statement, which enforces the same table size
per item. For instance, in the above example, a 3 rows by 2 columns table is created for each field,
but if our JSON was instead: {"transcript1": {annot1: val1, annot2: val2}, "transcript2": {annot3:
val3}} then the following nested table would be shown on the details page: JSON Title Example transcript1
annot1 val1 annot2 val2 transcript2 annot3 val3'
format: extraTableFields <fieldName1|table title,fieldName2|table title,...>
examples:
- extraTableFields _jsonField1|JSON Title Example,tableField2|NON-JSON Title Example
- "_jsonField1\ttableField2\n{key:val, key1: val1, key2: val2}\tkey|val;key1|val1;key2|val2"
- '{"transcript1": {annot1: val1, annot2: val2}, "transcript2": {annot3: val3}}'
- name: detailsStaticTable
types:
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: new
required: false
summary: Provides a template to a tab separated text file where $<fieldName> strings will be substituted
for data in the bigBed and displayed as an HTML table.
description: 'Provides a template to a tab separated text file where $<fieldName> strings will be substituted
for data in the bigBed and displayed as an HTML table. For an example of this, please see the following
text file: http://hgdownload.gi.ucsc.edu/gbdb/hg38/gnomAD/v3.1/variants/v3.1.genomes.popTable.txt
, where the strings such as "${AC_afr}" will be substituted for the data in that field for the particular
item from the bigBed.
Note that the same size table is displayed for every item of the bigBed, even if there is missing
data in that field for a particular item. For variable size tables, please see detailsDynamicTable
.'
format: detailsStaticTable <url/relativePath>
examples: []
- name: detailsDynamicTable
types:
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: new
required: false
summary: Tells the system that the data in <fieldName1,...> contains an encoded table that should be
turned into a standard HTML table on the details page for that item.
description: 'Tells the system that the data in <fieldName1,...> contains an encoded table that should
be turned into a standard HTML table on the details page for that item. If the <fieldName> starts
with "_json" or "json", then the system expects the data in <fieldName> to be valid JSON. If the field
name starts with anything else, then the table is formatted using "|" and ";" as field and new row
separators. The "table title" part of the statment is optional, if present it will be used as the
title for the table, if not, then the title will be taken from the autoSql description of the field
name, or if there is no autoSql because the data is from an external file, then the field name will
be used. An example of both formats is shown below, along with the corresponding trackDb statements:
trackDb line: detailsDynamicTable _jsonField1|JSON Title Example,tableField2|NON-JSON Title Example
the two columns from the bigBed (or external file): _jsonField1 tableField2 {key:val, key1: val1,
key2: val2} key|val;key1|val1;key2|val2 And when clicking on an item in the browser, the following
would be displayed: JSON Title Example key val key1 val1 key2 val2 NON-JSON Title Example key val
key1 val1 key2 val2 Note that the number of columns and rows is variable per item, meaning some items
can have different sized tables than other items, contrasting with the extraDetailsTable statement,
which enforces the same table size per item. For instance, in the above example, a 3 rows by 2 columns
table is created for each field, but if our JSON was instead: {"transcript1": {annot1: val1, annot2:
val2}, "transcript2": {annot3: val3}} then the following nested table would be shown on the details
page: JSON Title Example transcript1 annot1 val1 annot2 val2 transcript2 annot3 val3
An example of both formats is shown below, along with the corresponding trackDb statements: trackDb
line: detailsDynamicTable _jsonField1|JSON Title Example,tableField2|NON-JSON Title Example the two
columns from the bigBed (or external file): _jsonField1 tableField2 {key:val, key1: val1, key2: val2}
key|val;key1|val1;key2|val2 And when clicking on an item in the browser, the following would be displayed:
JSON Title Example key val key1 val1 key2 val2 NON-JSON Title Example key val key1 val1 key2 val2
Note that the number of columns and rows is variable per item, meaning some items can have different
sized tables than other items, contrasting with the extraDetailsTable statement, which enforces the
same table size per item. For instance, in the above example, a 3 rows by 2 columns table is created
for each field, but if our JSON was instead: {"transcript1": {annot1: val1, annot2: val2}, "transcript2":
{annot3: val3}} then the following nested table would be shown on the details page: JSON Title Example
transcript1 annot1 val1 annot2 val2 transcript2 annot3 val3'
format: detailsDynamicTable <fieldName1|table title,fieldName2|table title,...>
examples:
- detailsDynamicTable _jsonField1|JSON Title Example,tableField2|NON-JSON Title Example
- "_jsonField1\ttableField2\n{key:val, key1: val1, key2: val2}\tkey|val;key1|val1;key2|val2"
- '{"transcript1": {annot1: val1, annot2: val2}, "transcript2": {annot3: val3}}'
- name: detailsScript
types:
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: new
required: false
summary: Adds a custom JavaScript visualization to the item details page for a bigBed track.
description: 'Adds a custom JavaScript visualization to the item details page for a bigBed track. The
visualization is rendered by an ES6 module loaded on demand when the details page is viewed.
The setting name has three dot-separated parts:
- <plotType> - determines which JavaScript module to load ( hgc.<plotType>.js ) and which exported
function to call.
- <fieldName> - a bigBed extra field (defined in the autoSql schema) whose value is passed to the
JavaScript function. The raw value is suppressed from the HTML table and replaced by the visualization.
The <jsonConfig> value is a JSON object with configuration for the visualization, such as titles and
axis labels. Its keys are merged into the data object passed to the JavaScript function.
Multiple fields can be visualized by using multiple detailsScript settings with different field names.
Fields sharing the same <plotType> are grouped together and passed to a single JavaScript function
call.
Two keys in <jsonConfig> are understood by the browser itself, for every plot type:
- exportFields - a JSON list of other bigBed field names. Their values are passed to the JavaScript
function as well, in a fieldValues object keyed by field name. This lets one setting drive a visualization
that needs several fields, without the values having to be packed into a single field. Names that
are not fields of this bigBed are ignored, and at most 32 are exported. Unlike the field the setting
names, a field listed here still shows its own row in the details table.
- any key whose name ends in Url - treated as a file, in the same way as the bigDataUrl setting. A
relative path is resolved against the track''s own bigDataUrl , so it can be written relative to the
data file rather than as a full URL, and this works whether the hub is loaded over http(s) or from
a local path. The file is read by the server, not fetched by the browser, so the host serving it needs
no Access-Control-Allow-Origin header. It does have to sit inside the directory tree of a hub attached
to the session: the browser requests it through hgTrackUi , which canonicalizes the path and refuses
anything outside a connected hub, so a file elsewhere on the web or on the server cannot be read this
way.
Two plot types are available.
histogram draws an SVG bar chart from data encoded as space-separated key=value pairs (logfmt format).
It accepts the JSON config keys title (chart heading) and xLabel (x-axis label).
In this example, the bigBed fields afrHist and eurHist contain logfmt-encoded histograms such as 15=0.025
22=0.016 23=0.747 24=0.211 . On the details page, each field''s table row is replaced by an SVG bar
chart drawn by the hgc.histogram.js module.
scatterPlot draws a cloud of background points and highlights the position of the clicked item within
it, which suits a track whose items carry coordinates in some precomputed space. It accepts these
JSON config keys:
- dataUrl - the file of background points (required). It must live inside the hub, as described above.
- xLabel , yLabel - axis labels.
- title - replaces the field description in the left-hand column.
- exportFields - the fields holding the coordinates to highlight, as described above. Each is drawn
as a large dot in its own color, in the order listed, and labelled in the legend below the plot. A
track with only one point to highlight can leave this out and put the coordinate in the field the
setting names.
Each coordinate field holds one point, written either as (x,y) or as logfmt x=<num> y=<num> ; in the
logfmt form the keys may carry a suffix, so x1=0.43 y1=-1.41 is also read.
The dataUrl file holds the background points, as JSON:
or, when the URL ends in .tsv or .txt , as a tab-separated file with a header line naming an x and
a y column, plus optional l and c columns:
Points carrying a category ( c , or an index into labels ) are colored by it and listed in a legend;
without one the cloud is drawn in grey. Points carrying a label ( l ) show it on mouseover. The form
with a separate labels list keeps the file small when long category names repeat across thousands
of points. The cloud is drawn on a canvas, so a file of tens of thousands of points still renders
quickly.
Here the bigBed fields pca and pcaSegment each hold a point such as (0.433,-1.407) . On the details
page the pca row is replaced by a scatterplot of the reference points in pclaiRefPanel.json , with
both of the item''s own coordinates marked on it.'
format: detailsScript.<plotType>.<fieldName> <jsonConfig>
examples:
- 'detailsScript.histogram.afrHist {"title":"AFR Allele Frequencies","xLabel":"Allele size (repeat copies)"}
detailsScript.histogram.eurHist {"title":"EUR Allele Frequencies","xLabel":"Allele size (repeat copies)"}'
- '[[x,y], ...]
{"points": [[x,y], ...]}
{"points": [{"x":x, "y":y, "l":"mouseover label", "c":"category"}, ...]}
{"labels": ["category A","category B"], "points": [[x,y,categoryIndex,"mouseover label"], ...]}'
- "x\ty\tl\tc\n0.467\t-1.368\tHG00096_H1\tBritish from England and Scotland"
- detailsScript.scatterPlot.pca {"dataUrl":"../pclaiRefPanel.json","exportFields":["pca","pcaSegment"],"title":"Position
in ancestry space","xLabel":"PC1","yLabel":"PC2"}
- name: exonArrows
types:
- bed
- bigBed
- genePred
- bigGenePred
- psl
- bigPsl
- chain
- bigChain
- narrowPeak
- bigNarrowPeak
- broadPeak
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: 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.
description: 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.
format: exonArrows <on/off>
examples:
- exonArrows off
- name: exonNumbers
types:
- genePred
- bigGenePred
- bed
- bigBed
- psl
- bigPsl
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: A mouseover that shows the exon and intron numbers can be explicitly shown or hidden using
this setting.
description: 'A mouseover that shows the exon and intron numbers can be explicitly shown or hidden using
this setting. The default is "on" for the track types genePred and bigGenePred.
The text can be set with the options "exonText" and "intronText". It defaults to "exon" and "intron",
respectively.'
format: exonNumbers <on/off>
examples:
- exonNumbers off
- name: scoreFilter
types:
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: Type bigBed tracks can be filtered on the standard bed field score .
description: '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.
Since the introduction of scoreFilter more powerful filter.<fieldName> options exist where the score
column can be filtered with different syntax. In such a way scoreFilter 400 and scoreFilterLimits
0:1000 can be replaced with filter.score 400 and filterByRange.score 0:1000 . The advantage of switching
to the filter.<fieldName> approach is that filters can also be added on additional bigBed <fieldNames>
such as filterText.disease or filterValues.cellType where bigBeds defined with a disease or cellType
column can be filtered. See filter.<fieldName> for more information and examples.
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..'
format: scoreFilter <low>[:<high>]
examples:
- "scoreFilter 300\n scoreFilterLimits 200:1000"
- name: maxItems
types:
- bed
- bigBed
- broadPeak
- psl
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: Maximum number of items to display individually in full or pack or squish mode.
description: 'Maximum number of items to display individually in full or pack or squish mode. When the
maximum is exceeded, the track switches to coverage mode. Default: 1000. For type bigBed tracks, this
setting can never be larger than the hg.conf setting bigBedMaxItems, which by default is 100,000 at
UCSC.
bigBedMaxItems is configured globally for a Genome Browser server and sets an upper limit on how many
features can be loaded at most from a bigBed file, to avoid a single track making a Genome Browser
view unusable at high zoom levels so it the upper limit for all maxItems settings of any tracks shown
on a Genome Browser. If you have feedback on these values, please do not hesitate to contact us.'
format: maxItems <integer>
examples:
- maxItems 25
- name: maxWindowCoverage
types:
- bed
- bigBed
- genePred
- bigGenePred
- psl
- bigPsl
- chain
- bigChain
- narrowPeak
- bigNarrowPeak
- broadPeak
- bam
- rmsk
- bedLogR
- vcf
- vcfTabix
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: When too many individual bed items might be shown in the Browser image (such as might occur
when a large region of a chromosome is viewed), maxWindowCoverage...
description: 'When too many individual bed items might be shown in the Browser image (such as might
occur when a large region of a chromosome is viewed), maxWindowCoverage will switch the track into
density coverage plot when the window contains more than the specified number of bases.
Browser images that show more than 10,000,000 bases will result in the track data being displayed
as a density coverage graph.'
format: maxWindowCoverage <integer>
examples:
- maxWindowCoverage 10000000
- name: maxWindowToDraw
types:
- all
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: When too many individual bed items might be shown in the Browser image (such as might occur
when a large region of a chromosome is viewed), maxWindowToDraw w...
description: 'When too many individual bed items might be shown in the Browser image (such as might
occur when a large region of a chromosome is viewed), maxWindowToDraw will trigger a choice to display
a message asking users to zoom in to a smaller region.
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 in some cases. The maxWindowToDraw
setting allows you to force users to zoom in as an overriding message will block out the data display.
Unlike the maxItems setting, which controls the display of vertical space and forces a display to
dense when the maximum number of items is exceeded, the maxWindowToDraw setting dictates the number
of bases to be displayed in a window before the track is obscured with a message explaining the requirement
for zooming-in. Even without this setting, there are browser operations that will ultimately prevent
too many items from being displayed by forcing a visualized summary in dense mode as noted.
Browser images that show more than 10,000,000 bases will result in the track data being obscured with
a note across the genomic range stating the message zoom in to <= 10,000,000 bases to view items .'
format: maxWindowToDraw <integer>
examples:
- maxWindowToDraw 10000000
- name: minGrayLevel
types:
- bed
- bigBed
- broadPeak
- narrowPeak
- bigNarrowPeak
- bedLogR
- bigInteract
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: 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 specif...
description: '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.
This sets the lowest scores to slightly less than medium gray, while the highest scores appear black.'
format: minGrayLevel <1-9>
examples:
- minGrayLevel 4
- name: noScoreFilter
types:
- bed
- bigBed
- bedGraph
- bedLogR
- gvf
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: By default, bed tracks with 5 or more standard bed fields that contain either a ' .
description: By 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.
format: noScoreFilter on
examples:
- "type bigBed 6 +\n noScoreFilter on"
- name: spectrum
types:
- bed
- bigBed
- bigGenePred
- psl
- bigPsl
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: base
required: false
summary: Replaces useScore .
description: '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:
- minGrayLevel can be used to set the level of the lightest shade
- scoreMin and scoreMax can be used to define the lower and upper limits of the range that will receive
graded shading
Note: The file type must be type bigBed x where x is at least bigBed 5. If only type bigBed is used,
the setting will not work as it is assumed to be a bigBed 3.
In this example, the track description will be displayed in blue, but the track will remain a gray
scale. Items with scores less than or equal to 700 will be shown in very light gray, those with scores
between 700 and 900 will display in increasingly darker shades of gray, and items with scores greater
than or equal to 900 above will display in black.'
format: spectrum on
examples:
- "spectrum on\n scoreMin 700\n scoreMax 900"
- name: style
types:
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: new
required: false
summary: BigBed tracks can be created with a variety of extra fields.
description: BigBed tracks can be created with a variety of extra fields. When created according to
the heatmap schema , the extra fields include data to support a positional heatmap display. This setting
causes the browser to use those data for a heatmap display mode instead of the standard bigBed display.
format: style <heatmap>
examples:
- style heatmap
- name: thickDrawItem
types:
- bed
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: 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 fro...
description: 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.
format: thickDrawItem <off/on>
examples:
- thickDrawItem on
- name: decorator
types:
- bed
- bigBed
- genePred
- bigGenePred
- psl
- bigPsl
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: new
required: false
summary: Decorators allow annotation to be placed on top of BED 12+, bigBed, PSL, and bigGenePred tracks
by highlighting regions and adding glyphs on top of them.
description: 'Decorators allow annotation to be placed on top of BED 12+, bigBed, PSL, and bigGenePred
tracks by highlighting regions and adding glyphs on top of them. The decorators themselves can be
configured with a small selection of trackDb settings as follows. For a more interactive introduction
to decorators, see the Track Decorators help page.
NB: In all of the following settings, decorator.default. is used as a prefix to indicate that the
settings should be applied to the decorator and not the primary track. This is necessary because many
settings that you can apply to decorators are identical to settings that can be applied to tracks.
For example, filterValues can be applied to a main track to filter which items are displayed, but
can also be applied to a decorator for that track as decorator.default.filterValues to filter which
decorations are drawn. In the future, other names besides "default" may be allowed to permit multiple
decorators annotating a single track.
Settings
decorator.default.bigDataUrl <url>
This setting is required when adding a decorator to a track. It specifies the path to a bigBed file
that contains the decorations.
decorator.default.filterValues <specification>
Decorators support the same filter options that bigBed tracks do. This includes the filter , filterText
, and filterValues settings, as described in the Track Hub Filters Quick Start Guide .
decorator.default.mouseOver <specification>
Decorators also support the same mouseOver and mouseOverField settings that can be applied to bigBed
tracks.
There is one more setting that is currently specific to decorators.
decorator.default.maxLabelBases <integer>
This setting controls a failsafe option for deactivating the drawing of decoration labels when they''re
in block mode. There will also be a checkbox on the track configuration page to deactivate labels
manually, but even when that is on, a track display can quickly become unintelligible if the window
displayed is too large - there will simply be too many track items and too many decoration labels
to process visually. maxLabelBases sets a maximum window size (in bases) for which labels will be
drawn. If not set, the value will default to 200kb.'
format: decorator.default.*
examples: []
- name: searchIndex
types:
- bigBed
- bigPsl
- bigGenePred
- bigBarChart
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: Specifies the list of field names on which a index has been made.
description: '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. The searchIndex setting
requires the input BED data to be case-senstive sorted ( sort -k1,1 -k2,2n ), where newer versions
of the tool bedToBigBed (available here ) are enhanced to catch improper input. Example: searchIndex
name'
format: searchIndex <str>
examples:
- searchIndex name
- name: searchTrix
types:
- bigBed
- bigGenePred
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: 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.
description: '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
and a Searchable Track Hub Quick Start Guide here. Example: searchTrix url or relative path'
format: searchTrix <url/relativePath>
examples:
- searchTrix url or relative path
- name: labelFields
types:
- bigBarChart
- bigBed
- bigGenePred
- bigNarrowPeak
- bigPsl
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: A list of fields from the bigBed based file that can be used as a label.
description: A list of fields from the bigBed based file that can be used as a label. The special value
none can be specified if no labels are desired.
format: labelFields < fieldName[,fieldName] >
examples: []
- name: defaultLabelFields
types:
- bigBarChart
- bigBed
- bigGenePred
- bigNarrowPeak
- bigPsl
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: A list of fields from the bigBed based file that should be used as a label by default.
description: A list of fields from the bigBed based file that should be used as a label by default.
Only applicable if labelFields is set. If defaultLabelFields is not specified, the first field in
labelFields is used as the default. The special value none can be specified if no label should be
the default.
format: defaultLabelFields < fieldName[,fieldName] >
examples: []
- name: labelSeparator
types:
- bigBed
- bigGenePred
- bigNarrowPeak
- bigPsl
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: One or more characters to use as the field separator between multiple labels.
description: One or more characters to use as the field separator between multiple labels. A slash (/)
by default, this string can have double quotes around it if it should have white spaces in it.
format: labelSeparator < text >
examples: []
- name: filter
types:
- bed
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: There are a number of different filters available for bigBed data.
description: 'There are a number of different filters available for bigBed data. See the Filters Quick
Start guide for more info. Note: for configurable features, like filters, an additional period "."
or plus "+" is required in the type declaration, for instance type bigBed 5 . or type bigBed 9 + .
filter.<fieldName> is used for numerical data. It requires a default value to be passed. A value of
0 (or the lowest value present in the dataset) can be used to enable numerical filtering, but filter
nothing by default.
By default, the range of values for filter.<fieldName> is 0 to 1000. However, you can explicitly set
the upper and lower limits of the filter with filterLimits.<fieldName> .
The numeric filters will exclude items that fall below the setting. That is, a filter.<fieldName>
of 800 will exclude all items with a score below 800. You can also filter values within a range by
including the filterByRange.<fieldName> setting. For example, filter.<fieldName> 800:900 will include
only items with scores at or above 800 and below 900. It is recommended that filterByRange.<fieldName>
be used in combination with filterLimits.<fieldName> to set limit boundaries.
The filter label will be the description of the field as specified by the autoSql (.as) file. This
label can be customized with the filterLabel.<fieldName> parameter. See the bigBed help page and example
3 for more information about creating unique .as files for bigBed data.
Notes: filter.<fieldName> can be used multiple times with different columns Both integers and decimals
(floats) are supported Any column/field values that start with non-numerical characters will be treated
as zeros Column/fieldName values that start with a number followed by non-numerical characters will
be treated as only the number; the non-numerical characters (and any numbers that follow them) will
be ignored (see example below) If a column/fieldName contains negative values, be sure to specify
a default value at or below the lowest negative value in order to avoid actively filtering items by
default (unless that is the intended behavior) In order for filters to work, the track must be " type
bigBed N + " or " type bigBed N . ". Including the "+" (for bigBed+ tracks) or a "." (for non-extended
bigBed tracks) is required Filters are not supported in bed3 or bed4 files, even bed 3+x. The file
must be at least a bed5 By default, all bed tracks that are at least bed5 will have a score filter.
Enabling any of the filter*.<fieldName> filter settings will disable that default filter
- filter.<fieldName> can be used multiple times with different columns
- Both integers and decimals (floats) are supported
- Any column/field values that start with non-numerical characters will be treated as zeros
- Column/fieldName values that start with a number followed by non-numerical characters will be treated
as only the number; the non-numerical characters (and any numbers that follow them) will be ignored
(see example below)
- If a column/fieldName contains negative values, be sure to specify a default value at or below the
lowest negative value in order to avoid actively filtering items by default (unless that is the intended
behavior)
- In order for filters to work, the track must be " type bigBed N + " or " type bigBed N . ". Including
the "+" (for bigBed+ tracks) or a "." (for non-extended bigBed tracks) is required Filters are not
supported in bed3 or bed4 files, even bed 3+x. The file must be at least a bed5 By default, all bed
tracks that are at least bed5 will have a score filter. Enabling any of the filter*.<fieldName> filter
settings will disable that default filter
- Filters are not supported in bed3 or bed4 files, even bed 3+x. The file must be at least a bed5
- By default, all bed tracks that are at least bed5 will have a score filter. Enabling any of the
filter*.<fieldName> filter settings will disable that default filter
In this example, filtering is being enabled for the field score . We are passing a default value of
0, which is usually a safe default value to pass as most score values contain only positive numbers.
Note, however, that any negative values would be filtered out by default in this example.
In this second example, we are enabling filtering on the same field score , however, we are passing
the integer 300. This means that when the data is loaded, items with scores below 300 will be excluded
by default. This value can then be modified in the track description page.
In this example, we are enabling numerical filtering on the field signal . filterByRange.<fieldName>
is also being enabled, allowing for filtering between interval values, this also allows us to pass
a range of values to the filter.<fieldName> parameter. In this case, by default only values between
300 and 400 are being displayed. Lastly, the filter limits are being modified to accept values between
200 and 500 as opposed to the default 0 to 1000.
This example applies filter.<fieldName> to values in the field named confidenceScore containing some
non-numerical values. If items with the four values above were filtered with a minimum value of 6:
5 - item would be removed as it is less than the filter value 6 (Uncertain) - item should show up,
as it would be interpreted as "6" Unknown - item would be removed as it would be interpreted as 0
7.0 - item would appear as decimals are supported
5 - item would be removed as it is less than the filter value 6 (Uncertain) - item should show up,
as it would be interpreted as "6" Unknown - item would be removed as it would be interpreted as 0
7.0 - item would appear as decimals are supported'
format: filter.<fieldName> <default integer>
examples:
- filter.score 0
- filter.score 300
- "filter.signal 300:400\n filterByRange.signal on\n filterLimits.signal 200:500"
- filter.confidenceScore 6
- "5\n 6 (Uncertain)\n Unknown\n 7.0"
- name: filterText
types:
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: There are a number of different filters available for bigBed data.
description: 'There are a number of different filters available for bigBed data. See the Filters Quick
Start guide for more info. Note: for configurable features, like filters, an additional period "."
or plus "+" is required in the type declaration, for instance type bigBed 5 . or type bigBed 9 + .
filterText.<fieldName> is used to enable text searching in the specified fieldName. It requires a
default search string to be passed. An asterisk/wildcard (*) can be used to enable text searching,
but pass no default value. If a word or string is passed, items matching the string will be filtered
by default. See examples below for details.
filterText.<fieldName> will enable two kinds of searching, wildcard and regexp. By default, the wildcard
option is enabled. This means that a search term with a wildcard (*) item on either end will match
any number of additional characters before and/or after the search term. The regexp option allows
for searching with regular expression rules . For instance, with wildcard changed to a regexp type
of search, putting in .*A\|B.* will match any items with an A or B in it, while .*[0-9] will match
any item ending in a number. The optional settings filterType.<fieldName> may be added to switch the
default from wildcard to regexp.
The filter label will be the description of the field as specified by the autoSql (.as) file. This
label can be customized with the filterLabel.<fieldName> parameter. See the bigBed help page and example
3 for more information about creating unique .as files for bigBed data.
Notes: filterText.<fieldName> will treat all fields as strings. That is to say, it can be enabled
on entirely numerical fields, such as chromStart , if one is looking to filter numerical values as
text In order for filters to work, the track must be " type bigBed N + " or " type bigBed N . ". Including
the "+" (for bigBed+ tracks) or a "." (for non-extended bigBed tracks) is required Filters are not
supported in bed3 or bed4 files, even bed 3+x. The file must be at least a bed5 By default, all bed
tracks that are at least bed5 will have a score filter. Enabling any of the filter*.<fieldName> filter
settings will disable that default filter
- filterText.<fieldName> will treat all fields as strings. That is to say, it can be enabled on entirely
numerical fields, such as chromStart , if one is looking to filter numerical values as text
- In order for filters to work, the track must be " type bigBed N + " or " type bigBed N . ". Including
the "+" (for bigBed+ tracks) or a "." (for non-extended bigBed tracks) is required Filters are not
supported in bed3 or bed4 files, even bed 3+x. The file must be at least a bed5 By default, all bed
tracks that are at least bed5 will have a score filter. Enabling any of the filter*.<fieldName> filter
settings will disable that default filter
- Filters are not supported in bed3 or bed4 files, even bed 3+x. The file must be at least a bed5
- By default, all bed tracks that are at least bed5 will have a score filter. Enabling any of the
filter*.<fieldName> filter settings will disable that default filter
In this example, we are applying a default filter on the field geneName so that only items with BRCA
in the geneName are visible. By default, this is a wildcard search of *BRCA* which is equivelant to
a regexp search .*BRCA.* . The filter term can be freely changed in the track setting page allowing
users to filter on other values in the geneName field.
This example is enabling filtering on the same field as above, geneName , however, it is not declaring
a default search parameter. This is done by passing only an asterisk/wildcard (*). This means that
the search box will be present but no geneName items will be filtered out of the data unless the user
specifies a value.
This example once again enables filtering on the same field, however, it is declaring regexp as the
filter type and passing a regular expression to be applied by default. In this case, we are targeting
all geneName items that are version 1.'
format: filterText.<fieldName> <default search string>
examples:
- filterText.geneName *BRCA*
- filterText.geneName *
- "filterText.geneName \\.1$\n filterType.geneName regexp"
- name: filterValues
types:
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: There are a number of different filters available for bigBed data.
description: 'There are a number of different filters available for bigBed data. See the Filters Quick
Start guide for more info. Note: for configurable features, like filters, an additional period "."
or plus "+" is required in the type declaration, for instance type bigBed 5 . or type bigBed 9 + .
filterValues.<fieldName> is used to enable filtering by specified values within a field. It can be
used on fields that can contain one text value or a list of comma-separated values of text, like "classA,classB".
Usually these are category names. The option requires at least one value to filter on.
Every individual possible value that can ever occur in the field must be passed in a comma separated
list. If there are commas in the values, two commas can be used to designate literal commas. You will
then be able to select those values as categories, choosing to display only items that belong to one,
any, or at least one of the selected values. By default, the user can select multiple values from
this list and the filter lets pass any features with at least one of these values ( multiple ).
In order to choose the default selection behavior, the optional parameter filterType.<fieldName> may
be used. If this parameter is not passed, by default the selection will be set to "one or more match"
which is the same as having filterType.fieldName multiple . If the user should only be able to select
a single value, single can be passed instead. Another option, multipleListAnd , means that the user
can select multiple categories, but the filter will let pass only features where all of these categories
are present.
Both single and multiple have "list" options. These options split the bigBed field values by commas,
meaning that they should only be used when items can contain multiple values at once in the desired
filter field. For example, if my data is classifying variants, and they can only be a SNV, insertion,
or deletion, I will want to use single and multiple . However, if instead the filter will be on a
field classifying functional impact, there can be many values for each item. For example, variant
rs11541299, which is both a synonymous variant and a coding sequence variant. In this case, I would
want to use one of the "list" options. Most simply singleList or multipleList , or one of the additional
varieties of multipleList depending on the desired options.
multipleListOr and multipleListAnd both still let the user override the type of combination manually
in the user interface with a radio button. If you specify multipleListOnlyOr or multipleListOnlyAnd
then the radiobutton is suppressed and the user cannot choose between the options anymore. This can
be used in cases where by the nature of the field, it makes little sense to offer the OR or AND search.
You can also choose which values to have selected by default using the filterValuesDefault.<fieldName>
parameter. It can take a comma separated list just like filterValues.<fieldName> , and any items included
will be automatically selected. Not that the values need to be present in both settings.
The labels in the menu shown to the user can be configured to display a different name/label than
the one present in the bigBed field. This can be helpful when the data values are written in short
form, but you want a longer more descriptive name to show up in the UI. The format for this substitution
is as follows:
E.g. if the value in the bigBed field is AML , a setting like Acute Myeloid Leukemia|AML will show
Acute Myeloid Leukemia in the user interface but will lead to the value AML being searched in the
bigBed field. This can reduce the size of the bigBed file a lot. See example below for more information.
Notes: Currently, all values must be stated individually Value names must match exactly By default,
all bed tracks that are at least bed5 will have a score filter. Enabling any of the filter*.<fieldName>
filter settings will disable that default filter In order for filters to work, the track must be "
type bigBed N + " or " type bigBed N . ". Including the "+" (for bigBed+ tracks) or a "." (for non-extended
bigBed tracks) is required Filters are not supported in bed3 or bed4 files, even bed 3+x. The file
must be at least a bed5 There should not be any white spaces between declared items after commas,
e.x. "itemOne,itemTwo,itemThree" The default label can be customized with the filterLabel.<fieldName>
parameter When using filter values in a field that incudes commas, an additional comma can be used
to escape it. E.x. "fieldOne,fieldTwo,,fieldTwo,fieldThree"
- Currently, all values must be stated individually
- Value names must match exactly
- By default, all bed tracks that are at least bed5 will have a score filter. Enabling any of the
filter*.<fieldName> filter settings will disable that default filter
- In order for filters to work, the track must be " type bigBed N + " or " type bigBed N . ". Including
the "+" (for bigBed+ tracks) or a "." (for non-extended bigBed tracks) is required Filters are not
supported in bed3 or bed4 files, even bed 3+x. The file must be at least a bed5 There should not be
any white spaces between declared items after commas, e.x. "itemOne,itemTwo,itemThree" The default
label can be customized with the filterLabel.<fieldName> parameter When using filter values in a field
that incudes commas, an additional comma can be used to escape it. E.x. "fieldOne,fieldTwo,,fieldTwo,fieldThree"
- Filters are not supported in bed3 or bed4 files, even bed 3+x. The file must be at least a bed5
- There should not be any white spaces between declared items after commas, e.x. "itemOne,itemTwo,itemThree"
- The default label can be customized with the filterLabel.<fieldName> parameter
- When using filter values in a field that incudes commas, an additional comma can be used to escape
it. E.x. "fieldOne,fieldTwo,,fieldTwo,fieldThree"
In this simple example, we are applying filterValues.<fieldName> to the OddEven field, which designates
either "Even" or "Odd". We can then filter the data using the OddEven field with a drop-down menu
displayed on the track controls page to just evens or odds. As there is no filterType, the user can
also show both evens and odds at the same time.
In this follow up example, we are passing the filterType.fieldName singleList parameter, which means
that only one item in the OddEven field can be chosen, in this case "Odd" or "Even". This removes
the default that allows multiple selections.
In this third example, we have added the filterValuesDefault.fieldName parameter as well. Now the
default filter when the hub is loaded will have the Odd value preselected.
In this example the filter is being applied to multiple values in the annotationType field. We can
then select from these values in the annotationType field with a drop-down menu displayed on the track
settings page, and display only items that match our selections. The selection choices will let us
match one, all, or any combination of the supplied values.
In this follow up to the previous question, we have changed the name of the items that show up in
the drop down menu to be more descriptive than the dense file format values. This means that if we
wanted to only see items with annotationType of DNA-BR , we would select DNA-binding region from the
interface menu.'
format: filterValues.<fieldName> <value1,value2,value3...>
examples:
- filterValues.fieldName fieldValue1|alternativeName1,fieldValue2|alternativeName2...
- filterValues.OddEven Odd,Even
- "filterValues.OddEven Odd,Even\n filterType.OddEven singleList"
- "filterValues.OddEven Odd,Even\n filterType.OddEven singleList\n filterValuesDefault.OddEven\
\ Odd"
- filterValues.annotationType DNA-BR,AS,BS,BSi
- filterValues.annotationType DNA-BR|DNA-binding region,AS|active site,BS|beta strand,BSi|binding site
- name: filterBy
types:
- bed
- bigBed
- genePred
- bigGenePred
- psl
- bigPsl
- bigLolly
- factorSource
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: Another method of filtering items relies upon discrete values.
description: '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:
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.
The best way to understand this setting is with an example. This is an operational example in the
hg19 "Open Chrom Synth" track.
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.'
format: "filterBy <field1:title=[+]opt1a...>\n [field2:title=[+]opt2a...]"
examples:
- "filterBy {field1}[:{Title1}]=[+]\\\n option1a[|label1a[{style1a}]],\\\n option1b[|label1b[{style1b}]],...\
\ \\\n [{field2}[:{Title2}]=[+]\\\n option2a[|label2a[{style2a}]],,...]"
- "filterBy color:Validation_Level=\\\n 0|Validated_(OC_1){color:#000000},\\\n \
\ 255|Open_Chromatin_(OC_2-3){color:#0000FF},\\\n 39168|DNase_low_(OC_2){color:#009900},\\\
\n 10027008|FAIRE_low_(OC_3){color:#990000},\\\n 16711935|ChIP-seq_(OC_4){color:#FF00FF}\
\ \\\n ocCode:OC_Code=+\\\n One:_Validated_(all),\\\n Two:_DNase_(all),\\\
\n Three:_FAIRE_(all),\\\n Four:_ChIP_(all)"
- name: filterLabel
types:
- bed
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: full
required: false
summary: When a user clicks on a track item in the Browser image, the item detail page is shown.
description: 'When a user clicks on a track item in the Browser image, the item detail page is shown.
This setting specifies an alternate label for the filter on that page. Without this setting, the label
will be the description of the field as specified by the autoSql (.as) file. Some of the parameters
modified by this are:
filter.<fieldName> filterText.<fieldName> filterValues.<fieldName>
- filter.<fieldName>
- filterText.<fieldName>
- filterValues.<fieldName>
In this example, we have a standard "strand" BED field with the default description "+ or - for strand".
We have enabled a filter and simplified the label to just "Strand (Orientation)".'
format: filterLabel.<fieldName> <label>
examples:
- "filterValues.strand +,-\n filterLabel.strand Strand (Orientation)"
- name: filterPriority
types:
- bed
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: new
required: false
summary: Sets the display order of filters on the track configuration page.
description: 'Sets the display order of filters on the track configuration page. Filters are shown in
ascending order of filterPriority value (lowest first), so a filter with priority 1 appears above
one with priority 2. Filters that do not specify a priority sort after all filters that do, sorted
alphabetically by field name.
The setting applies to any filter declared on <fieldName> , regardless of which filter style is used.
filter.<fieldName> , filterText.<fieldName> , and filterValues.<fieldName> all share a single filterPriority.<fieldName>
entry. The companion setting highlightPriority.<fieldName> does the same for highlight*.<fieldName>
.
Numbers may be integers or decimals; only the relative ordering matters, so values like 1 2 3 and
10 20 30 produce the same layout, as do decimal values such as 0.5 1 1.5 . Filters of different types
appear in fixed sections in this order: numeric range filters first, then text filters, then values
(categorical) filters. filterPriority orders the filters within each section.
In this example, the variation type filter is shown first, the annotation filter second, and the FILTER
tags filter last, regardless of the order in which the filterValues.* lines appear in the stanza or
the alphabetical order of field names.'
format: filterPriority.<fieldName> <number>
examples:
- "filterValues.variation_type 3_prime_UTR_variant,5_prime_UTR_variant,...\n filterValues.annot pLoF,missense,synonymous,other\n\
\ filterValues.FILTER PASS,InbreedingCoeff,RF,AC0\n filterPriority.variation_type 1\n filterPriority.annot\
\ 2\n filterPriority.FILTER 3"
- name: highlight
types:
- bed
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: new
required: false
summary: Similar to filters, There are a number of different highlights available for bigBed data.
description: 'Similar to filters, There are a number of different highlights available for bigBed data.
See the Filters Quick Start guide for more information on setting up filters. Note: for configurable
features, like highlights, an additional period "." or plus "+" is required in the type declaration,
for instance type bigBed 5 . or type bigBed 9 + .
All of these settings follow exactly the same syntax and functionality as the filter.fieldName, filterByRange.fieldName,
and filterLimits.fieldName explained above, except instead of items being excluded from the display,
they are striped with a colored background to appear "highlighted" compared to the other items in
the display. You can control the default highlight color with the highlightColor setting, or with
the color picker on the configuration page when interacting with the track. Please note that at this
time only one higlight color is available per track, and if multiple highlight settings are present
on the same track, only items that pass ALL highlight settings will highlighted.
In this example, highlighting is enabled for the blockCount field. We are passing a default value
of 4, which will highlight items where the blockCount is 4 or above.
In this example, highlighting is enabled for the score field. We are passing a default value of 300,
which will highlight all items with a score of 300 or above.
In this example, we are enabling highlights for a range on the score field. The highlightByRange setting
is also enabled, allowing for highlighting between interval values. Lastly, the highlightLimits are
being used to modify the accepted values between 200 and 500 as opposed to the default 0 to 1000.'
format: highlight.<fieldName> <default integer>
examples:
- highlight.blockCount 4
- highlight.score 300
- "highlight.score 300:400\n highlightByRange.score on\n highlightLimits.score 200:500"
- name: highlightText
types:
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: new
required: false
summary: Similar to filters, There are a number of different highlights available for bigBed data.
description: 'Similar to filters, There are a number of different highlights available for bigBed data.
See the Filters Quick Start guide for more information on setting up filters. Note: for configurable
features, like highlights, an additional period "." or plus "+" is required in the type declaration,
for instance type bigBed 5 . or type bigBed 9 + .
All of these settings follow exactly the same syntax and functionality as the filter.fieldName, filterByRange.fieldName,
and filterLimits.fieldName explained above, except instead of items being excluded from the display,
they are striped with a colored background to appear "highlighted" compared to the other items in
the display. You can control the default highlight color with the highlightColor setting, or with
the color picker on the configuration page when interacting with the track. Please note that at this
time only one higlight color is available per track, and if multiple highlight settings are present
on the same track, only items that pass ALL highlight settings will highlighted.
In this example, we are applying a highlight on the field name so any items that start with NM are
highlighted.
In this example, we are enabling highlighting on the same name field, name but declaring the search
parameter with the highlightType . In this case, we are using regular expression to highlight all
items in the name field that are version 1.'
format: highlightText.<fieldName> <default search string>
examples:
- highlightText.name NM*
- "highlightText.name \\.1$\n highlightType.name regexp"
- name: highlightValues
types:
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: new
required: false
summary: Similar to filters, There are a number of different highlights available for bigBed data.
description: 'Similar to filters, There are a number of different highlights available for bigBed data.
See the Filters Quick Start guide for more information on setting up filters. Note: for configurable
features, like highlights, an additional period "." or plus "+" is required in the type declaration,
for instance type bigBed 5 . or type bigBed 9 + .
All of these settings follow exactly the same syntax and functionality as the filter.fieldName, filterByRange.fieldName,
and filterLimits.fieldName explained above, except instead of items being excluded from the display,
they are striped with a colored background to appear "highlighted" compared to the other items in
the display. You can control the default highlight color with the highlightColor setting, or with
the color picker on the configuration page when interacting with the track. Please note that at this
time only one higlight color is available per track, and if multiple highlight settings are present
on the same track, only items that pass ALL highlight settings will highlighted.
In this example, we are applying highlightValues. to the OddEven field, which designates either "Even"
or "Odd". We can then highlight the OddEven field with a drop-down menu displayed on the track controls
page to highlight the even or odd items. Since there is no highlightType setting, the user can highlight
both even and odd items at the same time.
In this example, we are passing the highlightType. singleList parameter, which means only one options
can be chosen -- "Even" or "Odd". This setting removed the default setting that allows multiple selections.
In this third example, we are using the highlightValuesDefault. setting to set a default value for
the highlight setting. Now the default will be to highlight items with an Odd value when the hub is
loaded on the Genome Browser.
In this fourth example, we are applying a highlight to multiple values in the annotationType field.
We can select from these values in the annotationType field with a drop-down menu displayed on the
track settings page, and highlight only items that match our selections. The selection choices will
let us match one, all or any combination of the supplied values.
Similar to the last example, but we have changed the name of the items that show up in the drop-down
menu to be more descriptive than the dense file format values. For example, if we wanted to highlight
only items with annotationType of DNA-BR , on the track settings page, we would select DNA-binding
region .'
format: highlightValues.<fieldName> <value1,value2,value3...>
examples:
- highlightValues.OddEven Odd
- "highlightValues.OddEven Odd,Even\n highlightType.OddEven singleList"
- highlighValuesDefault.OddEven Odd
- highlightValues.annotationType DNA-BR,AS,BS,BSi
- highlightValues.annotationType DNA-BR|DNA-binding region,AS|active site,BS|beta strand,BSi|binding
site
- name: highlightColor
types:
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: new
required: false
summary: Sets the default color for all of the various highlights defined in this stanza In this example,
we are using the highlightColor to set the default highlight...
description: 'Sets the default color for all of the various highlights defined in this stanza
In this example, we are using the highlightColor to set the default highlight color. With this setting,
all highlight stripes will use the color red, #ff0000 .'
format: highlightColor <hexcolor>
examples:
- 'highlightColor #ff0000'
- name: highlightPriority
types:
- bed
- bigBed
roles:
- leaf
category: bigBed - Item or Region Track Settings
context: trackDb
level: new
required: false
summary: Sets the display order of highlights on the track configuration page.
description: 'Sets the display order of highlights on the track configuration page. Highlights are shown
in ascending order of highlightPriority value (lowest first), so a highlight with priority 1 appears
above one with priority 2. Highlights that do not specify a priority sort after all highlights that
do, sorted alphabetically by field name.
The setting applies to any highlight declared on <fieldName> , regardless of which highlight style
is used. highlight.<fieldName> , highlightText.<fieldName> , and highlightValues.<fieldName> all share
a single highlightPriority.<fieldName> entry.
Numbers may be integers or decimals; only the relative ordering matters, so values like 1 2 3 and
10 20 30 produce the same layout, as do decimal values such as 0.5 1 1.5 . Highlights of different
types appear in fixed sections in this order: numeric range highlights first, then text highlights,
then values (categorical) highlights. highlightPriority orders the highlights within each section.
In this example, the variation type highlight is shown first, the annotation highlight second, and
the FILTER tags highlight last, regardless of the order in which the highlightValues.* lines appear
in the stanza or the alphabetical order of field names.'
format: highlightPriority.<fieldName> <number>
examples:
- "highlightValues.variation_type 3_prime_UTR_variant,5_prime_UTR_variant,...\n highlightValues.annot\
\ pLoF,missense,synonymous,other\n highlightValues.FILTER PASS,InbreedingCoeff,RF,AC0\n highlightPriority.variation_type\
\ 1\n highlightPriority.annot 2\n highlightPriority.FILTER 3"
- name: bedNameLabel
types:
- bed
- bigBed
roles:
- leaf
category: Item or Region Track Settings - less frequent
context: trackDb
level: full
required: false
summary: When a user clicks on a bed track item in the Browser image, the item detail page is shown.
description: 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:".
format: bedNameLabel <label>
examples:
- bedNameLabel Gene Id
- name: exonArrowsDense
types:
- bed
- bigBed
- genePred
- bigGenePred
- psl
- bigPsl
- chain
- bigChain
- narrowPeak
- bigNarrowPeak
- broadPeak
- bam
roles:
- leaf
category: Item or Region Track Settings - less frequent
context: trackDb
level: full
required: false
summary: On tracks that show exons or blocks within items, exon arrows allow the user to jump to the
next exon/block outside the image.
description: 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.
format: exonArrowsDense <off/on>
examples: []
- name: itemImagePath
types:
- bed
- bigBed
roles:
- leaf
category: Item or Region Track Settings - less frequent
context: trackDb
level: full
required: false
summary: Items can be associated with images and the images can be made visible with these two settings.
description: '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.
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 .'
format: itemImagePath <path> <suffix>
examples:
- "itemImagePath images/myTrackImages png\n itemBigImagePath http://bigImages.com/myTrackImages jpg"
- name: mergeSpannedItems
types:
- bigBed
roles:
- leaf
category: Item or Region Track Settings - less frequent
context: trackDb
level: full
required: false
summary: Allows merging all track items that extend beyond both sides of the current viewing window
into one bed item in the display.
description: 'Allows merging all track items that extend beyond both sides of the current viewing window
into one bed item in the display. The presence of this setting permits the display to offer this collapsed
viewing option, while the on or off denotes what view should be shown by default.
The display can be enabled/disabled by the user either on the normal track configuration page, or
via selection from the right-click menu. If the track is a bigBed 9 (+), then the merged item will
be shaded as the average of all the merged items.'
format: mergeSpannedItems <on/off>
examples:
- mergeSpannedItems on
- name: linkIdInName
types:
- bed
- bigBed
roles:
- leaf
category: Item or Region Track Settings - less frequent
context: trackDb
level: full
required: false
summary: This setting changes the meaning of the bed name field to "identifier description".
description: 'This setting changes the meaning of the bed name field to "identifier description". If
it is activated, the browser does not show the first word of the BED item name, but uses this first
word for linking out to the item detail page. This allows putting both an identifier, like a gene
ID, and its human-readable description into the BED item name field, separated by a space.
A BED name field of "9005 PITX2" will be shown "PITX2" on the genome browser, but when the user clicks
on it, the URL will be built only from the first word, by default cgi-bin/hgc?i=9005&(...). The URL
can be changed with directUrl , where %s is replaced by the identifier.
bigBed files are often created using the UCSC bedToBigBed program. By default, this program expects
only a single word for BED item names. To tell the program to accept multiple words separated by spaces
(required for this track setting), you will need to use the -tab option for bedToBigBed . This tells
the program that that tab characters are used instead of spaces to separate fields of the BED file.
Please note that this option will only work if tab characters are used as the field separator throughout
your BED file. More information on creating bigBed files is available on our bigBed Track Format page.'
format: linkIdInName on
examples:
- linkIdInName on
- name: nextExonText
types:
- bed
- bigBed
- genePred
- bigGenePred
- psl
- bigPsl
- chain
- bigChain
- narrowPeak
- bigNarrowPeak
- broadPeak
roles:
- leaf
category: Item or Region Track Settings - less frequent
context: trackDb
level: full
required: false
summary: For tracks that offer multiple block items such as gene models, the next/previous exon arrows
are usually displayed by default in the Browser.
description: 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.
format: nextExonText <str>
examples:
- "nextExonText \"Next Match\"\n prevExonText \"Previous Match\""
- name: scoreLabel
types:
- bed
- bigBed
- bigPsl
- bigGenePred
- bigNarrowPeak
roles:
- leaf
category: Item or Region Track Settings - less frequent
context: trackDb
level: full
required: false
summary: When a user clicks on a track item in the Browser image, the item detail page is shown.
description: When a user clicks on a track item in the Browser image, the item detail page is shown.
This setting specifies an alternate label for the score on that page. Without this setting, the label
will be "Score:".
format: scoreLabel <label>
examples:
- scoreLabel Log of binding Score * 1000
- name: showTopScorers
types:
- bed
- bed5FloatScoreWithFdr
- bed5FloatScore
roles:
- leaf
category: Item or Region Track Settings - less frequent
context: trackDb
level: full
required: false
summary: 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.
description: 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.
format: 'showTopScorers #'
examples:
- showTopScorers 20
- name: bigChain
types:
- bigChain
roles:
- leaf
category: bigChain - Pairwise Alignments
context: trackDb
level: null
required: false
summary: ''
description: ''
format: type bigChain targetDb
examples: []
- name: linkDataUrl
types:
- bigChain
roles:
- leaf
category: bigChain - Pairwise Alignments
context: trackDb
level: full
required: true
summary: The location of a remote data file containing the chain link data.
description: The location of a remote data file containing the chain link data.
format: linkDataUrl <url/relativePath>
examples: []
- name: chainColor
types:
- chain
- bigChain
roles:
- leaf
category: bigChain - Pairwise Alignments
context: trackDb
level: full
required: false
summary: By default chains are colored by the alignment chromosome of the query species.
description: '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 - default
- Normalized Score - chains are colored by score
- Black - no coloring occurs
This setting affects chain but not netAlign type tracks.'
format: chainColor <scheme>
examples:
- chainColor Black
- name: chainNormScoreAvailable
types:
- chain
- bigChain
- netAlign
- bed
roles:
- leaf
category: bigChain - Pairwise Alignments
context: trackDb
level: full
required: false
summary: A given chain or netAlign track may or may not have a populated normScore column.
description: 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 .
format: chainNormScoreAvailable <yes/no>
examples:
- "chainNormScoreAvailable yes\n chainColor Normalized Score"
- name: baseColorUseSequence
types:
- bed
- bigBed
- genePred
- psl
- bigPsl
- chain
- bigChain
- bam
roles:
- leaf
category: bigChain - Pairwise Alignments
context: trackDb
level: full
required: false
summary: 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 sma...
description: '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 extFile is 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 hgPcrResult is specified then a PCR result is used.
- If lfExtra is specified then the sequence of an item is found in the last column of the table or
remote file.
- If nameIsSequence is specified then the 4th column ( name or sequence ) contains the sequence. (see
hg/lib/encode/tagAlign.as)
- If seq1Seq2 is specified then the 7th & 8th columns ( seq1 and seq2 ) contain the left and right
pairs of the sequence. (see hg/lib/encode/pairedTagAlign.as)
- If ss is specified then a user-provided blat sequence is looked for.
- If 2bit is specified then looks for sequence in the file specified by the otherTwoBitUrl tag.'
format: "baseColorUseSequence <extFile {seqTable} /\n hgPcrResult / lfExtra / nameIsSequence\
\ / seq1Seq2 / ss / 2bit >"
examples: []
- name: baseColorDefault
types:
- bed
- bigBed
- genePred
- bigGenePred
- psl
- bigPsl
- chain
- bigChain
- bam
roles:
- leaf
category: bigChain - Pairwise Alignments
context: trackDb
level: full
required: false
summary: Specifies the default drawing mode.
description: 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.
format: "baseColorDefault\n <diffBases/diffCodons/itemBases/itemCodons/genomicCodons>"
examples: []
- name: bigNet
types:
- bigNet
roles:
- leaf
category: bigNet - Alignment Nets
context: trackDb
level: new
required: false
summary: ''
description: ''
format: type bigNet targetDb chainTrack
examples: []
- name: bigGenePred
types:
- bigGenePred
roles:
- leaf
category: bigGenePred - Gene Annotations
context: trackDb
level: null
required: false
summary: ''
description: ''
format: type bigGenePred
examples: []
- name: intronGap
types:
- genePred
- bigGenePred
- psl
- bigPsl
roles:
- leaf
category: bigGenePred - Gene Annotations
context: trackDb
level: full
required: false
summary: In drawing gene models, it can be useful to see "exon arrows" when the transcript extends beyond
the current window.
description: '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.
Don''t draw exon arrows when the gap between exons is 12 bases or less.'
format: intronGap <#bases>
examples:
- intronGap 12
- name: bigInteract
types:
- bigInteract
roles:
- leaf
category: bigInteract
context: trackDb
level: null
required: false
summary: ''
description: ''
format: type bigInteract
examples: []
- name: interactDirectional
types:
- bigInteract
roles:
- leaf
category: bigInteract
context: trackDb
level: full
required: false
summary: This setting is used when the interaction has an orientation (direction of effect).
description: 'This setting is used when the interaction has an orientation (direction of effect). The
offset setting shows the source (offsetSource) or target (offsetTarget) below the other end type;
that is vertically displaced in the image. The interaction is drawn with dashed lines when the target
region precedes the source region (reverse direction) in the genome.
The cluster setting collects all interactions with the same source (clusterSource) or target (clusterTarget)
and displays each group as a single linked block display in the browser. This provides an alternate
view of an interact file.'
format: interactDirectional <true|offsetSource|offsetTarget|clusterSource|clusterTarget>
examples: []
- name: interactUp
types:
- bigInteract
roles:
- leaf
category: bigInteract
context: trackDb
level: full
required: false
summary: This setting flips the curved full visibility display so that the peak of the curves is 'up'
(hills instead of valleys).
description: This setting flips the curved full visibility display so that the peak of the curves is
'up' (hills instead of valleys).
format: interactUp <true|false>
examples: []
- name: detailsBoxesEnabled
types:
- bigInteract
roles:
- leaf
category: bigInteract
context: trackDb
level: new
required: false
summary: This setting controls the default behavior for suppressing the "box" links to hgc details pages
that appear on the lines connecting interacting regions.
description: This setting controls the default behavior for suppressing the "box" links to hgc details
pages that appear on the lines connecting interacting regions. Useful for generating figures without
those markers. The default value is true - set it to false to hide the boxes. It can still be overridden
in the UI for the track.
format: detailsBoxesEnabled <true|false>
examples: []
- name: interactMultiRegion
types:
- bigInteract
roles:
- leaf
category: bigInteract
context: trackDb
level: full
required: false
summary: This setting causes a link to appear on the details page that appears when an interaction is
clicked on.
description: This setting causes a link to appear on the details page that appears when an interaction
is clicked on. This link will generate a "multi-region" Genome Browser view of the interaction (or
interaction cluster) endpoints. Use padding to specify non-default padding at the edges of each region.
The default value is 200 base pairs.
format: interactMultiRegion <true|padding>
examples: []
- name: endsVisible
types:
- bigInteract
roles:
- leaf
category: bigInteract
context: trackDb
level: full
required: false
summary: This setting makes the default behavior for the track show only interactions with both ends
in the window.
description: This setting makes the default behavior for the track show only interactions with both
ends in the window.
format: endsVisible two
examples: []
- name: bigMaf
types:
- bigMaf
roles:
- leaf
category: bigMaf - Multiple Alignments
context: trackDb
level: null
required: false
summary: ''
description: ''
format: type bigMaf
examples: []
- name: speciesOrder
types:
- wigMaf
- bigMaf
roles:
- leaf
category: bigMaf - Multiple Alignments
context: trackDb
level: full
required: false
summary: Use speciesOrder to declare the order of the stacked alignments.
description: 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.
format: speciesOrder <species1> [species2 ...]
examples: []
- name: speciesLabels
types:
- wigMaf
- bigMaf
roles:
- leaf
category: bigMaf - Multiple Alignments
context: trackDb
level: new
required: false
summary: Use speciesLabels to specify new labels that map to sequence names.
description: Use speciesLabels to specify new labels that map to sequence names.
format: speciesLabels <species1=newLabel1> [species2=newLabel2 ...]
examples:
- speciesLabels mm10=mouse_mm10 mm39=mouse_mm39
- name: pairwiseHeight
types:
- wigMaf
- bigMaf
roles:
- leaf
category: bigMaf - Multiple Alignments
context: trackDb
level: full
required: false
summary: A wigMaf display in the Browser image is a stacked set of pairwise alignments to the target
genome.
description: 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.
format: pairwiseHeight <#>
examples:
- pairwiseHeight 10
- name: speciesGroups
types:
- wigMaf
- bigMaf
roles:
- leaf
category: bigMaf - Multiple Alignments
context: trackDb
level: full
required: false
summary: You can include a list of "clades" to group the species into.
description: '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.
Choose one of these two alternatives to display species.'
format: speciesGroups <sgroup1> [sgroup2 ...]
examples:
- "speciesOrder panTro1 canFam1 mm5 rn3 \\\n galGal2 fr1 danRer1\n speciesGroups\
\ Mammal Vertebrate\n sGroup_Mammal mm9 rn4\n sGroup_Vertebrate galGal2 fr1 danRer1"
- name: speciesDefaultOff
types:
- wigMaf
- bigMaf
roles:
- leaf
category: bigMaf - Multiple Alignments
context: trackDb
level: full
required: false
summary: 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...
description: 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).
format: speciesDefaultOff <species1> [species2 ...]
examples:
- speciesDefaultOff galGal2 fr1 danRer1
- name: speciesCodonDefault
types:
- wigMaf
- bigMaf
roles:
- leaf
category: bigMaf - Multiple Alignments
context: trackDb
level: full
required: false
summary: This setting, which is used with "frames", declares the default species for the codon reading
frame.
description: This setting, which is used with "frames", declares the default species for the codon reading
frame.
format: speciesCodonDefault <species>
examples:
- "speciesCodonDefault hg19\n frames myCodonFrames"
- name: itemFirstCharCase
types:
- wigMaf
- bigMaf
roles:
- leaf
category: bigMaf - Multiple Alignments
context: trackDb
level: full
required: false
summary: This controls if species names in the multiple alignment should be capitalized in the pairwise
display.
description: This 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.
format: itemFirstCharCase noChange
examples:
- itemFirstCharCase noChange
- name: irows
types:
- wigMaf
- bigMaf
roles:
- leaf
category: bigMaf - Multiple Alignments
context: trackDb
level: full
required: false
summary: 'By default, gaps in the non-reference species are filled with the placeholder character: Single
Line '' - '': No bases in the aligned species.'
description: 'By 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. These display conventions make
it easier to visualize the columns in stacked alignments, but they also tend to clutter the display.
The user has the option to remove these placeholders by unchecking the "Display chains between alignments"
option. To set the default of this option to off, set irows to " off ".
- 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.'
format: irows off
examples:
- irows off
- name: frames
types:
- wigMaf
- bigMaf
roles:
- leaf
category: bigMaf - Multiple Alignments
context: trackDb
level: full
required: false
summary: A wigMaf or bigMaf track can display gene codon translation.
description: A wigMaf or bigMaf 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. For bigMaf the value is expected to be a bigBed, for wigMaf
it should be a table. Read about bigMaf supporting files on the help page.
format: frames <table/url>
examples:
- frames myCodonFrames
- frames myCodonFrames.bb
- name: summary
types:
- wigMaf
- bigMaf
roles:
- leaf
category: bigMaf - Multiple Alignments
context: trackDb
level: full
required: false
summary: This setting contains a table name containing a MAF summary table, or a url that points to
a bigBed containing that information.
description: This setting contains a table name containing a MAF summary table, or a url that points
to a bigBed containing that information. 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 (SQL track) or mafToBigMafSummary (bigMaf). For bigMaf, the
value is assumed to be bigBed, Read about bigMaf supporting files on the help page.
format: summary <tableName/url>
examples:
- summary hg17Maf8waySummary
- name: bigNarrowPeak
types:
- bigNarrowPeak
roles:
- leaf
category: bigNarrowPeak - Peaks
context: trackDb
level: null
required: false
summary: ''
description: ''
format: type bigNarrowPeak
examples: []
- name: Filter
types:
- bed
- bigBed
- narrowPeak
- bigNarrowPeak
- broadPeak
roles:
- leaf
category: bigNarrowPeak - Peaks
context: trackDb
level: full
required: false
summary: A number of numerical filters are available for bed tracks.
description: '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.
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.
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.'
format: <column>Filter <low>[:<high>]
examples:
- scoreFilter 100
- "pValueFilter 3.0:15.0\n pValueFilterLimits 0.0:15.0\n pValueFilterByRange on"
- name: bigPsl
types:
- bigPsl
roles:
- leaf
category: bigPsl - Pairwise Alignments
context: trackDb
level: null
required: false
summary: ''
description: ''
format: type bigPsl
examples: []
- name: baseColorUseCds
types:
- bed
- bigBed
- genePred
- bigGenePred
- psl
- bigPsl
roles:
- leaf
category: bigPsl - Pairwise Alignments
context: trackDb
level: full
required: false
summary: Specifies where coding sequence (CDS) coordinates can be found (if any) so that codons can
be drawn when viewing a sufficiently small region.
description: Specifies where coding sequence (CDS) coordinates can be found (if any) so that codons
can be drawn when viewing a sufficiently small region.
format: baseColorUseCds <given>
examples:
- baseColorUseCds given
- name: baseColorTickColor
types:
- bed
- bigBed
- psl
- bigPsl
roles:
- leaf
category: bigPsl - Pairwise Alignments
context: trackDb
level: full
required: false
summary: Sets the color of the tick marks that mark where item bases differ from the genome.
description: 'Sets the color of the tick marks that mark where item bases differ from the genome. Those
marks appear when the track draws with baseColorDefault diffBases and the view is zoomed out past
base level. Their default color is red.
- contrastingColor : a color that stands out against the item color, often white.
- lighterShade : a lighter version of the item color.
Both values are worked out from the item''s own color, so this setting does nothing unless the track
gives each item a color. In a hub the way to do that is colorByStrand . Without it the setting is
read and ignored, and the tick marks stay red. itemRgb does not count here: it colors an item as it
is drawn, but it does not give the track the per-item color this setting reads.'
format: baseColorTickColor <lighterShade/contrastingColor>
examples:
- "colorByStrand 0,0,200 200,0,0\n baseColorDefault diffBases\n baseColorTickColor contrastingColor"
- name: showDiffBasesAllScales
types:
- bed
- bigBed
- genePred
- psl
- bigPsl
- chain
- bigChain
- bam
roles:
- leaf
category: bigPsl - Pairwise Alignments
context: trackDb
level: full
required: false
summary: Show base differences for all zoom levels.
description: Show base differences for all zoom levels.
format: showDiffBasesAllScales on
examples: []
- name: pslSequence
types:
- psl
- bigPsl
roles:
- leaf
category: bigPsl - Pairwise Alignments
context: trackDb
level: deprecated
required: false
summary: Obsolete.
description: 'Obsolete. The Browser does not read this setting. It selected how bases were labelled
on psl tracks that also have sequence loaded. The baseColor family replaced it in 2006, and nothing
has read either this spelling or the older pslSequenceBases since. all is now baseColorDefault itemBases
. different is now baseColorDefault diffBases . no left the choice to the user, which is what happens
when baseColorDefault is not set. Both replacements need baseColorUseSequence to be set. Remove pslSequence
from a trackDb file; it has no effect.
- all is now baseColorDefault itemBases .
- different is now baseColorDefault diffBases .
- no left the choice to the user, which is what happens when baseColorDefault is not set.'
format: pslSequence <no/all/different>
examples: []
- name: showCdsAllScales
types:
- psl
- bigPsl
roles:
- leaf
category: bigPsl - Pairwise Alignments
context: trackDb
level: new
required: false
summary: Show CDS for PSL tracks at all zoom levels.
description: Show CDS for PSL tracks at all zoom levels.
format: showCdsAllScales on
examples: []
- name: showCdsMaxZoom
types:
- psl
- bigPsl
roles:
- leaf
category: bigPsl - Pairwise Alignments
context: trackDb
level: new
required: false
summary: Use this setting (a float) to specify the maximum zoom-out allowed for displaying the CDS for
psl tracks.
description: 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.
format: showCdsMaxZoom <basesPerPixel>
examples:
- "baseColorDefault genomicCodons\n baseColorUseCds given\n showDiffBasesMaxZoom 10000.0\n \
\ showCdsMaxZoom 10000.0\n baseColorUseCds table hgFixed.transMapGeneUcscGenes\n baseColorUseSequence\
\ lfExtra\n baseColorDefault diffCodons\n baseColorTickColor lighterShade\n showDiffBasesAllScales\
\ .\n showCdsAllScales ."
- name: showDiffBasesMaxZoom
types:
- bed
- bigBed
- genePred
- psl
- bigPsl
- chain
- bigChain
- bam
roles:
- leaf
category: bigPsl - Pairwise Alignments
context: trackDb
level: new
required: false
summary: Show annotations highlighting base or codon differences only if current zoom level does not
exceed basesPerPixel (a float).
description: 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.
format: showDiffBasesMaxZoom <basesPerPixel>
examples: []
- name: bigWig
types:
- bigWig
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: null
required: false
summary: The remote data files of type bigWig must declare the expected signal range for the data.
description: The remote data files of type bigWig must declare the expected signal range for the data.
format: type bigWig <#> <#>
examples: []
- name: autoScale
types:
- wig
- bigWig
- bedGraph
- hic
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: base
required: false
summary: This setting is available for both the graph types of tracks (wig, bigWig, bedGraph) and the
Hi-C heatmap tracks (hic).
description: 'This setting is available for both the graph types of tracks (wig, bigWig, bedGraph) and
the Hi-C heatmap tracks (hic). It behaves slightly differently for each.
For graph tracks, 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 two types of autoScale which will ensure
either that the high score in the current viewing window will peak at the top of the graph, or that
all tracks in a composite will be scaled according to the highest point in the viewing window of any
visible tracks in the same composite. Like most graph settings, this is configurable by the user.
Setting it to " on " in trackDb will default the track to auto-scale to data view . The setting will
independently scale its y-axis based on the data within the track. Setting it to " group " in trackDb
will default the track to group auto-scale . With this setting, tracks within the same group will
share the same y-axis scaling. This means that the maximum and minimum values on the y-axis will be
determined based on the data across all tracks within the same group. This can be useful when comparing
multiple tracks and wanting to ensure consistency in scaling. The default is " off " which will set
the track to use vertical viewing range setting .
NOTE: These options can be misleading if a noisy, low signal erroneously appears as significant because
there is no high signal in the view window. To use the group option declare the setting only in the
parent bigWig composite, not in the individual children tracks.
For Hi-C tracks, higher interaction scores are represented with more intense colors. When this setting
is set to " off ", the score at which the color reaches maximum intensity is a fixed value that can
be chosen with the saturationScore trackDb setting. When this setting is set to " on ", the maximum
intensity score changes dynamically depending on the values in the current viewing window. The default
value for this setting is " on ". The " group " option for autoScale is not available for Hi-C tracks.'
format: autoScale <off/on/group>
examples:
- autoScale on
- name: mouseOverFunction
types:
- wig
- bigWig
- bedGraph
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: full
required: false
summary: Limit mouse over value display to only display the fundamental values without any averaging
of multiple data points.
description: Limit mouse over value display to only display the fundamental values without any averaging
of multiple data points. Display will show "zoom in to see values" when fundamental individual values
can not be shown. Useful for tracks where averaging values together is not a valid operation.
format: mouseOverFunction <noAverage>
examples:
- mouseOverFunction noAverage
- name: maxHeightPixels
types:
- wig
- bigWig
- bedGraph
- bigInteract
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: base
required: false
summary: The amount of vertical viewing space for your signal track should be declared, though it is
configurable by the user.
description: '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.
The browser will display the track as 16 pixels high, but the user can scale it up to 100 pixels.'
format: maxHeightPixels <max:default:min>
examples:
- maxHeightPixels 100:16:8
- name: viewLimits
types:
- wig
- bigWig
- bedGraph
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: base
required: false
summary: The data of most interest in a graph track may be contained within a narrow range.
description: '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.
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.'
format: viewLimits <lower:upper>
examples:
- "viewLimits 5:20\n viewLimitsMax0:100"
- name: alwaysZero
types:
- wig
- bedGraph
- bigWig
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: full
required: false
summary: When autoScale is set to "on" or "group" in the signal track, additionally setting alwaysZero
to "on" will ensure that the y=0 value will be in view at all t...
description: 'When autoScale is set to "on" or "group" 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.'
format: alwaysZero <off/on>
examples: []
- name: graphTypeDefault
types:
- wig
- bigWig
- bedGraph
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: full
required: false
summary: The signal can be graphed as either " points " displayed at the signal value, or the default
space-filling " bar ".
description: The signal can be graphed as either " points " displayed at the signal value, or the default
space-filling " bar ".
format: graphTypeDefault points
examples:
- graphTypeDefault points
- name: maxWindowToQuery
types:
- bigWig
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: full
required: false
summary: For bigWigs only When signal data is clicked in the Browser image, the details of the signal
in the current viewing window are displayed.
description: '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.'
format: maxWindowToQuery <integer>
examples: []
- name: negateValues
types:
- wig
- bigWig
- bedGraph
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: full
required: false
summary: Negate the values in the wiggle, meaning that positive values become negative and vice-versa.
description: Negate the values in the wiggle, meaning that positive values become negative and vice-versa.
This is useful for wiggles representing transcription or other activities on the Crick strand. Be
aware that wiggles with negative values are drawn in altColor not color as positive values are. Also,
tracks using the windowing function "mean+whiskers" will see the shading of colors impacted, with
lighter shades for values a standard deviation around the mean, most noticeable when zoomed out and
average calculations are taking place.
format: negateValues <on>
examples: []
- name: setColorWith
types:
- bigWig
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: full
required: false
summary: Specifies the URL to a bed 9 bigBed file.
description: 'Specifies the URL to a bed 9 bigBed file. Notably, this file contains regions (chr + chromStart
+ chromEnd) in the first three fields, and then an RGB value in the 9th field. The associated bigWig
track will then be colored regionally to reflect this bigBed file.
An example of this in use can be seen with CADD 1.7 . It may also be helpful to reference our previously
used script for a method on how to generate this file based on score thresholds, colors, and an input
bigWig track. It is recommended to use windowingFunction minimum alongside this setting in order to
prevent confusing coloring when items are averaged at zoomed out levels.'
format: setColorWith <url/relativePath>
examples:
- setColorWith url or relative path
- name: smoothingWindow
types:
- wig
- bigWig
- bedGraph
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: full
required: false
summary: Often signal information is chunky, because a single value is given for a number of bases.
description: '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.'
format: smoothingWindow <off/1-16>
examples:
- smoothingWindow 4
- name: transformFunc
types:
- wig
- bigWig
- bedGraph
- bed
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: full
required: false
summary: The track's signal can be presented in log scale with this user-configurable setting.
description: 'The track''s signal can be presented in log scale with this user-configurable setting.
Default: NONE.'
format: transformFunc <NONE/LOG>
examples:
- transformFunc LOG
- name: logo
types:
- bigWig
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: new
required: false
summary: Enables dynseq display , which graphs the signal as reference base nucleotide letters with
their heights equal to the signal value within the bigWig track.
description: Enables dynseq display , which graphs the signal as reference base nucleotide letters with
their heights equal to the signal value within the bigWig track. If not sufficiently zoomed in, the
bigWig will revert to bars instead of letters by default. See a working example of the logo dynseq
display on the bigWig help page.
format: logo on
examples:
- logo on
- name: logoMaf
types:
- wig
- bigWig
- bigMaf
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: new
required: false
summary: The argument to logoMaf is the path to a MAF alignment (either a table or bigMaf).
description: The argument to logoMaf is the path to a MAF alignment (either a table or bigMaf). If set
and zoomed into base level, the wiggle will be drawn as a sequence logo calculated by counting the
number of each nucleotide aligned to that base, which will be scaled by the value in the wiggle.
format: logoMaf <url/relativePath>
examples:
- logoMaf https://hgdownload.gi.ucsc.edu/goldenPath/hg38/multiz470way/multiz470way.bigMaf
- name: windowingFunction
types:
- wig
- bigWig
- bedGraph
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: full
required: false
summary: Depending upon how large of a genomic region is displayed in the Browser image, it may be necessary
to summarize the actual signal.
description: '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 data is shown using mean+whiskers display, though the maximum , mean , or minimum can alternatively
be displayed. The mean+whiskers setting displays the mean, max, and one standard deviation above the
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.
When zoomed out, this track will show the mean signal but include shading representing higher scores.
The user may change this setting.'
format: windowingFunction <mean/mean+whiskers/maximum/minimum>
examples:
- windowingFunction mean
- name: yLineMark
types:
- wig
- bigWig
- bedGraph
roles:
- leaf
category: bigWig - Signal Graphing Track Settings
context: trackDb
level: full
required: false
summary: It can be useful to draw a line across the track's signal graph at some fixed y coordinate.
description: 'It 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.
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.'
format: yLineMark <#>
examples:
- "yLineOnOff on\n yLineMark 2.5\n gridDefault on"
- name: bigLolly
types:
- bigLolly
roles:
- leaf
category: bigLolly - Lollipop charts
context: trackDb
level: null
required: false
summary: ''
description: ''
format: type bigLolly
examples: []
- name: lollyNoStems
types:
- bigLolly
roles:
- leaf
category: bigLolly - Lollipop charts
context: trackDb
level: full
required: false
summary: Draw the lollipop heads without the stems that normally connect them to the baseline.
description: 'Draw the lollipop heads without the stems that normally connect them to the baseline.
This setting was documented as noStems until August 2026. That spelling never worked, because the
Browser has always read lollyNoStems . A track using noStems draws its stems as usual.'
format: lollyNoStems <on/off>
examples:
- lollyNoStems on
- name: lollySizeField
types:
- bigLolly
roles:
- leaf
category: bigLolly - Lollipop charts
context: trackDb
level: full
required: false
summary: ''
description: ''
format: lollySizeField <integer>
examples: []
- name: lollyMaxSize
types:
- bigLolly
roles:
- leaf
category: bigLolly - Lollipop charts
context: trackDb
level: full
required: false
summary: ''
description: ''
format: lollyMaxSize <integer>
examples: []
- name: lollyField
types:
- bigLolly
roles:
- leaf
category: bigLolly - Lollipop charts
context: trackDb
level: full
required: false
summary: ''
description: ''
format: lollyField <integer>
examples: []
- name: yAxisLabel
types:
- bigLolly
roles:
- leaf
category: bigLolly - Lollipop charts
context: trackDb
level: full
required: false
summary: ''
description: ''
format: yAxisLabel.<integer> <integer> <on/off> <R,G,B> <string>
examples: []
- name: yAxisNumLabels
types:
- bigLolly
roles:
- leaf
category: bigLolly - Lollipop charts
context: trackDb
level: full
required: false
summary: ''
description: ''
format: yAxisNumLabels.<on/off> <integer>
examples: []
- name: hic
types:
- hic
roles:
- leaf
category: hic - Hi-C contact matrices
context: trackDb
level: null
required: false
summary: ''
description: ''
format: type hic
examples: []
- name: drawMode
types:
- hic
roles:
- leaf
category: hic - Hi-C contact matrices
context: trackDb
level: full
required: false
summary: This setting controls the default display mode for the hic track.
description: This setting controls the default display mode for the hic track. In arc mode, an interaction
between two regions is drawn as an arc between the centers of those two regions. In square mode, interactions
are represented by a square in a heatmap. The interacting regions for any square can be identified
by projecting the sides of the square onto the diagonal axis of the heatmap and seeing where those
points fall in the chromosome window being viewed. In triangle mode, interactions are drawn as diamonds.
The interaction regions for any diamond can be identified by projecting the sides of the diamond onto
the horizontal axis of the heatmap and seeing where those points fall in the chromosome window.
format: drawMode <triangle|square|arc>
examples: []
- name: normalization
types:
- hic
roles:
- leaf
category: hic - Hi-C contact matrices
context: trackDb
level: full
required: false
summary: This setting controls which method is the default for normalizing the raw scores from the .hic
file.
description: This setting controls which method is the default for normalizing the raw scores from the
.hic file. Scores for all of these methods are computed during the creation of the .hic file. For
more information on these methods, see the Juicer documentation linked above.
format: normalization <NONE|VC|VC_SQRT|KR>
examples: []
- name: resolution
types:
- hic
roles:
- leaf
category: hic - Hi-C contact matrices
context: trackDb
level: full
required: false
summary: This setting controls the default size of the bins that the Hi-C contact results are grouped
into.
description: This setting controls the default size of the bins that the Hi-C contact results are grouped
into. The list of available resolutions depends on the file, but common values include numbers like
5000 and 10000. In addition to an integer value, the string Auto can also be provided (Auto is also
the default if this setting is not specified). In Auto mode, the browser will dynamically choose a
resolution that seems to provide a good amount of detail depending on the size of the chromosome window
currently being viewed.
format: resolution <Auto|integer>
examples: []
- name: saturationScore
types:
- hic
roles:
- leaf
category: hic - Hi-C contact matrices
context: trackDb
level: full
required: false
summary: The saturationScore setting is part of how the color shades of the heatmap are displayed.
description: The saturationScore setting is part of how the color shades of the heatmap are displayed.
Colors in the heatmap correlate with the score of each interaction - a higher interaction score corresponds
to a higher color intensity. At some point, however, maximum color saturation is reached and higher
interaction scores don't change the color any further. This setting determines what the default score
is for the point at which that maximum color saturation is reached.
format: saturationScore <float>
examples: []
- name: hicDistanceMin
types:
- hic
roles:
- leaf
category: hic - Hi-C contact matrices
context: trackDb
level: new
required: false
summary: Hi-C tracks have a setting that controls the minimum interaction distance in nucleotides for
the heatmap.
description: Hi-C tracks have a setting that controls the minimum interaction distance in nucleotides
for the heatmap. If a portion of the heatmap represents an interaction closer than the value of the
minimum distance setting, that portion of the heatmap simply isn't drawn. This setting, hicDistanceMin,
controls the default value for that minimum (without this setting, the default is 0). A value of 0
means that no filter is applied.
format: hicDistanceMin <integer>
examples: []
- name: hicDistanceMax
types:
- hic
roles:
- leaf
category: hic - Hi-C contact matrices
context: trackDb
level: new
required: false
summary: Hi-C tracks have a setting that controls the maximum interaction distance in nucleotides for
the heatmap.
description: Hi-C tracks have a setting that controls the maximum interaction distance in nucleotides
for the heatmap. If a portion of the heatmap represents an interaction farther than the value of the
maximum distance setting, that portion of the heatmap simply isn't drawn. This setting, hicDistanceMax,
controls the default value for that maximum (without this setting, the default is 0). A value of 0
means that no filter is applied.
format: hicDistanceMax <integer>
examples: []
- name: hicArcLimit
types:
- hic
roles:
- leaf
category: hic - Hi-C contact matrices
context: trackDb
level: new
required: false
summary: The "arc" display mode for Hi-C tracks can become difficult to read if too many arcs are being
drawn, particularly if many of them have scores close to the s...
description: The "arc" display mode for Hi-C tracks can become difficult to read if too many arcs are
being drawn, particularly if many of them have scores close to the saturation score. This setting
can be used to restrict the display to only the N highest scoring arcs (it has no effect in other
display modes). The companion setting, hicArcLimitEnabled, controls whether this filter is applied
to the track by default or not. The default value for this setting is 10000.
format: hicArcLimit <integer>
examples: []
- name: hicArcLimitEnabled
types:
- hic
roles:
- leaf
category: hic - Hi-C contact matrices
context: trackDb
level: new
required: false
summary: The "arc" display mode for Hi-C tracks can become difficult to read if too many arcs are being
drawn, so there is an option to limit the display to the N hig...
description: The "arc" display mode for Hi-C tracks can become difficult to read if too many arcs are
being drawn, so there is an option to limit the display to the N highest scoring interactions. The
value of N is controlled by the companion setting, hicArcLimit, while this setting controls whether
the filter is automatically turned on when the track is loaded. The default value is true.
format: hicArcLimitEnabled <true|false>
examples: []
- name: halSnake
types:
- halSnake
roles:
- leaf
category: halSnake - Multiple Alignments
context: trackDb
level: null
required: false
summary: If the bigDataUrl setting is included, the data at the location specified by that URL will
be displayed.
description: If 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.
format: type halSnake
examples: []
- name: showSnpWidth
types:
- halSnake
roles:
- leaf
category: halSnake - Multiple Alignments
context: trackDb
level: full
required: false
summary: The maximum width (in bases) of a window where the halSnake will show SNPs between the reference
and the other species.
description: The maximum width (in bases) of a window where the halSnake will show SNPs between the
reference and the other species.
format: showSnpWidth < integer >
examples: []
- name: otherSpecies
types:
- halSnake
roles:
- leaf
category: halSnake - Multiple Alignments
context: trackDb
level: full
required: false
summary: The name of the other assembly in the pairwise alignment for this track.
description: 'The name of the other assembly in the pairwise alignment for this track.
The other species (other than the reference) in the alignment is the tweeter assembly in the same
HAL file.'
format: otherSpecies <otherSpecies>
examples:
- otherSpecies tweeter
- name: vcfTabix
types:
- vcfTabix
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: null
required: false
summary: If the bigDataUrl setting is included, the data at the location specified by that URL will
be displayed.
description: If 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.
format: type vcfTabix
examples: []
- name: hapClusterEnabled
types:
- vcf
- vcfTabix
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: full
required: false
summary: If the VCF file includes genotype columns for at least two individuals, then a haplotype sorting
display is enabled by default.
description: If the VCF file includes genotype columns for at least two individuals, then a haplotype
sorting display is enabled by default. This option can be used to disable it if desired, for example
if the genotypes have not been phased and a significant portion of the genotypes are heterozygous.
More information about the haplotype sorting display can be found on our Configuring VCF tracks page.
format: hapClusterEnabled <true|false>
examples: []
- name: hapClusterMethod
types:
- vcf
- vcfTabix
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: full
required: false
summary: 'Assuming hapClusterEnabled is true , this specifies how genotypes are ordered for display:
centerWeighted : For diploid organisms, this separates the two hap...'
description: 'Assuming hapClusterEnabled is true , this specifies how genotypes are ordered for display:
centerWeighted : For diploid organisms, this separates the two haplotypes from each sample and dynamically
clusters all haplotypes by similarity, weighted by proximity to a central variant. The clustering
tree will be drawn in the left label area. This works best for phased genotypes. fileOrder : Genotypes
are displayed in the order in which they appear in the VCF file. treeFile url : Genotypes are displayed
in the order in which they appear in url , a Newick -formatted tree file whose leaf node IDs are the
same as the genotype column IDs in the VCF file. The tree will be drawn in the left label area.
- centerWeighted : For diploid organisms, this separates the two haplotypes from each sample and dynamically
clusters all haplotypes by similarity, weighted by proximity to a central variant. The clustering
tree will be drawn in the left label area. This works best for phased genotypes. fileOrder : Genotypes
are displayed in the order in which they appear in the VCF file. treeFile url : Genotypes are displayed
in the order in which they appear in url , a Newick -formatted tree file whose leaf node IDs are the
same as the genotype column IDs in the VCF file. The tree will be drawn in the left label area.
- fileOrder : Genotypes are displayed in the order in which they appear in the VCF file. treeFile
url : Genotypes are displayed in the order in which they appear in url , a Newick -formatted tree
file whose leaf node IDs are the same as the genotype column IDs in the VCF file. The tree will be
drawn in the left label area.
- treeFile url : Genotypes are displayed in the order in which they appear in url , a Newick -formatted
tree file whose leaf node IDs are the same as the genotype column IDs in the VCF file. The tree will
be drawn in the left label area.'
format: hapClusterMethod <centerWeighted|fileOrder|treeFile url >
examples: []
- name: sampleColorFile
types:
- vcf
- vcfTabix
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: new
required: false
summary: Colors the haplotype clustering tree that hapClusterMethod treeFile draws in the left label
area.
description: 'Colors the haplotype clustering tree that hapClusterMethod treeFile draws in the left
label area. The file is tab-separated: a sample name in the first column, matching a genotype column
ID in the VCF file, and a color in the second. The color may be a color name, a # -prefixed six-digit
hex code, or comma-separated red, green and blue values from 0 to 255. Samples the file does not name
are drawn black.
Several colorings can be offered at once. Give a space-separated list of label = url pairs and the
track configuration page adds a drop-down to choose among them, displaying an underscore in a label
as a space. The drop-down appears only while hapClusterMethod is set to treeFile , and the first file
in the list is the one used until the user picks another.'
format: sampleColorFile <url>
examples:
- "HG00096\t#1f77b4\nHG00099\tsteelblue\nNA18939\t255,127,14"
- "track myVcf\n type vcfTabix\n bigDataUrl /path/to/myVcf.vcf.gz\n hapClusterMethod treeFile\
\ /path/to/tree.nwk\n sampleColorFile Population=/path/to/byPop.txt Sequencing_center=/path/to/byCenter.txt\n\
\ ..."
- name: hapClusterColorBy
types:
- vcf
- vcfTabix
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: full
required: false
summary: 'Assuming hapClusterEnabled is true , this specifies one of three ways that reference and alternate
alleles are colored: altOnly : reference allele is white (...'
description: 'Assuming hapClusterEnabled is true , this specifies one of three ways that reference and
alternate alleles are colored: altOnly : reference allele is white (invisible), alternate allele is
black. This emphasizes haplotypes with alternate alleles. (default) function : If the geneTrack setting
is also provided, then reference allele is white (invisible) and alternate allele is red if the variant
changes the protein sequence of a gene, green if the variant falls within a gene but does not change
the protein sequence, blue if the variant falls within the UTR of a protein-coding gene or within
a non-coding gene, and black if intronic or intergenic. refAlt : reference allele is blue, alternate
allele is red. base : A is red, C is blue, G is green and T is magenta.
- altOnly : reference allele is white (invisible), alternate allele is black. This emphasizes haplotypes
with alternate alleles. (default) function : If the geneTrack setting is also provided, then reference
allele is white (invisible) and alternate allele is red if the variant changes the protein sequence
of a gene, green if the variant falls within a gene but does not change the protein sequence, blue
if the variant falls within the UTR of a protein-coding gene or within a non-coding gene, and black
if intronic or intergenic. refAlt : reference allele is blue, alternate allele is red. base : A is
red, C is blue, G is green and T is magenta.
- function : If the geneTrack setting is also provided, then reference allele is white (invisible)
and alternate allele is red if the variant changes the protein sequence of a gene, green if the variant
falls within a gene but does not change the protein sequence, blue if the variant falls within the
UTR of a protein-coding gene or within a non-coding gene, and black if intronic or intergenic. refAlt
: reference allele is blue, alternate allele is red. base : A is red, C is blue, G is green and T
is magenta.
- refAlt : reference allele is blue, alternate allele is red. base : A is red, C is blue, G is green
and T is magenta.
- base : A is red, C is blue, G is green and T is magenta.'
format: hapClusterColorBy <altOnly|function|refAlt|base>
examples: []
- name: geneTrack
types:
- vcf
- vcfTabix
- vcfPhasedTrio
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: full
required: false
summary: This is for use with hapClusterColorBy function ; it specifies the gene track to use when determining
the functional effect of each variant.
description: This is for use with hapClusterColorBy function ; it specifies the gene track to use when
determining the functional effect of each variant.
format: geneTrack < track >
examples: []
- name: hapClusterTreeAngle
types:
- vcf
- vcfTabix
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: full
required: false
summary: Assuming hapClusterEnabled is true , this controls the shape of leaf clusters on the right
of the tree (i.e.
description: 'Assuming hapClusterEnabled is true , this controls the shape of leaf clusters on the right
of the tree (i.e. the lines drawn to denote groups of identical local haplotypes): triangle for the
< shape (default), rectangle for the [ shape.'
format: hapClusterTreeAngle <triangle|rectangle>
examples: []
- name: hapClusterHeight
types:
- vcf
- vcfTabix
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: full
required: false
summary: Assuming hapClusterEnabled is true , this specifies the height in pixels of the haplotype sorting
display.
description: Assuming hapClusterEnabled is true , this specifies the height in pixels of the haplotype
sorting display.
format: hapClusterHeight < N >
examples: []
- name: applyMinQual
types:
- vcf
- vcfTabix
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: full
required: false
summary: If true , then variants whose QUAL column contains a value less than the minQual setting will
not be displayed.
description: If true , then variants whose QUAL column contains a value less than the minQual setting
will not be displayed.
format: applyMinQual <true|false>
examples: []
- name: minQual
types:
- vcf
- vcfTabix
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: full
required: false
summary: Assuming applyMinQual is true , this is the minimum QUAL value required for a variant to be
displayed.
description: 'Assuming applyMinQual is true , this is the minimum QUAL value required for a variant
to be displayed.
Assuming applyMinQual is true , this is the minimum QUAL value required for a variant to be displayed.'
format: minQual < Q >
examples: []
- name: minFreq
types:
- vcf
- vcfTabix
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: full
required: false
summary: The minimum minor allele frequency required for a variant to be displayed.
description: The minimum minor allele frequency required for a variant to be displayed. By default this
is 0.0 (i.e. display all variants).
format: minFreq < F >
examples: []
- name: minAc
types:
- vcf
- vcfTabix
- vcfPhasedTrio
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: new
required: false
summary: The minimum alternate allele count required for a variant to be displayed, taken from the AC
field of the INFO column.
description: The minimum alternate allele count required for a variant to be displayed, taken from the
AC field of the INFO column. Variants whose INFO has no usable AC are always displayed. By default
this is 0 (i.e. display all variants).
format: minAc < N >
examples: []
- name: vcfDoFilter
types:
- vcf
- vcfTabix
- vcfPhasedTrio
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: full
required: false
summary: Turn on/off the FILTER options available by default for VCF tracks
description: Turn on/off the FILTER options available by default for VCF tracks
format: vcfDoFilter <on/off>
examples: []
- name: vcfDoQual
types:
- vcf
- vcfTabix
- vcfPhasedTrio
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: full
required: false
summary: Turns on/off the QUAL filter options available by default for VCF tracks
description: Turns on/off the QUAL filter options available by default for VCF tracks
format: vcfDoQual <on/off>
examples: []
- name: vcfDoMaf
types:
- vcf
- vcfTabix
- vcfPhasedTrio
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: full
required: false
summary: Turns on/off the Minor Allele Frequency filter options available by default for VCF tracks
description: Turns on/off the Minor Allele Frequency filter options available by default for VCF tracks
format: vcfDoMaf <on/off>
examples: []
- name: vcfDoMinAc
types:
- vcf
- vcfTabix
- vcfPhasedTrio
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: new
required: false
summary: Turns on/off the minimum allele count filter option available by default for VCF tracks
description: Turns on/off the minimum allele count filter option available by default for VCF tracks
format: vcfDoMinAc <on/off>
examples: []
- name: sampleMetadataFile
types:
- vcf
- vcfTabix
- vcfPhasedTrio
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: new
required: false
summary: Specifies a tab-separated file that provides metadata columns for VCF samples.
description: 'Specifies a tab-separated file that provides metadata columns for VCF samples. (Meta data
can always be provided in the VCF file directly, but this option allows storing the metadata in an
external file.) When a user clicks on a variant, the metadata columns from this file are appended
to the genotype details table. The first line is a header that starts with #sample , followed by tab-separated
column names for the metadata fields. Subsequent lines contain the sample name in the first column
(matching the VCF genotype column IDs), followed by the metadata values.'
format: sampleMetadataFile <url>
examples:
- "#sample\tPopulation\tSuperpopulation\tRegion\nHG00096\tGBR\tEUR\tEurope\nHG00099\tGBR\tEUR\tEurope\n\
NA18939\tJPT\tEAS\tEast Asia"
- "track myVcf\n type vcfTabix\n bigDataUrl /path/to/myVcf.vcf.gz\n sampleMetadataFile /path/to/sampleMeta.txt\n\
\ ..."
- name: showHardyWeinberg
types:
- vcf
- vcfTabix
- vcfPhasedTrio
roles:
- leaf
category: vcfTabix - Variant Call Format Track Settings
context: trackDb
level: new
required: false
summary: When a user clicks on a variant with exactly two alleles, adds a line to the details page giving
the genotype frequencies that Hardy-Weinberg equilibrium pre...
description: When a user clicks on a variant with exactly two alleles, adds a line to the details page
giving the genotype frequencies that Hardy-Weinberg equilibrium predicts from the observed allele
frequencies. Off by default. There is no control for this on the track configuration page; it is set
in trackDb.
format: showHardyWeinberg <on/off>
examples: []
- name: vcfPhasedTrio
types:
- vcfPhasedTrio
roles:
- leaf
category: vcfPhasedTrio - Variant Call Format Track Settings
context: trackDb
level: null
required: false
summary: There are no extra options that can appear on the type vcfPhasedTrio line.
description: There are no extra options that can appear on the type vcfPhasedTrio line.
format: type vcfPhasedTrio
examples: []
- name: vcfChildSample
types:
- vcfPhasedTrio
roles:
- leaf
category: vcfPhasedTrio - Variant Call Format Track Settings
context: trackDb
level: full
required: false
summary: The VCF Genotype column ID of the "child" sample, followed optionally by a "|" character and
an alias for the display.
description: The VCF Genotype column ID of the "child" sample, followed optionally by a "|" character
and an alias for the display. This sample will become the center haplotype if parents are also specified.
format: vcfChildSample <sampleName|altName>
examples: []
- name: vcfParentSamples
types:
- vcfPhasedTrio
roles:
- leaf
category: vcfPhasedTrio - Variant Call Format Track Settings
context: trackDb
level: full
required: false
summary: A comma separated (no spaces) list of the VCF Genotype column IDs of the "parents", followed
optionally by a "|" character and an alias for the display.
description: A comma separated (no spaces) list of the VCF Genotype column IDs of the "parents", followed
optionally by a "|" character and an alias for the display. This setting is optinonal, and supports
one or both parents.
format: vcfParentSamples <sampleName|altName,sampleName|altName>
examples: []
- name: vcfUseAltSampleNames
types:
- vcfPhasedTrio
roles:
- leaf
category: vcfPhasedTrio - Variant Call Format Track Settings
context: trackDb
level: full
required: false
summary: Make the display use the aliases as the default labels for each haplotype lane instead of the
ID from the VCF.
description: Make the display use the aliases as the default labels for each haplotype lane instead
of the ID from the VCF.
format: vcfUseAltSampleNames <on/off>
examples: []
- name: vcfPhasedColorBy
types:
- vcfPhasedTrio
roles:
- leaf
category: vcfPhasedTrio - Variant Call Format Track Settings
context: trackDb
level: new
required: false
summary: How to color the variants drawn on each haplotype lane.
description: How to color the variants drawn on each haplotype lane. noColor , the default, draws them
all black. deNovo colors a child variant red when it appears in neither parent. mendelDiff colors
a child variant red when it disagrees with the allele the parents imply was transmitted; this needs
vcfParentSamples to be set. function colors by predicted effect on the gene, red for non-synonymous,
green for synonymous, blue for UTR or noncoding, and black otherwise; it is offered only when geneTrack
is also set.
format: vcfPhasedColorBy <noColor|function|deNovo|mendelDiff>
examples: []
- name: superTrack
types:
- superTrack
roles:
- super
category: superTrack - Folder Track Settings
context: trackDb
level: base
required: false
summary: To declare a supertrack, simply add this setting to a track definition that will hold a few
standard settings.
description: 'To 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. To have the supertrack not display by default use only superTrack
on . It may help to think of the original declaring supertrack stanza as a light switch that by default
is off, and can be flipped on by adding show .
All tracks that claim membership to the supertrack should set their own visibilities in lower stanzas
by declaring settings such as parent superTrack1 and also by having a separate visibility dense line.
If no visibility setting is defined for a track, the default setting of hide is assigned. This can
cause confusion if one mistakenly tries to set visibilities only at the top supertack stanza, not
allowed, and leaves them out for each child.
Do not confuse the parent line with how it is used in composites. For example, in supertracks DO NOT
follow the example of parent superTrack1 [off/on] , where [off/on] will only work with composite tracks.
When attempting to debug visibility settings, it may be helpful to read the note about inheritance
found below.'
format: superTrack on show
examples: []
- name: parent_supertrack
types:
- superTrack
roles:
- super
category: superTrack - Folder Track Settings
context: trackDb
level: base
required: false
summary: Membership in a supertrack, composite, or aggregate track is declared by the child, not the
supertrack itself with a line such as parent superTrack1 .
description: 'Membership in a supertrack, composite, or aggregate track is declared by the child, not
the supertrack itself with a line such as parent superTrack1 .
Do not confuse the parent line with how it is used in composites. For example, in supertracks DO NOT
follow the example of parent compositeTrack1 [off/on] , which will only work with composite tracks.
Any number of children may belong to one supertrack, but ten is a suggested 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.
All tracks that claim membership to the supertrack should set their own visibilities in lower stanzas
by declaring separate settings such as visibility dense .When attempting to debug visibility settings,
it may be helpful to read the note about inheritance found below.'
format: parent <superTrack>
examples: []
- name: parent
types:
- compositeTrack
roles:
- composite
category: Composite Track Settings
context: trackDb
level: base
required: false
summary: Membership in a composite is declared by the subtrack child, not the composite itself, through
this setting.
description: 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. Visibility settings in composite subtracks
are directly inherited from the parent. Therefore, any visibility lines added at the child subtrack
level of a composite will be ignored.
format: parent <composite> [off/on]
examples: []
- name: compositeTrack
types:
- compositeTrack
roles:
- composite
category: Composite Track Settings
context: trackDb
level: base
required: false
summary: To declare a composite, simply add this setting to a track definition, along with a few standard
settings.
description: To 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.
format: compositeTrack on
examples: []
- name: allButtonPair
types:
- compositeTrack
roles:
- composite
category: Composite Track Settings
context: trackDb
level: full
required: false
summary: When 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.
description: When 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).
format: allButtonPair on
examples: []
- name: centerLabelsDense
types:
- compositeTrack
roles:
- composite
category: Composite Track Settings
context: trackDb
level: full
required: false
summary: By default, only the composite track's single center label is shown when the subtracks are
displayed together in the Browser dense mode.
description: 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.
format: centerLabelsDense <off/on>
examples: []
- name: dragAndDrop
types:
- compositeTrack
roles:
- composite
category: Composite Track Settings
context: trackDb
level: full
required: false
summary: When you have many subtracks in a composite track, it may be useful on the Track Setting page,
also known as the hgTrackUi configuration page, to rearrange t...
description: 'When you have many subtracks in a composite track, it may be useful on the Track Setting
page, also known as the hgTrackUi configuration page, to rearrange the subtracks. One avenue of rearranging
many subtracks is to employ the sortOrder setting, as described below, or by allowing the user to
drag and drop the subtracks to a new order on the Track Setting page. The dragAndDrop subTracks setting
will enable dragging by clicking on the check mark next to the subtrack on the configuration page.
Tracks can thereby be rearranged into a final desired order, that will then be seen when browsing
the tracks. However, the order of tracks can also be rearranged on the hgTracks Browser image by directly
dragging and dropping the displayed track data. Yet reordering subtracks in the Browser image in hgTracks
will not be reflected back on the hgTrackUi configuration page. Note: This setting will not work correctly
if ''container multiWig'' is specified.'
format: dragAndDrop subTracks
examples: []
- name: hideEmptySubtracks
types:
- compositeTrack
roles:
- composite
category: Composite Track Settings
context: trackDb
level: full
required: false
summary: When you have many subtracks in a composite track, it may be useful to limit the display to
only those with data in the current viewing window.
description: When you have many subtracks in a composite track, it may be useful to limit the display
to only those with data in the current viewing window. This track setting produces a checkbox on the
track configuration page allowing the user to enable or disable this feature. if on is specified,
the feature is on by default (the checkbox is checked).
format: hideEmptySubtracks <on/off>
examples: []
- name: hideEmptySubtracksMultiBedUrl
types:
- compositeTrack
roles:
- composite
category: Composite Track Settings
context: trackDb
level: full
required: false
summary: For large composites, especially those where each subtrack may be sparse, substantial performance
improvements can be gained by creating an index file of the...
description: 'For large composites, especially those where each subtrack may be sparse, substantial
performance improvements can be gained by creating an index file of the intersections of items in
all subtracks ("multiBed"). This file, and an accompanying sources file, are optional settings for
the hideEmptySubtracks feature. Instructions for creating these files are at the MultiBed help page
(TBD).
NOTE: These settings are required to use the hideEmptySubtracks feature with multi-view composites.'
format: hideEmptySubtracksMultiBedUrl file.bb
examples: []
- name: hideEmptySubtracksSourcesUrl
types:
- compositeTrack
roles:
- composite
category: Composite Track Settings
context: trackDb
level: full
required: false
summary: This setting is used in conjunction with the hideEmptySubtracksMultiBedUrl setting, described
above.
description: This setting is used in conjunction with the hideEmptySubtracksMultiBedUrl setting, described
above.
format: hideEmptySubtracksSourcesUrl file.tab
examples: []
- name: hideEmptySubtracksLabel
types:
- compositeTrack
roles:
- composite
category: Composite Track Settings
context: trackDb
level: full
required: false
summary: This setting is used in conjunction with the hideEmptySubtracks setting to customize the label
preceding the selection checkbox on the track configuration page.
description: This setting is used in conjunction with the hideEmptySubtracks setting to customize the
label preceding the selection checkbox on the track configuration page. Default wording is "Hide empty
subtracks". Custom wording is useful to distinguish affected tracks in multi-view composites (e.g.
"Hide empty Peaks subtracks").
format: hideEmptySubtracksLabel <label>
examples: []
- name: subGroupN
types:
- subGroups
roles:
- composite
category: Composite - Subgroups Settings
context: trackDb
level: base
required: false
summary: Up to 9 subgroups may be declared, one per line.
description: '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, not contain a period, 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.'
format: "subGroup1 <gTag1> <gTitle1> <mTag1a=mTitle1a>\n [mTag1b=mTitle1b...]"
examples: []
- name: subGroups
types:
- subGroups
roles:
- composite
category: Composite - Subgroups Settings
context: trackDb
level: base
required: false
summary: The subtracks themselves declare their membership in a group with the subGroups setting.
description: '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).'
format: subGroups <gTag1=mTag1?> [gTag2= mTag2?]
examples: []
- name: dimensions
types:
- subGroups
roles:
- composite
category: Composite - Subgroups Settings
context: trackDb
level: base
required: false
summary: In order to define the type of UI desired for selecting subtracks based upon groups, additional
settings are needed at the composite level.
description: '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. Please also note
that if a hub is not going to use the X,Y matrix, dimX should be the first dimension defined rather
than dimA. Also, the setting allButtonPair on will prevent the matrix from displaying.'
format: dimensions <dimX=gTag#> [dimY=gTag#] [dimA=gTag# ...]
examples: []
- name: filterComposite
types:
- subGroups
roles:
- composite
category: Composite - Subgroups Settings
context: trackDb
level: full
required: false
summary: For the "abc" dimensions, rows of checkboxes will be shown by default.
description: '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. Please note that if a hub is not going to use
the X,Y matrix, then dimX should be the first dimension defined rather than dimA.'
format: filterComposite <dim[A/B/C][=one]> [dimB dimC ...]
examples: []
- name: dimensionAchecked
types:
- subGroups
roles:
- composite
category: Composite - Subgroups Settings
context: trackDb
level: full
required: false
summary: One more complication in the selection process is determining which subgroup options are selected
by default.
description: 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.
format: "dimension<?>checked <mTag1a>\n [mTag1b ...]"
examples: []
- name: sortOrder
types:
- subGroups
roles:
- composite
category: Composite - Subgroups Settings
context: trackDb
level: full
required: false
summary: When declaring subgroups, it is often useful to sort the subtrack list by those subgroups.
description: 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.
format: sortOrder <gTag#=+/-> [gTag#=- ...]
examples: []
- name: view
types:
- view
roles:
- view
category: Composite - Views Settings
context: trackDb
level: base
required: false
summary: A view is always declared both as a subgroup and in a track stanza itself.
description: 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.
format: subGroup1 view <Views> <vTag1a=vTitle1a> [vTag1b=vTitle1b...]
examples: []
- name: parent_view
types:
- view
roles:
- view
category: Composite - Views Settings
context: trackDb
level: base
required: false
summary: A subtrack declares its membership in a view both as subgroup membership and with a parent
setting that refers to the view track name.
description: 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.
format: subGroups view=<vTag1>...
examples: []
- name: viewUi
types:
- view
roles:
- view
category: Composite - Views Settings
context: trackDb
level: full
required: false
summary: If 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.
description: If 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.
format: viewUi on
examples: []
- name: configurable
types:
- view
- composite
roles:
- view
category: Composite - Views Settings
context: trackDb
level: full
required: false
summary: 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.
description: 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.
format: configurable <off/on>
examples: []
- name: faceted
types:
- faceted
- composite
roles:
- composite
category: Faceted Composite Settings
context: trackDb
level: null
required: false
summary: This version of the compositeTrack setting indicates that the UI for this composite track should
be handled with facets.
description: 'This version of the compositeTrack setting indicates that the UI for this composite track
should be handled with facets.
A faceted composite also treats its own visibility as a maximum for its subtracks rather than a value
they inherit, so one container can hold tracks that each want a different display mode. See onlyVisibility
for how a subtrack picks its own mode within that maximum.'
format: compositeTrack faceted
examples: []
- name: metaDataUrl
types:
- faceted
- composite
roles:
- composite
category: Faceted Composite Settings
context: trackDb
level: new
required: false
summary: The URL here points to the tsv file that provides facet information.
description: 'The URL here points to the tsv file that provides facet information. This setting is required
for faceted composite tracks. The first row of the tsv file contains the field names; subsequent rows
provide the metadata for each sample. Example: accession group cell_type DRX118406 CellLine iPSC DRX118407
CellLine iPSC DRX118408 CellLine iMeLC'
format: metaDataUrl <url>
examples:
- 'accession group cell_type
DRX118406 CellLine iPSC
DRX118407 CellLine iPSC
DRX118408 CellLine iMeLC'
- name: primaryKey
types:
- faceted
- composite
roles:
- composite
category: Faceted Composite Settings
context: trackDb
level: new
required: false
summary: This setting is required and works in tandem with the file specified in the metaDataUrl setting.
description: This setting is required and works in tandem with the file specified in the metaDataUrl
setting. The named field will be used as a primary key for the metadata table, and those values will
be used to identify subtracks.
format: primaryKey <field>
examples: []
- name: maxCheckboxes
types:
- faceted
- composite
roles:
- composite
category: Faceted Composite Settings
context: trackDb
level: new
required: false
summary: Frequently a facet may have a long list of possible values - too many to display at once in
the track selection interface.
description: Frequently a facet may have a long list of possible values - too many to display at once
in the track selection interface. This setting limits the number of facet values displayed on the
left to the N most common, where N is the value of this setting. The default value is 20.
format: maxCheckboxes <integer>
examples: []
- name: dataTypes
types:
- faceted
- composite
roles:
- composite
category: Faceted Composite Settings
context: trackDb
level: new
required: false
summary: This optional setting identifies a list of datatypes available for each sample in the metadata
file (one sample per row).
description: This optional setting identifies a list of datatypes available for each sample in the metadata
file (one sample per row). Each datatype is identified by a name, which is combined with the name
of the parent track and a primary key to form track names as described above. Spaces cannot be used
in data type names; instead, spaces separate the various data types. If present, the table title after
the | character will be used as the display name for that data type in the track UI. Titles can incorporate
spaces if they are enclosed in quotes.
format: dataTypes <name1(|"table title") name2(|"table title") ...>
examples:
- dataTypes sig|"Raw signal" peak|Peaks
- name: defaultSortField
types:
- faceted
- composite
roles:
- composite
category: Faceted Composite Settings
context: trackDb
level: new
required: false
summary: This optional setting chooses which field in the metadata table will be used to sort the table
of subtracks when the page is first loaded.
description: This optional setting chooses which field in the metadata table will be used to sort the
table of subtracks when the page is first loaded. The name should match the field name in the first
line of the metadata tsv file. If there is no match, or if this setting is absent, the first field
in the metadata tsv file is used as the default sort field.
format: defaultSortField <name>
examples:
- defaultSortField tissue
- name: subtrackUrls
types:
- faceted
- composite
roles:
- composite
category: Faceted Composite Settings
context: trackDb
level: new
required: false
summary: For some faceted composites, each subtrack is associated with a particular cell line or other
accession that is described in more detail at another resource...
description: For some faceted composites, each subtrack is associated with a particular cell line or
other accession that is described in more detail at another resource (e.g. ENCODE or SRA). This optional
setting specifies remote URLs for linking out to those resources. When it is set, the names in the
columns from the metadata TSV file whose field names match this setting will be turned into hyperlinks
to the corresponding resources. If a URL includes the string '$$', it will be dynamically replaced
with the identifier from that column.
format: subtrackUrls <field1>=<url1> <field2>=<url2> ...
examples:
- subtrackUrls accession=https://www.ncbi.nlm.nih.gov/sra/$$ project=https://www.ncbi.nlm.nih.gov/bioproject/$$
- name: container
types:
- container
- multiWig
roles:
- composite
- view
- leaf
category: Aggregate or Overlay Track Settings
context: trackDb
level: full
required: false
summary: Signal overlay tracks are declared much like simple composites.
description: Signal 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.
format: container multiWig
examples: []
- name: parent_container
types:
- container
- multiWig
roles:
- composite
- view
- leaf
category: Aggregate or Overlay Track Settings
context: trackDb
level: base
required: false
summary: Membership in a container track is declared at the subtrack level.
description: Membership in a container track is declared at the subtrack level. The subtracks should
be defined with indent beneath their container parent.
format: parent <containerTrack>
examples: []
- name: aggregate
types:
- container
- multiWig
roles:
- composite
- view
- leaf
category: Aggregate or Overlay Track Settings
context: trackDb
level: full
required: false
summary: It is important to declare an aggregation method; otherwise, this set of tracks displays as
a composite would, with additional restrictions.
description: 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.
format: aggregate <transparentOverlay/stacked/solidOverlay/none>
examples: []
- name: showSubtrackColorOnUi
types:
- container
- multiWig
roles:
- composite
- view
- leaf
category: Aggregate or Overlay Track Settings
context: trackDb
level: full
required: false
summary: Subtracks in an overlay have individual colors.
description: Subtracks in an overlay have individual colors. Use this setting to show the color associated
with each on the track configuration page.
format: showSubtrackColorOnUi on
examples: []
- name: hub
types:
- all
roles:
- hub
category: general hub file settings
context: hub
level: base
required: false
summary: A short, unique identifier for the hub used internally by the Genome Browser software to identify
your hub.
description: A short, unique identifier for the hub used internally by the Genome Browser software to
identify your hub. It must not contain any spaces.
format: hub <str>
examples:
- hub myRnaSeqData
- name: hubShortLabel
types:
- all
roles:
- hub
category: general hub file settings
context: hub
level: base
required: false
summary: A short description of the hub.
description: A short description of the hub. Used as track group label below the main Genome Browser
image. Should be under 20 characters.
format: shortLabel <str>
examples:
- shortLabel ENCODE3 RNA-seq Data
- name: hubLongLabel
types:
- all
roles:
- hub
category: general hub file settings
context: hub
level: base
required: false
summary: A longer, more descriptive label for the hub.
description: A longer, more descriptive label for the hub. Should be under 70 characters long.
format: longLabel <str>
examples:
- longLabel Comment describing this hub contents
- name: genomesFile
types:
- all
roles:
- hub
category: general hub file settings
context: hub
level: base
required: false
summary: References the next definition file in this hub that will describe the assemblies and tracks
available at this hub.
description: 'References the next definition file in this hub that will describe the assemblies and
tracks available at this hub. Typically, genomes.txt is at the same directory level as this hub.txt;
however, it can also be a relative path reference to a different directory level.
Not needed if using useOneFile (recommended).'
format: genomesFile <url/relativePath>
examples:
- genomesFile genomes.txt
- name: email
types:
- all
roles:
- hub
category: general hub file settings
context: hub
level: base
required: false
summary: Provides users with a contact point for questions related to the hub.
description: Provides users with a contact point for questions related to the hub.
format: email <email address>
examples:
- email contactEmail@institution.edu
- name: descriptionUrl
types:
- all
roles:
- hub
category: general hub file settings
context: hub
level: base
required: false
summary: Specify a relative path or URL link to a webpage (e.g.
description: Specify a relative path or URL link to a webpage (e.g. a paper) describing the hub. For
public hubs, this can be used to highlight key words to make searching easier and direct users to
your hub.
format: descriptionUrl <url/relativePath>
examples:
- descriptionUrl castorBeanHubDescription.html
- name: useOneFile
types:
- all
roles:
- hub
category: general hub file settings
context: hub
level: base
required: false
summary: If the hub only has tracks on a single genome, useOneFile allows all hub and track configuration
settings to be in a single file.
description: If the hub only has tracks on a single genome, useOneFile allows all hub and track configuration
settings to be in a single file. See our documentation for more details.
format: useOneFile <on>
examples:
- useOneFile on
- name: hubGenome
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: For hubs on native assemblies, use the UCSC database name (e.g.
description: 'For hubs on native assemblies, use the UCSC database name (e.g. hg38). Genome assemblies
in our GenArk Repository can be referenced using their GCA_NNN or GCA_NNN identifier (e.g. GCF_000891275.1).
If an assembly is not available in GenArk, request it .
For custom assemblies, create your own name. This will appear on title pages in the Genome Browser.'
format: genome <str>
examples:
- genome ricCom1
- name: trackDbFile
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Relative path or URL to the file that defines the tracks for the assembly specified by the
genome setting.
description: 'Relative path or URL to the file that defines the tracks for the assembly specified by
the genome setting.
Not necessary if using the useOneFile setting (recommended).'
format: trackDb <url/relativePath>
examples:
- trackDb ricCom1/trackDb.txt
- name: groupsFile
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Relative path or URL that points to a file defining track groups, which are collections of
related tracks displayed together under the main Genome Browser im...
description: 'Relative path or URL that points to a file defining track groups, which are collections
of related tracks displayed together under the main Genome Browser image.
See our assembly hub groups.txt documentation for format details.'
format: groups <url/relativePath>
examples:
- groups ricCom1/groups.txt
- name: description
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Description of the assembly version that is displayed on the Gateway page and title pages for
this assembly.
description: Description of the assembly version that is displayed on the Gateway page and title pages
for this assembly. It also appears in the assembly pull-down menu.
format: description <str>
examples:
- description July 2011 Castor bean
- name: twoBitPath
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Relative path or URL to the .2bit sequence file for the assembly.
description: Relative path or URL to the .2bit sequence file for the assembly. This file is typically
generated from FASTA files using the faToTwoBit command-line program, available from our download
server .
format: twoBitPath <url/relativePath>
examples:
- twoBitPath ricCom1/ricCom1.2bit
- name: chromAlias
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Enables the Genome Browser to automatically convert chromosome names in submitted custom track
data from alternate naming schemes to the names used in the as...
description: 'Enables the Genome Browser to automatically convert chromosome names in submitted custom
track data from alternate naming schemes to the names used in the assembly. This functionality applies
to both custom track data and assembly hub data.
See our chromAlias documentation for details on the required file format.'
format: chromAlias <url/relativePath>
examples:
- chromAlias thisGenome.chromAlias.txt
- name: chromAliasBb
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Like chromAlias , except the file is in the compressed, binary bigBed format.
description: 'Like chromAlias , except the file is in the compressed, binary bigBed format. This allows
efficient searching for sequence names without requiring the entire text file to be read, which is
important for assemblies with a large number of sequences.
See our chromAlias documentation for details on the required file format.'
format: chromAliasBb <url/relativePath>
examples:
- chromAliasBb thisGenome.chromAlias.bb
- name: chromSizes
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Defines a file to be used when displaying the sequences contained in an assembly.
description: Defines a file to be used when displaying the sequences contained in an assembly. These
are visible from the "View Sequences" link on the Gateway page, or with the "vs" keyboard shortcut
when looking at the main Genome Browser image.
format: chromSizes <url/relativePath>
examples:
- chromSizes thisGenome.chromSizes.txt
- name: chromAuthority
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Indicates which chromosome naming scheme from the chromAlias file to be used as the default
in the Genome Browser display.
description: Indicates which chromosome naming scheme from the chromAlias file to be used as the default
in the Genome Browser display. The string must match a name defined in the chromAlias header.
format: chromAuthority <str>
examples:
- chromAuthority ucsc
- name: codonTable
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: new
required: false
summary: By default the Genome Browser translates codons to amino acids with the standard genetic code,
except for sequences named chrM or chrMT , which use the verte...
description: 'By default the Genome Browser translates codons to amino acids with the standard genetic
code, except for sequences named chrM or chrMT , which use the vertebrate mitochondrial code. An assembly
hub can assign a different NCBI genetic code to individual sequences with the codonTable setting in
the genome stanza.
The value is a space-separated list of sequenceName=id pairs, where id is an NCBI translation table
number (for example 1 for the standard code, 2 for vertebrate mitochondrial, 13 for ascidian mitochondrial).
The special name default sets the code used for any sequence not listed. Sequences with no assignment
keep the default behavior described above. This affects amino acid display in the base position track''s
three-frame translation, in codon-colored annotation tracks such as gene predictions, and on the details
pages.
Note : sequenceName must be the sequence''s own name as stored in the assembly''s .2bit file (the
same name used in chrom.sizes ), for example a RefSeq or GenBank accession such as NC_017929.1 . This
is the internal name even when a chromAlias and chromAuthority cause a different name (such as chrM
) to be displayed. Because the special chrM / chrMT mitochondrial default only applies to sequences
whose own name is literally chrM or chrMT , an assembly whose mitochondrial sequence has an accession
name needs an explicit codonTable entry to translate it with a mitochondrial code.
See our assembly hub codonTable documentation for more details.'
format: codonTable default=<id> <sequenceName>=<id> ...
examples:
- codonTable default=1 NC_017929.1=13
- name: organism
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Common name of the organism, displayed alongside the description on title pages.
description: Common name of the organism, displayed alongside the description on title pages. It also
appears in the assembly pull-down menu.
format: organism <str>
examples:
- organism Orangutan
- name: defaultPos
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Defines the initial view in the Genome Browser, usually highlighting a popular gene or region
of interest.
description: Defines the initial view in the Genome Browser, usually highlighting a popular gene or
region of interest.
format: defaultPos <chr:start-end>
examples:
- defaultPos chr7:155799529-155812871
- name: orderKey
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Controls the ordering of assemblies in the pull-down menu.
description: Controls the ordering of assemblies in the pull-down menu. Useful if you have several assemblies
in your hub.
format: orderKey <int>
examples:
- orderKey 4800
- name: scientificName
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Scientific name of organism, displayed alongside the description on title pages.
description: Scientific name of organism, displayed alongside the description on title pages. It also
appears in the assembly pull-down menu.
format: scientificName <str>
examples:
- scientificName Ricinus communis
- name: htmlPath
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Points to an HTML file with assembly information.
description: Points to an HTML file with assembly information. The HTML file is displayed on the Gateway
page.
format: htmlPath <url/relativePath>
examples:
- htmlPath ricCom1/description.html
- name: transBlat
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Indicates the server and port to be used for the "translated DNA/RNA" options in the BLAT interface.
description: Indicates the server and port to be used for the "translated DNA/RNA" options in the BLAT
interface. See our documentation for more details about setting up BLAT for your hub.
format: transBlat <url> <port>
examples:
- transBlat yourServer.yourInstitution.edu 17778
- name: blat
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Indicates the server and port to be used for the BLAT tool.
description: Indicates the server and port to be used for the BLAT tool. See our documentation for more
details about setting up BLAT for your hub.
format: blat <url> <port>
examples:
- blat yourServer.yourInstitution.edu 17777
- name: isPcr
types:
- all
roles:
- genome
category: genomes file settings
context: genomes
level: base
required: false
summary: Indicates the server and port to be used for the In-Silico PCR tool.
description: Indicates the server and port to be used for the In-Silico PCR tool. See our documentation
for more details about setting up In-Silico PCR for your hub.
format: isPcr <url> <port>
examples:
- isPcr yourServer.yourInstitution.edu 17779
- name: metadata
types:
- all
roles:
- super
- composite
- view
- leaf
category: Miscellaneous Deprecated Settings
context: trackDb
level: deprecated
required: false
summary: Deprecated.
description: 'Deprecated. Use meta instead.
Attaches metadata to a track as a list of name=value pairs on one line. Wrap a value that contains
spaces in double quotes. A word starting with # ends the line, so anything after it is a comment.
The pairs are shown on the track description page and on the item details page.
The meta setting replaces this one. It keeps the metadata in a single file for the whole hub, named
by metaDb or metaTab in genomes.txt , instead of repeating it in every stanza. See the metadata guide
. The Browser still reads metadata , but meta wins when a stanza has both.'
format: metadata <name=value> [<name=value> ...]
examples:
- metadata cellType=K562 antibody=CTCF lab="Broad Institute"
- name: noInherit
types:
- all
roles:
- super
- composite
- view
- leaf
category: Miscellaneous Deprecated Settings
context: trackDb
level: deprecated
required: false
summary: Deprecated.
description: 'Deprecated.
Placed on a subtrack, this stops the subtrack from taking settings from its composite parent. Without
it a subtrack inherits the parent''s type and group , plus every parent setting the subtrack does
not define itself.
The Browser only checks whether the setting is present, so any value turns it on, including noInherit
off . Defining a setting on the subtrack already overrides the inherited value, so this setting is
rarely needed.'
format: noInherit on
examples:
- noInherit on
- name: useScore
types:
- bed
- bigBed
- bigGenePred
- psl
- bigPsl
roles:
- leaf
category: Miscellaneous Deprecated Settings
context: trackDb
level: deprecated
required: false
summary: Deprecated.
description: 'Deprecated. Use spectrum instead.
Shades each item by its score field, so low scores draw in light gray and high scores draw near black.
spectrum on does the same thing and is the spelling to use in a new track. The Browser treats the
two names as one setting, and scoreMin , scoreMax and minGrayLevel tune both the same way.
In a trackDb file or a hub, any value turns the shading on, including useScore 0 , because the Browser
only checks whether the setting is present. In a custom track the value is read, and 0 turns the shading
off.'
format: useScore 1
examples:
- useScore 1