744c3f21361148e959397572e346516a81ea52ed
braney
Mon Aug 31 13:21:01 2026 -0700
Replace the dead snp track type with bed in thirteen trackDb settings
Thirteen settings in the library declared the type snp and nothing else. There
is no such track any more. hg38 and hg19 both have zero tracks of that type,
and nothing in the track engine dispatches on it: the only startsWith("snp",
...) left, at cgilib/snp125.c:318, tests the track name rather than the type.
The dbSNP tracks are bigDbSnp and "bed 6 +". So snp is not a missing type here,
it is a type that went away and took thirteen type lists with it.
Every one of them is used on bed today, between 2 and 4047 tracks each, and
each has a reader that a bed track reaches: snp125Ui.c for the ortho tables,
hapmapTrack.c for hapmapPhase, variation.c for defaultMaxWeight, and hgc.c for
the rest.
defaultGeneTracks gets bed and bigDbSnp. Its 16 bigDbSnp tracks are real, not
convention: snp153OfferGeneTracksForFunction reads the setting at hui.c:4923
and bigDbSnpCfgUi calls that function at hui.c:4999. None of the other twelve
is read on a bigDbSnp path.
Two of the thirteen were missing from the earlier survey of this family.
chimpMacaqueOrthoTable is a separate setting from chimpOrangMacOrthoTable and
is read at snp125Ui.c:16. codingAnnoLabel_<table> looked unused because hgc.c
builds the setting name at run time, at hgc.c:20153 inside
printSnpAlleleAndOrthos.
The two remaining snp spans are left alone on purpose. Neither is a setting:
one documents the snp track type itself and already says "type bed 6 +", and
the other is the example track stanza beneath it.
None of these thirteen has a row in the hub spec, which is correct, since they
all name a SQL table or a SQL-backed gene track. So the generated
trackDbSettings.yaml and .json do not change.
refs #37908
diff --git src/hg/htdocs/goldenPath/help/trackDb/trackDbLibrary.shtml src/hg/htdocs/goldenPath/help/trackDb/trackDbLibrary.shtml
index 2d0614344d4..ad1f694d7e6 100644
--- src/hg/htdocs/goldenPath/help/trackDb/trackDbLibrary.shtml
+++ src/hg/htdocs/goldenPath/help/trackDb/trackDbLibrary.shtml
@@ -1,7791 +1,7791 @@
<!-- trackDb documentation Library
In order to reference trackDb type and setting descriptions in multiple documents, this library
file is designed to hold the one definitive copy of the setting or type description.
*** Go ahead and try your changes by following existing examples.
If you have questions, read the detailed explanation below.
*** Your changes can be seen in hgwdev or your sandbox when they are in:
/usr/local/apache/htdocs-{sandbox}/goldenPath/help/trackDb/
A "make" should get them there.
ALWAYS CHECK THIS FILE AFTER MODIFYING IT !!!!!!!
Run "make settings", which rebuilds trackDbSettings.yaml and .json from this
file and reports any blurb it could not read. Then view trackDbDoc.html and
trackDbHub.html and open the settings you touched.
(The old trackDbTestBlurbs.html test page was dropped in Nov 2025.)
How to add/maintain this documentation:
There are 2 essential parts to trackDb*.html DOCS: I) this LIBRARY and II) the HTML PAGES.
I) This LIBRARY consists of DIVs that contain "blurbs" describing settings and types.
Example:
<DIV class="someSetting"><span class="types bed bigBed"></span>
<div class="format"><code>someSetting <minVal></code></div>
<P>Both <code>bed</code> and <code>bigBed</code> type tracks
use <code>someSetting</code> in combination with
<A onclick="return jumpTo(this);" HREF="#">visibility</A> to accomplish something.</P>
<P><B>Example:</B></P>
<pre> someSetting 100</pre>
</DIV>
- Each "blurb" DIV should have the class={setting}. There MUST be only one uniquely classed
DIV for each setting or type. NOTE: use class NOT id so that anchor links work.
- Each "setting blurb" must contain a <span class="types..."> that lists the track types that
this setting is relevant to.
- Each setting blurb MUST contain a <div class="format"> that gives the exact format of the
setting, wrapped in <code> tags.
- The setting blurb should also contain an <B>Example:</B> followed by a preferably real life
example wrapped in <PRE> tags. Remeber multi-line <PRE> text will include the indents
found in this file!
- Some settings may refer to other settings and your blurb should include a link to the other
setting, especially if that setting's blurb will appear at some distance in the document.
Since all settings should have an anchor by the setting name, a "jumpTo" link to
visibility setting can be accomplished as:
<A onclick="return jumpTo(this);" HREF="#">visibility</A>
which is identical to
<A HREF="#visibility">visibility</A>
- Any setting or code that is not made into a <A> link should be wrapped with <code> tags.
- "Type setting blurbs" are the same as other setting blurbs except that there should be a
separate "example blurb" DIV with class of type_example (e.g. <DIV class="bed_example">).
This will allow a type definition to be followed by multiple type specific settings then
be completed by the example that references those settings.
- These example blurbs should also have a "class=format" DIV but in this case it contains a
title to the example: <div class="format"><B>Examples of item base types</B></div>.
- Exmples should make use of <PRE> tags and preferrably multiple real life examples.
- Document introductions and section introductions may also be shared by multiple documents
and therefore may be included here as "intro blurb" DIVs as: <DIV class="bed_intro">.
- intro DIVs do not contain a class="format" DIV.
- Run "make settings" to check a blurb you add or modify. trackDbSettingsGen.py
parses this file and names any blurb whose types span, format div or description
it could not read.
HINT: It is the class={setting} that ties things togther. If there is a need for multiple
descriptions of the same setting, then create multiple blurb DIVs with different classes as:
<DIV class="parent"> and <DIV class="parent_view">.
II) Document HTML PAGES should include this trackDbLibrary.html with server side includes
and wrapped in <DIV ID="library"> tags.
- Documents may differ, but using trackDbDoc.html as the example, the setting
documentation is organized into tables by trackDb "type", so that settings are documented in
the context of their use. The (usually) single cell rows contain the settings.
The settings specification includes a <DIV> with a class attribute of value "format", and the
setting name embedded in <CODE> tags. In the trackDbHub document, the <CODE> tag has
a class whose value defines the support level for the setting, as 'class="level-*"', where '*'
is one of the levels defined in the introduction of the trackDbHub document.
Note: New settings should always be added to the current (highest version) trackDbHub document
in this directory (e.g. trackDbHub.v2.html) and designated "level-new".
Settings table row example for trackDbDoc.html:
<TR VALIGN=TOP><TD class="someSetting"><A name="someSetting"><IMG class='toggle detail'>
<div class="format"><code>someSetting</code></div>
</TD></TR>
Settings table row example for trackDbHub.v?.html:
<TR VALIGN=TOP><TD class="someSetting"><A name="someSetting"><IMG class='toggle detail'>
<div class="format"><code class="level-new">someSetting</code></div>
</TD></TR>
- Any setting may be referenced multiple times. To reference a setting blurb, place it in
a table cell that contains class={setting} and a <IMG class='toggle detail'> tag.
When the user clicks on the [+] button toggle image, the library will be read to render
the <DIV class="{setting}">.
- The table cell should also contain the "format" DIV, so the user knows what they are
requesting. The format contained in the doc will be replaced by the one in the
library at toggle, so the library has the final word on format. In the example,
<code>someSetting</code> is replaced by <code>someSetting <minVal></code>.
- The first (or best) reference to your library blurb should contain the one and only
"named anchor" for that setting <A name="{setting}">. This named anchor MUST be at
the beginning of the cell, before the toggle image. NOTE: the named anchor for a type is
often put at the start of the table that describes it.
- Related settings can be grouped as a set of related rows by adding the "related" class
to the TR. The first such related row must have class="related1st" as:
<TR class="related1st" VALIGN=TOP><TD class="directUrl"> ...
<TR class="related" VALIGN=TOP><TD class="hgsid">
Related rows toggle as a set and have faint dividers between them. The final setting DIV
of a related set should have an example for the whole set.
- Each table of settings for a particular type or set of types should end in an example. The
Example cell behaves similarly to the setting cells, except the row has a special class:
<TR class="examples" VALIGN=TOP><TD class="bed_example">
<A name="bed_Examples"><IMG class='toggle detail'>
- Each table should be headed with an introduction as:
<THEAD><TR><TD><DIV ID="bed_intro" class="intro"></DIV></TD></TR></THEAD>
All DIVs of class "intro" will be read from the library (by ID) and rendered when the
page is first loaded.
- Each table of settings can begin with a "toggle oneSection" image as:
<TR VALIGN=TOP><TH><IMG class='toggle oneSection'> bed/bigBed - Item or region track settings
This toggle will toggle all cells in the table.
- The document as a whole should contain a "toggle all" image as:
<IMG class='toggle all' /> <I>Open/close all details.</I>
which will open and close all the table cells.
- The document should include a "self-assembling table of contents". This table will be
built if
- There is an empty table of ID="toc": <TABLE class="settingsTable" id="toc"></TABLE>
- The $(document).ready() event calls: tdbDoc.tocAssemble(<delay>,[<exclude>]);
- delay (ms) greater than zero will delay the start of the assembly for user responsiveness
- <exclude> can be a comma separated list of settings (class={setting}) to exclude
- The table will fill in a header and a row per settingsTable td that contains a "format" div.
The table will include 3 columns: setting, types that call it (from the "types" span) and
the ID of the table that includes the setting. Use this ID to be descriptive:
ID="Signal_Track_Settings".
Additional text, table of contents, etc. may best be built into the document, not the library.
Please make use of "named anchors" and "jumpTo" anchors. Add uniquely named anchors and directly
reference those anchors as needed.
-->
<!-- The trackDbLibrary.html has a <div>
each setting organized roughly by track type -->
<!-- - - - - - - - COMMON settings - - - - - - - -->
<DIV class="commonSettings_intro">
The following settings, which must be defined for each trackDb record, are common to all
data format types. The first few settings are required for all tracks. Some type-specific
requirements will be mentioned in the appropriate sections to follow.
</DIV>
<DIV class="track"><span class="types all"></span>
<div class="format all"><code>track</code></div>
<P class="isRequired">Required: <span class="red">Yes</span></P>
<P>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:
[<code>a-zA-Z0-9_-</code>].</P>
<P><B>Example:</B></P>
<pre> track myFirstTrack</pre>
</DIV>
<DIV class="type"><span class="types all"></span>
<div class="format"><code>type</code></div>
<P class="isRequired">Required: <span class="red">Yes</span></P>
<P>Declares the format of the data and is used to
determine display methods and options.</P>
<P>Valid settings:</P>
<P>
<A onclick="return jumpTo(this);" HREF="#">altGraphX</A>,
<A onclick="return jumpTo(this);" HREF="#">bam</A>,
<A onclick="return jumpTo(this);" HREF="#">bed</A>,
<A onclick="return jumpTo(this);" HREF="#">bed5FloatScore</A>,
<A onclick="return jumpTo(this);" HREF="#">bedGraph</A>,
<A onclick="return jumpTo(this);" HREF="#">bedRnaElements</A>,
<A onclick="return jumpTo(this);" HREF="#">bigBarChart</A>,
<A onclick="return jumpTo(this);" HREF="#">bigBed</A>,
<A onclick="return jumpTo(this);" HREF="#">bigInteract</A>,
<A onclick="return jumpTo(this);" HREF="#">bigLolly</A>,
<A onclick="return jumpTo(this);" HREF="#">bigPsl</A>,
<A onclick="return jumpTo(this);" HREF="#">bigChain</A>,
<A onclick="return jumpTo(this);" HREF="#">bigMaf</A>,
<A onclick="return jumpTo(this);" HREF="#">bigWig</A>,
<A onclick="return jumpTo(this);" HREF="#">broadPeak</A>,
<A onclick="return jumpTo(this);" HREF="#">chain</A>,
<A onclick="return jumpTo(this);" HREF="#">clonePos</A>,
<A onclick="return jumpTo(this);" HREF="#">coloredExon</A>,
<A onclick="return jumpTo(this);" HREF="#">ctgPos</A>,
<A onclick="return jumpTo(this);" HREF="#">downloadsOnly</A>,
<A onclick="return jumpTo(this);" HREF="#">encodeFiveC</A>,
<A onclick="return jumpTo(this);" HREF="#">expRatio</A>,
<A onclick="return jumpTo(this);" HREF="#">factorSource</A>,
<A onclick="return jumpTo(this);" HREF="#">genePred</A>,
<A onclick="return jumpTo(this);" HREF="#">gvf</A>,
<A onclick="return jumpTo(this);" HREF="#">hic</A>,
<A onclick="return jumpTo(this);" HREF="#">ld2</A>,
<A onclick="return jumpTo(this);" HREF="#">narrowPeak</A>,
<A onclick="return jumpTo(this);" HREF="#">netAlign</A>,
<A onclick="return jumpTo(this);" HREF="#">peptideMapping</A>,
<A onclick="return jumpTo(this);" HREF="#">psl</A>,
<A onclick="return jumpTo(this);" HREF="#">rmsk</A>,
<A onclick="return jumpTo(this);" HREF="#">snake</A>,
<A onclick="return jumpTo(this);" HREF="#">vcfTabix</A>,
<A onclick="return jumpTo(this);" HREF="#">wig</A>,
<A onclick="return jumpTo(this);" HREF="#">wigMaf</A></P>
<P>Not all track types are supported in hubs. The types specifically
supported are called out at the top of the Hub Track Database Definition
page. 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.</P>
<P><B>Example:</B>
</P>
<pre> type bed 6 +</pre>
</DIV>
<DIV class="type_for_hubs"><span class="types all"></span>
<div class="format"><code>type</code></div>
<P class="isRequired">Required: <span class="red">Yes</span></P>
<P>Declares the format of the data and is used to
determine display methods and options.</P>
<P>Valid settings for a hub:</P>
<P>
<A onclick="return jumpTo(this);" HREF="#">bam/cram</A>,
<A onclick="return jumpTo(this);" HREF="#">bigBarChart</A>,
<A onclick="return jumpTo(this);" HREF="#">bigBed</A>,
<A onclick="return jumpTo(this);" HREF="#">bigChain</A>,
<A onclick="return jumpTo(this);" HREF="#">bigGenePred</A>,
<A onclick="return jumpTo(this);" HREF="#">bigInteract</A>,
<A onclick="return jumpTo(this);" HREF="#">bigLolly</A>,
<A onclick="return jumpTo(this);" HREF="#">bigMaf</A>,
<A onclick="return jumpTo(this);" HREF="#">bigNarrowPeak</A>,
<A onclick="return jumpTo(this);" HREF="#">bigPsl</A>,
<A onclick="return jumpTo(this);" HREF="#">bigWig</A>,
<A onclick="return jumpTo(this);" HREF="#">halSnake</A>,
<A onclick="return jumpTo(this);" HREF="#">hic</A>,
<A onclick="return jumpTo(this);" HREF="#">vcfTabix</A>,
<A onclick="return jumpTo(this);" HREF="#">vcfPhasedTrio</A>.
</P>
<P>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.</P>
<P><B>Example:</B></P>
<pre> type bigBed 6 +</pre>
</DIV>
<DIV class="shortLabel"><span class="types all"></span>
<div class="format"><code>shortLabel</code></div>
<P class="isRequired">Required: <span class="red">Yes</span></P>
<P>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 <a href="../../../FAQ/FAQcustom.html#custom13">special characters</a>
are allowed in the shortLabel.</P>
<P><B>Example:</B>
</P>
<pre> shortLabel Human mRNAs</pre>
</DIV>
<DIV class="longLabel"><span class="types all"></span>
<div class="format"><code>longLabel</code></div>
<P class="isRequired">Required: <span class="red">Yes</span></P>
<P>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 <a href="../../../FAQ/FAQcustom.html#custom13">special characters</a>
are allowed in the longLabel.</P>
<P><B>Example:</B></P>
<pre> longLabel Human mRNAs from GenBank</pre>
</DIV>
<DIV class="meta"><span class="types all"></span>
<div class="format"><code>meta</code></div>
<P class="isRequired">Required: No</P>
<P> 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 <a href="/goldenPath/help/metadata.html">metadata guide</a>.
</DIV>
<DIV class="metadata"><span class="types all"></span>
<div class="format"><code>metadata <name=value> [<name=value> ...]</code></div>
<P><I>Deprecated. Use <A onclick="return jumpTo(this);" HREF="#">meta</A> instead.</I></P>
<P>Attaches metadata to a track as a list of <code>name=value</code> pairs on one line.
Wrap a value that contains spaces in double quotes. A word starting with <code>#</code>
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.</P>
<P>The <code>meta</code> setting replaces this one. It keeps the metadata in a single
file for the whole hub, named by <code>metaDb</code> or <code>metaTab</code> in
<code>genomes.txt</code>, instead of repeating it in every stanza. See the
<a href="/goldenPath/help/metadata.html">metadata guide</a>. The Browser still reads
<code>metadata</code>, but <code>meta</code> wins when a stanza has both.</P>
<P><B>Example:</B></P>
<pre> metadata cellType=K562 antibody=CTCF lab="Broad Institute"</pre>
</DIV>
<DIV class="visibility"><span class="types all"></span>
<div class="format"><code>visibility</code></div>
<P class="isRequired">Required: No</P>
<P>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
<A HREF="#faceted_composite">faceted composite</A>, 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.</P>
<P>Valid settings:</P>
<UL>
<LI><code>hide</code>: DEFAULT. The track is not displayed in the Browser image unless
the user changes the display setting.</LI>
<LI><code>dense</code>: 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.</LI>
<LI><code>squish</code>: Each item is drawn individually, but at half height
and without a label. <i>(Not supported for all types.)</i></LI>
<LI><code>pack</code>: Items are displayed individually at full height, but
in a much more compact vertical space than in full mode.
<i>(Not supported for all types.)</i></LI>
<LI><code>full</code>: Each item is displayed as a separate line in the
Browser image. Graphed signals may be displayed in varying heights.</LI>
</UL>
<P><B>Example:</B>
</P>
<pre> visibility dense</pre>
</DIV>
<DIV class="onlyVisibility"><span class="types all"></span>
<div class="format"><code>onlyVisibility <dense|squish|pack|full></code></div>
<P class="isRequired">Required: No</P>
<P>Restricts a track to a single display mode. The visibility dropdowns and the
right-click menu offer only <code>hide</code> and the named mode, so the track either
displays that way or is hidden; an unrecognized mode is treated as <code>dense</code>.
Use this for a track that is only meaningful in one mode - to pick a starting mode that
the user can then change, use <A HREF="#visibility">visibility</A> instead.</P>
<P>This setting is also read from the subtracks of a
<A HREF="#faceted_composite">faceted composite</A>, whose own <code>visibility</code> is a
<em>maximum</em> for its subtracks rather than a value they inherit. Display modes rank
from least to most detailed as <code>hide</code>, <code>dense</code>, <code>squish</code>,
<code>pack</code>, <code>full</code>.</P>
<UL>
<LI>A subtrack with neither setting of its own displays at whatever the parent allows,
just as in a conventional composite.</LI>
<LI>A subtrack with its own <code>visibility</code> displays in that mode, or at the
parent's maximum if its own setting is the more detailed of the two.</LI>
<LI>A subtrack with <code>onlyVisibility</code> is pinned to that single mode. It
displays if that mode is within the parent's maximum, and is not displayed at all
otherwise.</LI>
</UL>
<P>Both <code>visibility</code> and <code>onlyVisibility</code> are read only from the
subtrack's own stanza and are not inherited from the parent; an
<code>onlyVisibility</code> 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.</P>
<P><B>Example:</B> a track that only makes sense as a single ribbon:
</P>
<pre> track coverage
onlyVisibility dense</pre>
<P><B>Example:</B> in a faceted composite with the maximum set to <code>pack</code>, the
levels subtrack below displays in <code>pack</code> mode rather than <code>full</code>,
and the reads subtrack displays in <code>dense</code> mode:
</P>
<pre> track methylation
compositeTrack faceted
visibility pack
track methylation_SRX172462_levels
parent methylation off
visibility full
track methylation_SRX172462_reads
parent methylation off
onlyVisibility dense</pre>
</DIV>
<DIV class="html"><span class="types all"></span>
<div class="format"><code>html</code></div>
<P class="isRequired">Required: No</P>
<p>Use the <code>html path/to/explain.html</code> 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 <code>html explainFile</code>. To further simplify trackDb,
if there is a file, <code>nameOfTrack.html</code>, in the same directory as the
trackDb matching the name of the track, <code>track nameOfTrack</code>,
then the html file does not need to be declared.
<p>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.</p>
<p>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
<a href="../examples/hubExamples/templatePage.html"
target="_blank">example template</a> that you can use.</p>
<div class="indent1">
<p><b>Description</b></p>
<p class="indent1">A few sentences describing the track.</p>
<p><b>Display Conventions and Configuration</b></p>
<P class="indent1">If the track has colors, or unusual display properties,
explain them in this section, or how to configure special settings.</p>
<p><b>Methods</b></p>
<p class="indent1">This section can explain data-handling algorithms,
or the significance of scores if generated in a special fashion.</p>
<p><b>Credits</b></p>
<P class="indent1">This section helps people find the contacts
for questions about the data. Please include an email or laboratory web page.</p>
<p><b>References</b></p>
<P class="indent1">Relevant publications regarding the data.</p>
</div>
<p><b>Example:</b></p>
<pre> html docs/myFirstTrack.html</pre>
Or with full path:
<pre> html https://path/to/location/docs/explainMyData.html</pre>
</DIV>
<DIV class="lessCommon_intro">
<H3>Common, though less frequently used settings</H3>
The following settings are available for many or all track types but are less frequently used.
Most are optional, but some may be required for specific track
types or in specific situations.<BR><BR>
<div class="hintBox">
<I><B>Inside hint:</B></I><I> The ra file
format supports '<code>\</code>' continuation characters. If the
setting is long or complex, break it into several lines using
terminating '<code>\</code>' characters to make it more readable.
</I>
</div>
<BR>
</DIV>
<DIV class="linkDataUrl"><span class="types bigChain "></span>
<div class="format"><code>linkDataUrl <url/relativePath></code></div>
<P class="isRequired">Required: <span class="red">For Hubs</span></P>
<P>The location of a remote data file containing the chain link data.</P>
</DIV>
<DIV class="lollyField"><span class="types bigLolly"></span>
<div class="format"><code>lollyField <integer></code></div>
Use the given field as the height of the lollipop.
</DIV>
<DIV class="lollyNoStems"><span class="types bigLolly"></span>
<div class="format"><code>lollyNoStems <on/off></code></div>
<P>Draw the lollipop heads without the stems that normally connect them to
the baseline.</P>
<P>This setting was documented as <code>noStems</code> until August 2026.
That spelling never worked, because the Browser has always read
<code>lollyNoStems</code>. A track using <code>noStems</code> draws its
stems as usual.</P>
<P><B>Example:</B></P>
<pre> lollyNoStems on</pre>
</DIV>
<DIV class="lollySizeField"><span class="types bigLolly"></span>
<div class="format"><code>lollySizeField <integer></code></div>
Use the given field as the size of the lollipop, measured in percentage of the total available drawing area.
</DIV>
<DIV class="lollyMaxSize"><span class="types bigLolly"></span>
<div class="format"><code>lollyMaxSize <integer></code></div>
The maximum size of a lollipop in the file, used to establish margins.
</DIV>
<DIV class="yAxisLabel"><span class="types bigLolly"></span>
<div class="format"><code>yAxisLabel.<integer> <integer> <on/off> <R,G,B> <string> </code></div>
Add a label on the y axis at the given position. Draw a line of color if requested.
</DIV>
<DIV class="yAxisNumLabels"><span class="types bigLolly"></span>
<div class="format"><code>yAxisNumLabels.<on/off> <integer></code></div>
Turn the y axis number labels on or off
</DIV>
<DIV class="bigDataUrl"><span class="types bigBarChart bigBed bigChain bigInteract bigLolly bigMaf bigPsl bigWig bam hic vcfTabix vcfPhasedTrio"></span>
<div class="format"><code>bigDataUrl <url/relativePath></code></div>
<P class="isRequired">Required: <span class="red">For Hubs</span></P>
<P>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. </P>
<!-- THIS SHOULD BE FIXED for local tracks! -->
<P>The setting is either the full URL (including <code>http:</code> 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, 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
<A onclick="jumpTo(this)" HREF="#">bigDataIndex</A> is used.
All occurrences of the string <code>$D</code> in the URL will be
substituted with the genome assembly database name. This allows a
trackDb entry to be used with for multiple assemblies. <code>$D</code>
substitution is not implemented for track hubs.
</P> <P><B>Example:</B></P>
<pre> bigDataUrl http://vizhub.wustl.edu/VizHub/hg19/biBrainH3K4me1.bb</pre>
or
<pre> bigDataUrl biBrainH3K4me1.bb</pre>
</DIV>
<DIV class="bigDataIndex"><span class="types bam vcfTabix vcfPhasedTrio"></span>
<div class="format"><code>bigDataIndex <url/relativePath></code></div>
<P>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.
<P>The setting is either the full URL (including <code>http:</code> 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).
</P> <P><B>Example:</B></P>
<pre> bigDataIndex http://vizhub.wustl.edu/VizHub/hg19/biBrainH3K4me1.bam.bai</pre>
</DIV>
<DIV class="boxedCfg"><span class="types all"></span>
<div class="format"><code>boxedCfg <on/off></code></div>
<!-- <P><I>NOT FOR HUBS</I></P> says Jim, but why not. Already used. -->
<P>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.</P>
<P><B>Example:</B></P>
<pre> boxedCfg on</pre>
</DIV>
<DIV class="canPack"><span class="types all"></span>
<div class="format"><code>canPack <off/on></code></div>
<P><I>Deprecated. The track type usually implies whether pack and
squish are offered, so this setting is rarely needed.</I></P>
<P>Most tracks can be displayed in all five
visibilities modes. However on some track types such as
wiggles, the <code>squish</code> and <code>pack</code> modes offer no real advantage
over the <code>dense</code> and <code>full</code> modes. By default, these tracks will
not offer the <code>squish</code> and <code>pack</code> 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.</P>
<P><B>Example:</B></P>
<pre> canPack on</pre>
</DIV>
<DIV class="color"><span class="types all"></span>
<div class="format"><code>color <red,green,blue></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> color 255,0,0</pre>
<P>This example sets the color to red.</P>
</DIV>
<DIV class="altColor"><span class="types all"></span>
<div class="format"><code>altColor <red,green,blue></code></div>
<P>Many track types allow setting a color range that varies from <code>color</code> to
<code>altColor</code>. For instance the CpG Island tracks use the <code>altColor</code>
setting to display the weaker islands, while the stronger ones are rendered in
<code>color</code>. If <code>altColor</code> is not specified, the system will
use a color halfway between that specified in the <code>color</code> tag
and white instead. Tracks using <code>altColor</code> 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.</p>
</P>
<P><B>Example:</B></P>
<pre> altColor 0,0,255</pre>
<P>This example sets the alternate color to blue.</P>
</DIV>
<DIV class="chromosomes"><span class="types all"></span>
<div class="format"><code>chromosomes <chr1,chr2,...></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> chromosomes chr1,chr7,chr18,chr19,chr22,chrX,chrM</pre>
</DIV>
<DIV class="configureByPopup"><span class="types all"></span>
<div class="format"><code>configureByPopup <on/off></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> configureByPopup off</pre>
</DIV>
<DIV class="darkerLabels"><span class="types all"></span>
<div class="format">
<code>darkerLabels on</code><BR>
</div>
<P>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.</P>
</DIV>
<DIV class="dataVersion"><span class="types all"></span>
<div class="format"><code>dataVersion <str></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> dataVersion May 2011 <em>beta</em></pre>
</DIV>
<DIV class="directUrl"><span class="types all"></span>
<div class="format"><I>Related settings:</I><BR>
<code>directUrl <url></code></div>
<P>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:</P>
<UL>
<LI>%s - item name</LI>
<LI>%s - chromosome name</LI>
<LI>%d - chromosome start position (relative to zero)</LI>
<LI>%d - chromosome end position (relative to one)</LI>
<LI>%s - track name</LI>
<LI>%s - database name</LI>
</UL>
<P><I>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.</I>
The URL can either be a full external URL or local to the web site.</P>
<P><B>Examples:</B></P>
<pre> directUrl http://mygenes.org/cgi-bin/geneView/%s</pre>
or
<pre> directUrl /cgi-bin/hgGene?hgg_gene=%s&hgg_chrom=%s&hgg_start=%d&hgg_end=%d&hgg_type=%s&db=%s</pre>
</DIV>
<DIV class="hgsid"><span class="types all"></span>
<div class="format"><code>hgsid on</code></div>
<P><I>NOT FOR HUBS.</I></P>
<P>The "cart" is a hidden table
that contains the persistent selections that users have
made in the Genome Browser. To ensure your directUrl has
access to these cart settings, include the user's
Browser ID with this setting.</P>
<P><hr class="example" /><B>Example:</B></P>
<pre>
directUrl /cgi-bin/hgGene?hgg_gene=%s&hgg_chrom=%s&hgg_start=%d&hgg_end=%d&hgg_type=%s&db=%s
hgsid on </pre>
<P>In this example the URL specified by <code>directUrl</code> will have the user's
Browser ID appended so that cart settings will be available.</P>
</DIV>
<DIV class="iframeUrl"><span class="types all"></span>
<div class="format"><code>iframeUrl <url></code></div>
<P>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:</P>
<UL>
<LI>$$ - ID, will be replaced by the <code>name</code>
of an item or other string id depending upon the fields in the
given track's type.</LI>
<LI>$T - database table name</LI>
<LI>$S - chromomosome name (scaffold name on
scaffold assemblies)</LI>
<LI>$[ - left-most position of current viewing window (relative to zero)</LI>
<LI>$] - right-most position of current viewing window (relative to one)</LI>
<LI>${ - start location of clicked item (relative to zero)</LI>
<LI>$} - end location of clicked item (relative to one)</LI>
<LI>$s - chromosome name without <i>chr</i> prefix (or without <i>scaffold_</i> or
<i>Scaffold_</i> prefix on scaffold assemblies)</LI>
<LI> $D - database name (e.g. "hg19")</LI>
<LI> $P - item name portion before first : in name</LI>
<LI> $p - item name portion after first : in name up to next colon</LI>
<LI> $taxId - NCBI Taxon ID of current organism (from hgCentral.dbDb)</LI>
<LI> $n - Scientific Name of current organism (from hgCentral.dbDb)</LI>
</UL>
<P>The URL can either be a full external URL or local to the web site.</P>
<P>In HTML, iframes cannot be resized easily, so the default static size is 1024 pixels. This can be
changed with <A onclick="jumpTo(this)" HREF="#">iframeOptions</A></P>
<P><B>Examples:</B></P>
<pre>
iframeUrl https://www.ncbi.nlm.nih.gov/nuccore/$$
iframeOptions height='600' width='1024'</pre>
</DIV>
<DIV class="iframeOptions"><span class="types all"></span>
<div class="format"><code>iframeOptions <string></code></div>
<P>When <A onclick="jumpTo(this)" HREF="#">iframeUrl</A> 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.
</P>
<P>If the statement is not present, the default is <code>width='100%' height='1024'</code>.</P>
<P>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.
<P><B>Example:</B></P>
<pre> iframeOptions width='800' height='800' scrolling='yes'</pre>
</pre>
<P>This example fixes the size to 800x800 pixels and activates scrollbars.</P>
</DIV>
<DIV class="directUrl_for_hubs"><span class="types all"></span>
<div class="format"><code>directUrl <url></code></div>
<P>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:</P>
<UL>
<LI>%s - item name</LI>
<LI>%s - chromosome name</LI>
<LI>%d - chromosome start position (relative to zero)</LI>
<LI>%d - chromosome end position (relative to one)</LI>
<LI>%s - track name</LI>
<LI>%s - database name</LI>
</UL>
<P><I>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.</I>
The URL can either be a full external URL or local to the web site.</P>
<P><B>Example:</B></P>
<pre> directUrl http://mygenes.org/cgi-bin/geneView/%s</pre>
</DIV>
<DIV class="downloadUrl"><span class="types all"></span>
<div class="format"><code>downloadUrl <label> <URL></code></div>
<P>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 <tt>label</tt> 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.
</P>
<P>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, ... </P>
<P><B>Example:</B></P>
<pre> downloadUrl GFF https://mywebsite.com/ucscTrack.gff.gz</pre>
<B>or</B><br>
<pre> downloadUrl.1 "GFF Format" https://mywebsite.com/ucscTrack.gff.gz</pre>
<pre> downloadUrl.2 "BED Format" https://mywebsite.com/ucscTrack.bed.gz</pre>
</DIV>
<DIV class="otherSpecies"><span class="types halSnake"></span>
<div class="format"><code>otherSpecies <otherSpecies></code></div>
<P>The name of the other assembly in the pairwise alignment for this track. </P>
<P><B>Example:</B></P>
<pre> otherSpecies tweeter</pre>
<P>The other species (other than the reference) in the alignment is the tweeter assembly in the same HAL file.</P>
</DIV>
<DIV class="otherDb"><span class="types all"></span>
<div class="format"><code>otherDb <otherDb></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> otherDb mm10</pre>
<P>This example sets the second assembly in the alignment to the mouse mm10 assembly.</P>
</DIV>
<DIV class="otherTwoBitUrl"><span class="types chain bigChain psl bigPsl"></span>
<div class="format"><code>otherTwoBitUrl <url/relativePath></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> otherTwoBitUrl https://hgdownload.gi.ucsc.edu/goldenPath/hg38/bigZips/hg38.2bit</pre>
</DIV>
<DIV class="origAssembly"><span class="types all"></span>
<div class="format"><code>origAssembly <db></code></div>
<P>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.</P>
<P><B>Example: </B>
</P>
<pre> origAssembly hg18</pre>
</DIV>
<DIV class="pennantIcon"><span class="types all"></span>
<div class="format"><code>pennantIcon <iconFile>/<text color> [html [tip]]
[; <iconFile>/<text color> [html [tip]]]</code></div>
<P>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:</P>
<UL>
<LI>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.</LI>
<LI>text - A single word label. Case is ignored; the label is displayed capitalized lower case.</LI>
<LI>color - An HTML color name to color the text label</LI>
<LI>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.</LI>
<LI>tip - A "quoted string" tip that will be seen
when the user's mouse pointer hovers over the icon.</LI>
</UL>
<P><B>Examples:</B></P>
<pre> pennantIcon 18.jpg ../goldenPath/help/liftOver.html "lifted from hg18"</pre>
<pre> pennantIcon New red ../goldenPath/releaseLog.html "Released October 19, 2017"</pre>
<pre> pennantIcon 19.jpg liftOver.html "lifted hg19"; p12 black http://genome.ucsc.edu/patches/ "annotations patch"</pre>
</DIV>
<DIV class="priority"><span class="types all"></span>
<div class="format"><code>priority <float></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> priority 50</pre>
</DIV>
<DIV class="release"><span class="types all"></span>
<div class="format"><code>release <alpha/beta/public>[,beta/public]</code></div>
<P><I>NOT FOR HUBS.</I></P>
<P>This specifies the version of the Browser where the
track will be displayed. It can contain any combination of the three
values:</P>
<UL>
<LI>alpha - displayed on the alpha Browser (aka
genome-test, hgwdev)</LI>
<LI>beta - displayed on the beta Browser (aka
hgwbeta)</LI>
<LI>public - released on the public Browser
(aka genome.ucsc.edu)</LI>
</UL>
<P>Default: alpha,beta,public (all three Browsers).</P>
<P><B>Example:</B></P>
<pre> release alpha,beta</pre>
</DIV>
<DIV class="table"><span class="types all"></span>
<div class="format"><code>table <tableName></code></div>
<P><I>NOT FOR HUBS.</I></P>
<P>The track setting of most tracks is the same as
the table name. However, in some cases it is desirable to
reference the same table in more than one track.
An example of this is showing a table as a single signal track and
as part of a combination overlay track, as described later in this
document. For data contained in MariaDB tables, this setting must be used
if the <code>track</code> setting is not the name of the table.</P>
<P><B>Example:</B></P>
<pre>
track mySecondTrack
table myFirstTable </pre>
</DIV>
<DIV class="tableBrowser"><span class="types all"></span>
<div class="format"><code>tableBrowser <off/on/noGenome/tbNoGenome> [table1 ...]</code></div>
<P>The Table Browser (and <a href=../api.html target=_blank>REST API</a>)
typically allow querying and downloading of
some or all of the raw data for a track. The <code>off</code> value blocks
all API getData operations and Table Browser access to datasets with
restrictions
(for example, those with confidentiality or licensing limitations).
The <code>tbNoGenome</code> value allows unrestricted API getData
operations, while limiting the table browser queries within specific
genomic regions, but not genome-wide.
The <code>noGenome</code> 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.</P>
<P><B>Examples:</B></P>
<pre> tableBrowser off decipherRaw knownToDecipher</pre>
<P>The table for this track, as well as the decipherRaw and knownToDecipher tables,
are blocked from Table Browser access.</P>
<pre> tableBrowser noGenome omimAv omimAvRepl</pre>
<p>Genome-wide queries are disabled for the track table as well as omimAv and omimAvRepl.
Queries on genomic regions are permitted.</p>
</DIV>
<DIV class="url"><span class="types all"></span>
<div class="format">
<code>url <url></code><BR>
<code>urlLabel <label></code><BR>
<code>idInUrlSql <sql for id></code></div>
<P>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:</P>
<UL>
<LI>$$ - ID, will be replaced by the <code>name</code>
of an item or other string id depending upon the fields in the
given track's type.</LI>
<LI>$T - database table name</LI>
<LI>$S - chromomosome name (scaffold name on
scaffold assemblies)</LI>
<LI>$[ - left-most position of current viewing window (relative to zero)</LI>
<LI>$] - right-most position of current viewing window (relative to one)</LI>
<LI>${ - start location of clicked item (relative to zero)</LI>
<LI>$} - end location of clicked item (relative to one)</LI>
<LI>$s - chromosome name without <i>chr</i> prefix (or without <i>scaffold_</i> or
<i>Scaffold_</i> prefix on scaffold assemblies)</LI>
<LI> $D - database name (e.g. "hg19")</LI>
<LI> $P - item name portion before first : in name</LI>
<LI> $p - item name portion after first : in name, up to next colon</LI>
<LI> $taxId - NCBI Taxon ID of current organism (from hgCentral.dbDb)</LI>
<LI> $n - Scientific Name of current organism (from hgCentral.dbDb)</LI>
<LI>$<fieldName> - For bigBed based tracks only (so excluding vcf, vcfPhasedTrio, bam/cram and hic), substitute the <fieldName> value from the bigBed.</LI>
</UL>
<P>The default prompt the user will see for this url is "outside link:". Use
<code>urlLabel</code> to provide a more informative prompt.
</P>
<P>For local (non-hub) tracks, an additional setting can be used to find an ID
from another table based upon the item name or id from the track's
table. The value found will replace the "<code>$$</code>" token in the <code>url</code>.
Note that the format of this trackDb setting is a normal C
language format so that the item will replace the "%s"
token in the sql statement.</P>
<!-- DONNA - I don't quite understand the idInUrlSql usage
TIM responds: By default the ID is the bed column 'name'. That is what the $$ token
gets replaced with in the url provided. The idInUrlSql allows having a separate table
in the mysql database that holds an alternate id. No doubt this setting was for a
special case added by one engineer for one specific result. Nevertheless, it is now one
of our many settings I needed to document. So if a wrangler has a case where the
'name' in their bed table can be used to look up a different name in a different table,
AND that different name is what they need use as an id in their url, THEN this is
the obscure setting for them. -->
<P><B>Example:</B></P>
<pre>
url https://www.ncbi.nlm.nih.gov/htbin-post/Entrez/query?form=4&db=$n&term=$$&extra=$<field2>
urlLabel NCBI Details:
idInUrlSql select name from sibTxGraph where id=%s </pre>
</DIV>
<DIV class="url_for_hubs"><span class="types all"></span>
<div class="format">
<code>url <url></code><BR>
<code>urlLabel <label></code></div>
<P>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:</P>
<UL>
<LI>$$ - ID, will be replaced by the <code>name</code>
of an item or other string id depending upon the fields in the
given track's type.</LI>
<LI>$T - database table name</LI>
<LI>$S - chromomosome name (scaffold name on
scaffold assemblies)</LI>
<LI>$[ - left-most position of current viewing window (relative to zero)</LI>
<LI>$] - right-most position of current viewing window (relative to one)</LI>
<LI>${ - start location of clicked item (relative to zero)</LI>
<LI>$} - end location of clicked item (relative to one)</LI>
<LI>$s - chromosome name without <i>chr</i> prefix (or without <i>scaffold_</i> or
<i>Scaffold_</i> prefix on scaffold assemblies)</LI>
<LI> $D - database name (e.g. "hg19")</LI>
<LI> $P - item name portion before first : in name</LI>
<LI> $p - item name portion after first : in name, up to next colon</LI>
<LI> $taxId - NCBI Taxon ID of current organism (from hgCentral.dbDb)</LI>
<LI> $n - Scientific Name of current organism (from hgCentral.dbDb)</LI>
<LI>$<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.</LI>
</UL>
<P>The default prompt the user will see for this url is "outside link:". Use
<code>urlLabel</code> to provide a more informative prompt.
</P>
<P><B>Example:</B></P>
<pre>
url https://www.ncbi.nlm.nih.gov/htbin-post/Entrez/query?form=4&db=$n&term=$$&extra=$<field2>
urlLabel NCBI Details: </pre>
</DIV>
<DIV class="urls"><span class="types bigBed bigBarChart"></span>
<div class="format">
<code>urls <fieldName1>="<url1>" <fieldName2>="<url2>" ...</code><BR>
</div>
<P>This is similar to the <A onclick="jumpTo(this)" HREF="#">url</A> 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. </P>
<P>
Put the identifiers for these links into extended
bigBed fields as explained in example 3 of the <a href="/goldenPath/help/bigBed.html#Ex3">bigBed documentation</a>.
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 <A
onclick="jumpTo(this)" href="#url">url</a> 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).
</P>
<p>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.</p>
<p>
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".</p>
<P><B>Example:</B></P>
<pre>
urls pmid="https://www.ncbi.nlm.nih.gov/pubmed/$$" spId="http://www.uniprot.org/uniprot/$$"
</pre>
</DIV>
<DIV class="skipEmptyFields"><span class="types bigBed bigPsl bigGenePred bigMethyl bigNarrowPeak bigMaf bigChain"></span>
<div class="format">
<code>skipEmptyFields on</code><BR>
</div>
<P>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.</P>
</DIV>
<DIV class="skipFields"><span class="types bigBed bigPsl bigGenePred bigMethyl bigNarrowPeak bigMaf bigChain"></span>
<div class="format">
<code>skipFields <fieldName1>,<fieldName2> ...</code><BR>
</div>
<P>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.
</P>
<P><B>Example:</B></P>
<pre>
skipFields mouseOver,labelField,hiddenField
</pre>
</DIV>
<DIV class="sepFields"><span class="types bigBed bigPsl bigGenePred bigMethyl bigNarrowPeak bigMaf bigChain"></span>
<div class="format">
<code>sepFields fieldName1,fieldName2 ...</code><BR>
</div>
<P>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.
</P>
<P><B>Example:</B></P>
<pre>
sepFields pmid,spId
</pre>
</DIV>
<DIV class="mouseOverField"><span class="types bigBed bigPsl bigChain bigMaf bigMethyl bigNarrowPeak bigGenePred bigLolly"></span>
<div class="format">
<code>mouseOverField <fieldName1></code><BR>
</div>
<P>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. </P>
<P>
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 <a href="/goldenPath/help/bigBed.html">bigBed documentation</a>.
The field name from your .as file is the field name for this statement.
</P>
<P><B>Example:</B></P>
<pre>
mouseOverField comment
</pre>
</DIV>
<DIV class="mouseOver"><span class="types bigBed bigPsl bigChain bigMaf bigMethyl bigNarrowPeak bigGenePred bigLolly"></span>
<div class="format">
<code>mouseOver <pattern></code><BR>
</div>
<P>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.</P>
<P><B>Example:</B></P>
<pre>
mouseOver variant $name/$chrom:${chromStart} value $score
</pre>
</DIV>
<DIV class="multiRegionsBedUrl"><span class="types all"></span>
<div class="format"><code>multiRegionsBedUrl <url/relativePath></code></div>
<P>This setting causes a link to appear on the track configuration and items details pages to
launch a
<a target="_blank" href="https://genome.ucsc.edu/goldenPath/help/multiRegionHelp.html">
multi-region custom regions view</a>,
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
<a target="_blank" href="https://genome.ucsc.edu/FAQ/FAQformat.html#format1">BED format</a>,
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.
<P><B>Example</B></P>
<pre> multiRegionsBedUrl covidMuts.regions.bed</pre>
</DIV>
<DIV class="wgEncode"><span class="types all"></span>
<div class="format"><code>wgEncode on</code></div>
<P><I>NOT FOR HUBS.</I></P>
<P>This setting designates an ENCODE track. It activates the following special features:
<UL>
<li>Special thumbnail (NHGRI helix) is displayed before the track label in the brower track menu</li>
<li>ENCODE logo is displayed on track configuration page
<li>'Downloads' and 'Preview' browser links shown in upper right portion of track configuration page
<li>Track description includes a note about data on preview browser
<li>'downloads' and 'metadata' links appear after 'View table:' on track details page
</UL>
</P>
<P><B>Example:</B></P>
<pre> wgEncode on</pre>
</DIV>
<!-- - - - - - - - BED/BIGBED settings - - - - - - - -->
<DIV class="bed_intro">
<H3>bed/bigBed: Item or region tracks</H3>
<P>Some of the most
common track types are those that highlight regions or items of
varying size in a genome assembly. There are many variations to the
"items" track, most of which are specified with a bed or
bigBed format. These two formats are really a cluster of many
formats all starting with three common fields (chromosome start end)
and having optionally many more fields. For complete bed or bigBed
format definitions please see the
<A HREF="../../../FAQ/FAQformat.html">FAQ</A>.</P>
</DIV>
<DIV class="bigChain_intro">
<H3>bigChain: Genome-wide Pairwise Alignments</H3>
<P>
The bigChain format describes a pairwise alignment that allow gaps in both sequences simultaneously, just as Chain files do, but bigChain files are compressed and indexed as bigBeds. bigChain files are created using the program bedToBigBed with a special AutoSQL file that defines the fields of the bigChain. The resulting bigChain files are in an indexed binary format. The main advantage of the bigChain files is that only portions of the files needed to display a particular region are transferred to UCSC. So for large data sets, bigChain is considerably faster than regular Chain files. The bigChain file remains on your web accessible server (http, https, or ftp), not on the UCSC server. Only the portion that is needed for the chromosomal position you are currently viewing is locally cached as a "sparse file".
For complete bigChain format definitions please see the
<A HREF="../bigChain.html">bigChain help page</A>.</P>
</DIV>
<DIV class="bigPsl_intro">
<H3>bigPsl: Pairwise Alignments</H3>
<P>
The bigPsl format stores alignments between two sequences, as PSL files do, but they are compressed and indexed as bigBeds. bigPsl files are created using the program bedToBigBed with a special AutoSQL file that defines the fields of the bigPsl. The resulting bigPsl files are in an indexed binary format. The main advantage of the bigPsl files is that only portions of the files needed to display a particular region are transferred to UCSC. So for large data sets, bigPsl is considerably faster than regular PSL files. The bigPsl file remains on your web accessible server (http, https, or ftp), not on the UCSC server. Only the portion that is needed for the chromosomal position you are currently viewing is locally cached as a "sparse file".
For complete bigPsl format definitions please see the
<A HREF="../bigPsl.html">bigPsl help page</A>.</P>
</DIV>
<DIV class="bigGenePred_intro">
<H3>bigGenePred: Gene Annotations</H3>
<P>
The bigGenePred format stores annotation items that are a linked collection of exons, much as BED files indexed as bigBeds do, but bigGenePred has additional information about the coding frames and other gene specific information in eight additional fields.
bigGenePred files are created using the program bedToBigBed with a special AutoSQL file that defines the fields of the bigGenePred. The resulting bigBed files are in an indexed binary format. The main advantage of the bigBed files is that only portions of the files needed to display a particular region are transferred to UCSC. So for large data sets, bigBed is considerably faster than regular BED files. The bigBed file remains on your web accessible server (http, https, or ftp), not on the UCSC server. Only the portion that is needed for the chromosomal position you are currently viewing is locally cached as a "sparse file".
For complete bigGenePred format definitions please see the
<A HREF="../bigGenePred.html">bigGenePred help page</A>.</P>
</DIV>
<DIV class="bigMethyl_intro">
<H3>bigMethyl: Metholated sites</H3>
<P>
The bigMethyl format stores methylation sights. bigMethyl files are based on the bigBed format. The first nine fields are the same as bed. The other nine include various scores.
bigMethyl files are created using the program bedToBigBed with a special AutoSQL file that defines the fields of the bigMethyl. The resulting bigBed files are in an indexed binary format. The main advantage of the bigBed files is that only portions of the files needed to display a particular region are transferred to UCSC. So for large data sets, bigBed is considerably faster than regular BED files. The bigBed file remains on your web accessible server (http, https, or ftp), not on the UCSC server. Only the portion that is needed for the chromosomal position you are currently viewing is locally cached as a "sparse file".
For complete bigMethyl format definitions please see the
<A HREF="../bedMethyl.html#bigMethyl">bigMethyl help page</A>.</P>
</DIV>
<DIV class="bigNarrowPeak_intro">
<H3>bigNarrowPeak: Peaks</H3>
<P>
The bigNarrowPeak format stores peaks over a range with a single basepair central peak. bigNarrowPeak files are based on the bigBed format. The first six fields are the same as bed. The other four include three scores, and the base-pair offset of the central peak.
bigNarrowPeak files are created using the program bedToBigBed with a special AutoSQL file that defines the fields of the bigNarrowPeak. The resulting bigBed files are in an indexed binary format. The main advantage of the bigBed files is that only portions of the files needed to display a particular region are transferred to UCSC. So for large data sets, bigBed is considerably faster than regular BED files. The bigBed file remains on your web accessible server (http, https, or ftp), not on the UCSC server. Only the portion that is needed for the chromosomal position you are currently viewing is locally cached as a "sparse file".
For complete bigNarrowPeak format definitions please see the
<A HREF="../bigNarrowPeak.html">bigNarrowPeak help page</A>.</P>
</DIV>
<DIV class="bigMaf_intro">
<H3>bigMaf: Multiple Alignments</H3>
<P>
The bigMaf format stores multiple alignments in a format compatible with MAF files, which are then compressed and indexed as bigBeds. bigMaf files are created using the program bedToBigBed with a special AutoSQL file that defines the fields of the bigMaf. The resulting bigMaf files are in an indexed binary format. The main advantage of the bigMaf files is that only portions of the files needed to display a particular region are transferred to UCSC. So for large data sets, bigMaf is considerably faster than regular MAF files. The bigMaf file remains on your web accessible server (http, https, or ftp), not on the UCSC server. Only the portion that is needed for the chromosomal position you are currently viewing is locally cached as a "sparse file".
For complete bigMaf format definitions please see the
<A HREF="../bigMaf.html">bigMaf help page</A>.</P>
</DIV>
<DIV class="bigBed_intro">
<H3>bigBed: Item or region tracks</H3>
<P>Some of the most
common track types are those that highlight regions or items of
varying size in a genome assembly. There are many variations to the
"items" track, most of which can be represented with a bigBed format.
This format is really a cluster of many
formats all starting with three common fields (chromosome start end)
and having optionally many more fields. For complete bigBed
format definitions please see the
<A HREF="../bigBed.html">bigBed help page</A>.</P>
</DIV>
<DIV class="halSnake_intro">
<H3>halSnake -- Multiple Alignments in a HAL file</H3>
<P>
HAL is a file generated by the Cactus Progressive Alignment Suite, see
<A HREF="https://github.com/glennhickey/progressiveCactus">Cactus github page</A>.</P>
</P>
</DIV>
<DIV class="halSnake"><span class="types halSnake"></span>
<div class="format"><code>type halSnake</code></div>
<P>If the <code>bigDataUrl</code> setting is included, the data at the location
specified by that URL will be
displayed. Otherwise, a database table with a single column <code>fileName</code>
can specify the location of a local file or a URL.
If the database table includes a column <code>seqName</code>, a different
VCF file or URL can be specified for each assembly sequence.</P>
<P><em>Example can be found below.</em></P>
</DIV>
<DIV class="bed"><span class="types bed bigBed"></span>
<div class="format">
<code>type bed <3-12> [+/.]</code><BR>
<code>type bigBed <3-12> [+/.]</code></div>
<P>Both bed and bigBed
declare the number of standard bed fields in the data.
Additional fields may follow these standard ones. If so, the
type should end with a '<code>+</code>' (plus). Even if there are not
additional non-standard fields, the additional parameter '<code>.</code>' (dot)
is needed, if this track is meant to be configurable.</P>
<P><em>Examples can be found below.</em></P>
</DIV>
<DIV class="bigBed"><span class="types bigBed"></span>
<div class="format">
<code>type bigBed <3-12> [+/.]</code></div>
<P>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 '<code>+</code>' (plus). Even if there are no
additional non-standard fields, the parameter '<code>.</code>' (dot)
must be specified if this track is meant to be configurable.</P>
<P><B>Example:</B></P>
<pre> type bigBed 9 +</pre>
</DIV>
<DIV class="bigPsl"><span class="types bigPsl"></span>
<div class="format">
<code>type bigPsl</code></div>
There are no extra options that can appear on the type bigPsl line.
</DIV>
<DIV class="bigChain"><span class="types bigChain"></span>
<div class="format">
<code>type bigChain targetDb</code></div>
You must specify the target database in the type bigChain line.
</DIV>
<DIV class="bigNarrowPeak"><span class="types bigNarrowPeak"></span>
<div class="format">
<code>type bigNarrowPeak</code></div>
There are no extra options that can appear on the type bigNarrowPeak line.
</DIV>
<DIV class="bigGenePred"><span class="types bigGenePred"></span>
<div class="format">
<code>type bigGenePred</code></div>
There are no extra options that can appear on the type bigGenePred line.
</DIV>
<DIV class="bigMaf"><span class="types bigMaf"></span>
<div class="format">
<code>type bigMaf</code></div>
There are no extra options that can appear on the type bigMaf line.
</DIV>
<DIV class="bigBarChart"><span class="types bigBarChart"></span>
<div class="format">
<code>type bigBarChart</code></div>
There are no extra options that can appear on the type bigBarChart line.
</DIV>
<DIV class="bigLolly"><span class="types bigLolly"></span>
<div class="format">
<code>type bigLolly</code></div>
There are no extra options that can appear on the type bigLolly line.
</DIV>
<DIV class="bigInteract"><span class="types bigInteract"></span>
<div class="format">
<code>type bigInteract</code></div>
There are no extra options that can appear on the type bigInteract line.
</DIV>
<DIV class="hic"><span class="types hic"></span>
<div class="format">
<code>type hic</code></div>
There are no extra options that can appear on the type hic line.
</DIV>
<DIV class="bed_flavors"><span class="types bed5FloatScore bedRnaElements broadPeak coloredExon gvf ld2 narrowPeak peptideMapping"></span>
<div class="format">
<code>type bed5FloatScore</code><BR>
<code>type bedRnaElements</code><BR>
<code>type broadPeak</code><BR>
<code>type coloredExon</code><BR>
<code>type gvf</code><BR>
<code>type ld2</code><BR>
<code>type narrowPeak</code><BR>
<code>type peptideMapping</code></div>
<P>Each of these is a
specialized variation of the bed format. Their
specialized definitions should be sought elsewhere. However,
these item tracks share many of the same configuration options
available to bed tracks.</P>
<!--DONNA - rewrite above -->
<P><em>An example can be found below.</em></P>
</DIV>
<DIV class="colorByStrand"><span class="types bed bigBed"></span>
<div class="format"><code>colorByStrand <red,green,blue> <red,green,blue></code></div>
<P>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 <code>spectrum</code>
and all items on the same strand will have the same color, regardless of the item's
<code>score</code>.</P>
<P><B>Example:</B></P>
<pre> colorByStrand 255,0,0 0,0,255</pre>
<P>Plus strand alignments will be colored red, and minus
strand alignments will be blue. This setting is incompatible with <code>spectrum</code>,
and therefore all items on the same strand will have the same color, regardless of the item's
<code>score</score>.</P>
</DIV>
<DIV class="compareGenomeLinks"><span class="types bed"></span>
<div class="format"><code>compareGenomeLinks <db[.table[.column]]=label>
[db[.table[.column] =label …]</code></div>
<P><I>NOT FOR HUBS</I></P>
<P>Sometimes the
features that a bed track highlights in one genome are also
displayed in tracks of other genomes. If an item of the same name
exists in the bed tracks of two or more genomes, a bridge can be
readily made between them through links on the item's detail page. To establish
this association, the feature must have the same name in each genome, and the name
must be unique within the bed track of each genome. The components of this
setting are a genome assembly database, an optional table and column,
with a label for the link. If the column parameter is omitted, it is
assumed to be <code>name</code>. If the table is omitted, it
is assumed to be the same as the current table. Links to multiple
genomes can be established with this setting, as each pair is
joined by '<code>=</code>' and delimited by space. Be sure to use
'<code>_</code>' as a substitute for spaces in the labels.</P>
<P><B>Example:</B></P>
<pre>
compareGenomeLinks panTro2=Chimpanzee_(March_2006) rheMac2=Rhesus_(January_2006) \
mm9=Mouse_(July_2007) rn4=Rat_(November_2004) canFam2=Dog_(May_05) \
bosTau4=Cow_(October_2007) </pre>
<P>In this example for
the hg18 ENCODE bi-directional promoter track, each genome has a
track of the same name, and the names are unique within each track.
However, a named bi-directional promoter will not be found in
every genome; therefore, only links to genomes where the name is actually
found will be displayed.</P>
<!-- DONNA -- reread -->
<!--
<P><I>TODO: Bug alert: this was coded narrowly and
may have some problems when the table or column names differ from
default. This feature could be extended to simply provide a link
to the top hit of liftOver, if there is no named table found.</I></P>
-->
</DIV>
<DIV class="denseCoverage"><span class="types bigBed"></span>
<div class="format"><code>denseCoverage <maxVal></code></div>
<P><I>bigBed specific</I></P>
<P>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.</P>
<P><B>Example:</B></P>
<pre> denseCoverage 100</pre>
</DIV>
<div class="decorator"><span class="types bed bigBed genePred bigGenePred psl bigPsl"></span>
<div class="format"><code>decorator.default.*</code></div>
<p>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 <a
href="../decorator.html">Track Decorators</a> help page.</p>
<p>NB: In all of the following settings, <code>decorator.default.</code> 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,
<code>filterValues</code> 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
<code>decorator.default.filterValues</code> to filter which decorations are drawn.
In the future, other names besides "default" may be allowed to permit multiple
decorators annotating a single track.</p>
<p><strong>Settings</strong></p>
<p><code>decorator.default.bigDataUrl <url></code></p>
<p>This setting is required when adding a decorator to a track. It specifies
the path to a bigBed file that contains the decorations.</p>
<p><code>decorator.default.filterValues <specification></code></p>
<p>Decorators support the same filter options that bigBed tracks do. This includes
the <code>filter</code>, <code>filterText</code>, and <code>filterValues</code>
settings, as described in the
<a href="../hubQuickStartFilter.html">Track Hub Filters Quick Start Guide</a>.</p>
<p><code>decorator.default.mouseOver <specification></code></p>
<p>Decorators also support the same <code>mouseOver</code> and <code>mouseOverField</code>
settings that can be applied to bigBed tracks.</p>
<p>There is one more setting that is currently specific to decorators.</p>
<p><code>decorator.default.maxLabelBases <integer></code></p>
<p>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. <code>maxLabelBases</code> sets a maximum window size (in bases) for which
labels will be drawn. If not set, the value will default to 200kb.
</p>
</div>
<DIV class="labelOnFeature"><span class="types bed bigBed"></span>
<div class="format"><code>labelOnFeature <on/off></code></div>
<P>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.<br>
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 <A onclick="jumpTo(this)" HREF="#">exonArrows</A>. </P>
<P><B>Example:</B></P>
<pre> labelOnFeature on</pre>
</DIV>
<DIV class="exonArrows"><span class="types bed bigBed genePred bigGenePred psl bigPsl chain bigChain narrowPeak bigNarrowPeak broadPeak"></span>
<div class="format"><code>exonArrows <on/off></code></div>
<P>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.
</P>
<P><B>Example:</B></P>
<pre> exonArrows off</pre>
</DIV>
<DIV class="exonNumbers"><span class="types genePred bigGenePred bed bigBed psl bigPsl"></span>
<div class="format"><code>exonNumbers <on/off></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> exonNumbers off</pre>
<P>The text can be set with the options "exonText" and "intronText". It defaults to "exon" and "intron", respectively.</P>
</DIV>
<DIV class="Filter"><span class="types bed bigBed narrowPeak bigNarrowPeak broadPeak"></span>
<div class="format">
<code><column>Filter <low>[:<high>]</code><BR>
<code>scoreFilter <low>[:<high>]</code><BR>
<code>pValueFilter</code><BR>
<code>qValueFilter</code><BR>
<code>signalFilter</code><BR>
<code><column>FilterLimits <low>[:<high>]</code><BR>
<code><column>FilterByRange <off/on></code>
</div>
<P>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
<code>score</code>, and is thus controlled by the <code>scoreFilter</code>
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.
</P>
<P>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 <code><column>FilterLimits</code>.
</P>
<P>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
<code><column>FilterByRange</code> setting. For example, a
<code>scoreFilter</code> range of
800-900 will include only items with scores at or above 800 and
below 900.</P>
<P>Note: multiple
filters of different fields are allowed.</P>
<P><B>Examples:</B></P>
<pre> scoreFilter 100</pre>
<P>In this example, the standard bed
field <code>score</code>, 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.</P>
<pre>
pValueFilter 3.0:15.0
pValueFilterLimits 0.0:15.0
pValueFilterByRange on </pre>
<P>The non-standard bed field <code>pValue</code>, 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.</P>
</DIV>
<DIV class="scoreFilter"><span class="types bigBed"></span>
<div class="format">
<code>scoreFilter <low>[:<high>]</code><BR>
<code>scoreFilterLimits <low>[:<high>]</code><BR>
</div>
<P>Type <code>bigBed</code> tracks can be filtered on the standard bed field
<code>score</code>. This numerical filter is requested by the
<code>scoreFilter</code> setting, which should include the default value.
</P>
<P>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 <code>scoreFilterLimits</code>.
</P>
<P>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.</P>
<p>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 <code>scoreFilter 400</code> and <code>scoreFilterLimits 0:1000</code>
can be replaced with <code>filter.score 400</code> and <code>filterByRange.score 0:1000</code>.
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. </p>
<P><B>Example:</B></P>
<pre>
scoreFilter 300
scoreFilterLimits 200:1000</pre>
<P>The standard bed
field of <code>score</code>, 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..</P>
</DIV>
<DIV class="filterBy"><span class="types bed bigBed genePred bigGenePred psl bigPsl bigLolly factorSource"></span>
<div class="format"><code>filterBy <field1:title=[+]opt1a...>
[field2:title=[+]opt2a...]</code></div>
<P>Another method of
filtering items relies upon discrete values. One or more fields
such as <code>name</code> or <code>score</code> 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.
</P>
<P><I>Setting complexities:</I></P>
<UL>
<LI> Because filters for different fields are delimited by whitespace, any
whitespace in titles and labels should be replaced by the '<code>_</code>'
(underscore) character.</LI>
<LI> Each field/option pair is joined by '<code>=</code>' (equal sign).</LI>
<LI> The field portion
can have a title that is delimited from the field name by '<code>:</code> (colon)'.</LI>
<LI> A single field
filter will have multiple options delimited by commas.</LI>
<LI> If the options are
a 1-based index (1,2,3...) then the option list can be preceded
with a '<code>+</code>' (plus sign) and the options themselves are only labels.</LI>
<LI> Otherwise, each
option will be a value and optional label delimited by '<code>|</code>' (vertical bar).
Note that if one option has a label then all options of that filter
must have a label.</LI>
<LI><em>Finally,
options may have CSS style wrapped in {curly} brackets and
appended to the end.</em></LI>
</UL>
<P><I>Because of this
complexity, please remember to use the '<code>\</code>' continuation line to
ensure the setting is readable: </I>
</P>
<pre>
filterBy {field1}[:{Title1}]=[+]\
option1a[|label1a[{style1a}]],\
option1b[|label1b[{style1b}]],... \
[{field2}[:{Title2}]=[+]\
option2a[|label2a[{style2a}]],,...] </pre>
<P><I>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.</I></P><BR>
<div class="hintBox">
<I class="red">Secret tricks:</I>
<OL>
<LI>Avoid the use of the delimiter chars <code> ,|:={}</code> in titles and
labels. (These characters can be included via HTML codes.)
Spaces can be included by using the '<code>_</code>' character.</LI>
<LI>The option labels
can be in color or have other CSS style attributes. Append the style
enclosed in curly brackets and containing no spaces. For example:
<code>Pull_Over{color:#AA0000;text-decoration:blink;}</code>.
If one option has CSS style, then all options of that
filter must include a style definition.</LI>
<LI>The filterBy option is implemented in the code using an SQL <code>where</code> clause.
For instance, filtering on the <code>name</code> field for "Fred" and
"Ethyl" would result in an SQL where clause of
"<code>where name in ('Fred','Ethyl')</code>". In <code>type genePred</code>
tracks, this knowledge is used to define filters on fields in a separate table!
This is done by defining the field as <code>{otherTableName}.{fieldName}</code>.</LI>
</OL>
</div>
<P>The best way to
understand this setting is with an example. This is an operational
example in the hg19 "Open Chrom Synth" track.</P>
<P><B>Example:</B></P>
<pre>
filterBy color:Validation_Level=\
0|Validated_(OC_1){color:#000000},\
255|Open_Chromatin_(OC_2-3){color:#0000FF},\
39168|DNase_low_(OC_2){color:#009900},\
10027008|FAIRE_low_(OC_3){color:#990000},\
16711935|ChIP-seq_(OC_4){color:#FF00FF} \
ocCode:OC_Code=+\
One&#58;_Validated_(all),\
Two&#58;_DNase_(all),\
Three&#58;_FAIRE_(all),\
Four&#58;_ChIP_(all) </pre>
<P>This setting sets up
two filters, one on the field "<code>color</code>" and a second for the
"<code>ocCode</code>" 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, "<code>ocCode</code>", is titled by the
inscrutable "OC Code". It is a numeric index filter
(as declared by the '<code>+</code>'). 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.
</P>
<P>The filterBy setting is very powerful. We recommend that you experiment with the
settings to determine which work best for your case.</P>
<!--
<P><I>TODO: make a set
of standard filterBy settings and methods that work like *Filter
and filterBy:
<UL>
<LI>filterByDate</LI>
<LI>filterByNumber (currently *Filter)</LI>
<LI>filterByWild</LI>
<LI>filterByWildList (like in track search)</LI>
</UL></I></P>
<P><I>These generic filter controls should work by
"where clause" and should be allowed on any item based track
including bigBeds! Note that bigBeds already support scoreFilter
and will always have the problem that zoomed out will not support
filtering. The Browser UI should show when tracks are filtered,
so that losing the filter is obvious!</I></P>
-->
</DIV>
<DIV class="filter"><span class="types bed bigBed"></span>
<div class="format">
<code>filter.<fieldName> <default integer></code><BR>
<code>filterByRange.<fieldName> <off/on></code><BR>
<code>filterLimits.<fieldName> <low>[:<high>]</code><BR>
</div>
<P>There are a number of different filters available for bigBed data. See the
<a href="../hubQuickStartFilter.html" target="_blank">Filters Quick Start guide</a> for
more info. Note: for configurable features, like filters, an additional period
"." or plus "+" is required in the type declaration,
for instance <code>type bigBed 5 .</code> or <code>type bigBed 9 +</code>.</p>
<P><code> filter.<fieldName> </code> 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.</P>
<P>By default, the range of values for <code>filter.<fieldName></code> is 0 to 1000.
However, you can explicitly set the upper and lower limits of the filter with
<code>filterLimits.<fieldName></code>.</P>
<P>The numeric filters will exclude items that fall below the setting. That is, a
<code>filter.<fieldName></code> of 800 will exclude all items with a score
below 800. You can also filter values within a range by including the
<code>filterByRange.<fieldName></code> setting. For example,
<code>filter.<fieldName> 800:900</code> will include only items with scores at
or above 800 and below 900. It is recommended that <code>filterByRange.<fieldName></code>
be used in combination with <code>filterLimits.<fieldName></code>
to set limit boundaries.</P>
<P>The filter label will be the description of the field as specified by the autoSql (.as) file.
This label can be customized with the
<a href="#filterLabel"><code>filterLabel.<fieldName></code></a> parameter.
See the bigBed help page and <a target="_blank"
href="/goldenPath/help/bigBed.html#Ex3">example 3</a> for more information about creating
unique .as files for bigBed data.</P>
<P><B>Notes:</B><ul>
<li><code>filter.<fieldName></code> can be used multiple times with different
columns</li>
<li>Both integers and decimals (floats) are supported</li>
<li>Any column/field values that start with non-numerical characters will be treated
as zeros</li>
<li>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)</li>
<li>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)</li>
<li>In order for filters to work, the track must be "<code>type bigBed N +</code>" or
"<code>type bigBed N .</code>". Including the "+" (for bigBed+ tracks) or a
"." (for non-extended bigBed tracks) is required
<li>Filters are not supported in bed3 or bed4 files, even bed 3+x. The file must be
at least a bed5</li>
<li>By default, all bed tracks that are at least bed5 will have a score filter.
Enabling any of the <code>filter*.<fieldName></code> filter settings will disable
that default filter</li></ul></P>
<P><B>Examples:</B></P>
<pre>
filter.score 0</pre>
<P>In this example, filtering is being enabled for the field <code>score</code>. 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.</P>
<pre>
filter.score 300</pre>
<P>In this second example, we are enabling filtering on the same field <code>score</code>,
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.</P>
<pre>
filter.signal 300:400
filterByRange.signal on
filterLimits.signal 200:500</pre>
<P>In this example, we are enabling numerical filtering on the field <code>signal</code>.
<code>filterByRange.<fieldName></code> is also being enabled, allowing for filtering
between interval values, this also allows us to pass a range of values to the
<code>filter.<fieldName></code> 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.</P>
<pre>
filter.confidenceScore 6</pre>
<P>Example values in the <code>confidenceScore</code> field/column:</P>
<pre>
5
6 (Uncertain)
Unknown
7.0</pre>
<P>This example applies <code>filter.<fieldName></code> to values in the
field named <code>confidenceScore</code> containing some non-numerical values.
If items with the four values above were filtered with a minimum value of 6:
<P>
<code>5</code> - item would be removed as it is less than the filter value<br>
<code>6 (Uncertain)</code> - item should show up, as it would be interpreted as
"6"<br>
<code>Unknown</code> - item would be removed as it would be interpreted as 0<br>
<code>7.0</code> - item would appear as decimals are supported</P>
</DIV>
<DIV class="filterText"><span class="types bigBed"></span>
<div class="format">
<code>filterText.<fieldName> <default search string></code><BR>
<code>filterType.<fieldName> <wildcard/regexp></code><BR>
</div>
<P>There are a number of different filters available for bigBed data. See the
<a href="../hubQuickStartFilter.html" target="_blank">Filters Quick Start guide</a> for
more info. Note: for configurable features, like filters, an additional period
"." or plus "+" is required in the type declaration,
for instance <code>type bigBed 5 .</code> or <code>type bigBed 9 +</code>.</p>
<P><code>filterText.<fieldName></code> 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.</P>
<P><code>filterText.<fieldName></code> 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 <a target="_blank"
href="https://en.wikipedia.org/wiki/Regular_expression#POSIX_basic_and_extended">regular
expression rules</a>. For instance, with wildcard changed to a regexp type of search, putting in
<code>.*A\|B.*</code> will match any items with an A or B in it, while <code>.*[0-9]</code> will
match any item ending in a number. The optional settings <code>filterType.<fieldName></code>
may be added to switch the default from wildcard to regexp.</P>
<P>The filter label will be the description of the field as specified by the autoSql (.as) file.
This label can be customized with the <a
href="#filterLabel"><code>filterLabel.<fieldName></code></a> parameter.
See the bigBed help page and <a target="_blank"
href="/goldenPath/help/bigBed.html#Ex3">example 3</a> for more information about creating
unique .as files for bigBed data.</P>
<P><B>Notes:</B><ul>
<li><code>filterText.<fieldName></code> will treat all fields as strings. That is to say,
it can be enabled on entirely numerical fields, such as <code>chromStart</code>, if one is
looking to filter numerical values <strong>as text</strong></li>
<li>In order for filters to work, the track must be "<code>type bigBed N +</code>" or
"<code>type bigBed N .</code>". Including the "+" (for bigBed+ tracks) or a
"." (for non-extended bigBed tracks) is required
<li>Filters are not supported in bed3 or bed4 files, even bed 3+x. The file must be
at least a bed5</li>
<li>By default, all bed tracks that are at least bed5 will have a score filter. Enabling
any of the <code>filter*.<fieldName></code> filter settings will disable
that default filter</li></ul></P>
<P><B>Examples:</B></P>
<pre>
filterText.geneName *BRCA*</pre>
<P>In this example, we are applying a default filter on the field <code>geneName</code>
so that only items with BRCA in the <code>geneName</code> are visible. By default, this is
a wildcard search of <code>*BRCA*</code> which is equivelant to
a regexp search <code>.*BRCA.*</code>. The filter term can be freely changed in the track
setting page allowing users to filter on other values in the <code>geneName</code> field.</P>
<pre>
filterText.geneName *</pre>
<P>This example is enabling filtering on the same field as above, <code>geneName</code>,
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 <code>geneName</code> items will be filtered out of the data
unless the user specifies a value.</P>
<pre>
filterText.geneName \.1$
filterType.geneName regexp</pre>
<P>
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 <code>geneName</code> items that are version 1.</P>
</DIV>
<DIV class="filterValues"><span class="types bigBed"></span>
<div class="format">
<code>filterValues.<fieldName> <value1,value2,value3...></code><BR>
<code>filterValuesDefault.<fieldName> <value1,value2,value3...></code><BR>
<code>filterType.<fieldName> <single/singleList/multiple/multipleListOr/multipleListAnd/multipleListOnlyOr/multipleListOnlyAnd></code><BR>
</div>
<P>There are a number of different filters available for bigBed data. See the
<a href="../hubQuickStartFilter.html" target="_blank">Filters Quick Start guide</a> for
more info. Note: for configurable features, like filters, an additional period
"." or plus "+" is required in the type declaration,
for instance <code>type bigBed 5 .</code> or <code>type bigBed 9 +</code>.</p>
<P><code>filterValues.<fieldName></code> 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.</P>
<P>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 (<code>multiple</code>).</P>
<P>In order to choose the default selection behavior, the optional parameter
<code>filterType.<fieldName></code> 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 <code>filterType.fieldName multiple</code>. If the user should
only be able to select a single value,
<code>single</code> can be passed instead. Another option,
<code>multipleListAnd</code>, means that the user can select multiple categories,
but the filter will let pass only features where all of these categories are present.
</p>
<p>
Both <code>single</code> and <code>multiple</code> 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 <code>single</code> and <code>multiple</code>. 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 <code>singleList</code> or <code>multipleList</code>, or one of
the additional varieties of <code>multipleList</code> depending on the desired options.
</p>
<p>
<code>multipleListOr</code> and <code>multipleListAnd</code> both still let the user
override the type of combination manually in the user interface with a radio button.
If you specify <code>multipleListOnlyOr</code> or <code>multipleListOnlyAnd</code>
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.
</P>
<P>You can also choose which values to have selected by default using the
<code>filterValuesDefault.<fieldName></code> parameter. It can take a comma separated
list just like <code>filterValues.<fieldName></code>, and any items included will be
automatically selected. Not that the values need to be present in both settings.</P>
<P>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:</P>
<pre>filterValues.fieldName fieldValue1|alternativeName1,fieldValue2|alternativeName2...</pre>
<P>E.g. if the value in the bigBed field is <code>AML</code>, a setting
like <code>Acute Myeloid Leukemia|AML</code> will show <code>Acute Myeloid Leukemia</code>
in the user interface but will lead to the value <code>AML</code> being searched in the bigBed
field. This can reduce the size of the bigBed file a lot. See example below for more information.</P>
<P><B>Notes:</B><ul>
<li>Currently, all values must be stated individually</li>
<li>Value names must match exactly</li>
<li>By default, all bed tracks that are at least bed5 will have a score filter. Enabling any
of the <code>filter*.<fieldName></code> filter settings will disable that default
filter</li>
<li>In order for filters to work, the track must be "<code>type bigBed N +</code>" or
"<code>type bigBed N .</code>". Including the "+" (for bigBed+ tracks) or a
"." (for non-extended bigBed tracks) is required
<li>Filters are not supported in bed3 or bed4 files, even bed 3+x. The file must be
at least a bed5</li>
<li>There should not be any white spaces between declared items after commas, e.x.
"itemOne,itemTwo,itemThree"</li>
<li>The default label can be customized with the <a
href="#filterLabel"><code>filterLabel.<fieldName></code></a> parameter</li>
<li>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"</li>
</ul></P>
<P><B>Examples:</B></P>
<pre>
filterValues.OddEven Odd,Even</pre>
<P>In this simple example, we are applying <code>filterValues.<fieldName></code>
to the <code>OddEven</code> field, which designates either "Even"
or "Odd". We can then filter the data using the <code>OddEven</code>
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.</P>
<pre>
filterValues.OddEven Odd,Even
filterType.OddEven singleList</pre>
<P>In this follow up example, we are passing the <code>filterType.fieldName singleList</code>
parameter, which means that only one item in the <code>OddEven</code> field can be
chosen, in this case "Odd" or "Even". This removes the default that
allows multiple selections.</P>
<pre>
filterValues.OddEven Odd,Even
filterType.OddEven singleList
filterValuesDefault.OddEven Odd</pre>
<P>In this third example, we have added the <code>filterValuesDefault.fieldName</code>
parameter as well. Now the default filter when the hub is loaded will have the Odd value
preselected.</P>
<pre>
filterValues.annotationType DNA-BR,AS,BS,BSi</pre>
<P>In this example the filter is being applied to multiple values in the
<code>annotationType</code> field. We can then select from these values in the
<code>annotationType</code> 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.</P>
<pre>
filterValues.annotationType DNA-BR|DNA-binding region,AS|active site,BS|beta strand,BSi|binding site</pre>
<P>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 <code>annotationType</code> of
<code>DNA-BR</code>, we would select <code>DNA-binding region</code> from the interface menu.</P>
</DIV>
<DIV class="filterLabel"><span class="types bed bigBed"></span>
<div class="format"><code>filterLabel.<fieldName> <label></code></div>
<P>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:</P>
<P><ul><li><code>filter.<fieldName></code></li>
<li><code>filterText.<fieldName></code></li>
<li><code>filterValues.<fieldName></code></li></ul></P>
<P><B>Example:</B></P>
<pre>
filterValues.strand +,-
filterLabel.strand Strand (Orientation)</pre>
<P>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)".</P>
</DIV>
<DIV class="filterPriority"><span class="types bed bigBed"></span>
<div class="format"><code>filterPriority.<fieldName> <number></code></div>
<P>Sets the display order of filters on the track configuration page.
Filters are shown in ascending order of <code>filterPriority</code>
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.</P>
<P>The setting applies to any filter declared on <code><fieldName></code>,
regardless of which filter style is used. <code>filter.<fieldName></code>,
<code>filterText.<fieldName></code>, and
<code>filterValues.<fieldName></code> all share a single
<code>filterPriority.<fieldName></code> entry. The companion setting
<code>highlightPriority.<fieldName></code> does the same for
<code>highlight*.<fieldName></code>.</P>
<P>Numbers may be integers or decimals; only the relative ordering matters,
so values like <code>1 2 3</code> and <code>10 20 30</code> produce the same
layout, as do decimal values such as <code>0.5 1 1.5</code>. Filters of
different types appear in fixed sections in this order: numeric range
filters first, then text filters, then values (categorical) filters.
<code>filterPriority</code> orders the filters within each section.</P>
<P><B>Example:</B></P>
<pre>
filterValues.variation_type 3_prime_UTR_variant,5_prime_UTR_variant,...
filterValues.annot pLoF,missense,synonymous,other
filterValues.FILTER PASS,InbreedingCoeff,RF,AC0
filterPriority.variation_type 1
filterPriority.annot 2
filterPriority.FILTER 3</pre>
<P>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 <code>filterValues.*</code> lines appear in the
stanza or the alphabetical order of field names.</P>
</DIV>
<DIV class="highlight"><span class="types bed bigBed"></span>
<div class="format">
<code>highlight.<fieldName> <default integer></code><BR>
<code>highlightByRange.<fieldName> <off/on></code><BR>
<code>highlightLimits.<fieldName> <low>[:<high>]</code><BR>
</div>
<P>Similar to filters, There are a number of different highlights available for bigBed data. See the
<a href="../hubQuickStartFilter.html" target="_blank">Filters Quick Start guide</a> 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 <code>type bigBed 5 .</code> or <code>type bigBed 9 +</code>.</p>
<p>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.</p>
<P><B>Examples:</B></P>
<pre>
highlight.blockCount 4</pre>
<p>
In this example, highlighting is enabled for the <code>blockCount</code> field. We are passing
a default value of 4, which will highlight items where the blockCount is 4 or above.</p>
<pre>
highlight.score 300</pre>
<p>
In this example, highlighting is enabled for the <code>score</code> field. We are passing a
default value of 300, which will highlight all items with a score of 300 or above.</p>
<pre>
highlight.score 300:400
highlightByRange.score on
highlightLimits.score 200:500</pre>
<p>
In this example, we are enabling highlights for a range on the <code>score</code> field. The
<code>highlightByRange</code> setting is also enabled, allowing for highlighting between
interval values. Lastly, the <code>highlightLimits</code> are being used to modify the
accepted values between 200 and 500 as opposed to the default 0 to 1000.</p>
</DIV>
<DIV class="highlightText"><span class="types bigBed"></span>
<div class="format">
<code>highlightText.<fieldName> <default search string></code><BR>
<code>highlightType.<fieldName> <wildcard/regexp></code><BR>
</div>
<P>Similar to filters, There are a number of different highlights available for bigBed data. See the
<a href="../hubQuickStartFilter.html" target="_blank">Filters Quick Start guide</a> 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 <code>type bigBed 5 .</code> or <code>type bigBed 9 +</code>.</p>
<p>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.</p>
<P><B>Examples:</B></P>
<pre>
highlightText.name NM*</pre>
<p>
In this example, we are applying a highlight on the field <code>name</code> so any items that
start with <code>NM</code> are highlighted.</p>
<pre>
highlightText.name \.1$
highlightType.name regexp</pre>
<p>
In this example, we are enabling highlighting on the same name field, <code>name</code>
but declaring the search parameter with the <code>highlightType</code>. In this case, we are
using regular expression to highlight all items in the <code>name</code> field that are
version 1.</p>
</DIV>
<DIV class="highlightValues"><span class="types bigBed"></span>
<div class="format">
<code>highlightValues.<fieldName> <value1,value2,value3...></code><BR>
<code>highlightValuesDefault.<fieldName> <value1,value2,value3...></code><BR>
<code>highlightType.<fieldName> <single/singleList/multiple/multipleListOr/multipleListAnd/multipleListOnlyOr/multipleListOnlyAnd></code><BR>
</div>
<P>Similar to filters, There are a number of different highlights available for bigBed data. See the
<a href="../hubQuickStartFilter.html" target="_blank">Filters Quick Start guide</a> 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 <code>type bigBed 5 .</code> or <code>type bigBed 9 +</code>.</p>
<p>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.</p>
<P><B>Examples:</B></P>
<pre>
highlightValues.OddEven Odd</pre>
<p>
In this example, we are applying <code>highlightValues.<fieldname></code> to the
<code>OddEven</code> 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 <code>highlightType</code> setting, the
user can highlight both even and odd items at the same time.</p>
<pre>
highlightValues.OddEven Odd,Even
highlightType.OddEven singleList</pre>
<p>
In this example, we are passing the <code>highlightType.<fieldname> singleList</code> parameter,
which means only one options can be chosen -- "Even" or "Odd". This setting
removed the default setting that allows multiple selections.</p>
<pre>
highlighValuesDefault.OddEven Odd</pre>
<p>
In this third example, we are using the <code>highlightValuesDefault.<fieldname></code> 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.</p>
<pre>
highlightValues.annotationType DNA-BR,AS,BS,BSi</pre>
<p>
In this fourth example, we are applying a highlight to multiple values in the
<code>annotationType</code> field. We can select from these values in the
<code>annotationType</code> 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.</p>
<pre>
highlightValues.annotationType DNA-BR|DNA-binding region,AS|active site,BS|beta strand,BSi|binding site</pre>
<p>
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 <code>annotationType</code> of <code>DNA-BR</code>, on
the track settings page, we would select <code>DNA-binding region</code>.</p>
</DIV>
<DIV class="highlightColor"><span class="types bigBed"></span>
<div class="format">
<code>highlightColor <hexcolor></code><BR>
</div>
<P>Sets the default color for all of the various highlights defined in this stanza</P>
<P><B>Examples:</B></P>
<pre>
highlightColor #ff0000</pre>
<p>
In this example, we are using the <code>highlightColor <hex_color></code> to set the default
highlight color. With this setting, all highlight stripes will use the color red,
<code>#ff0000</code>.</p>
</DIV>
<DIV class="highlightPriority"><span class="types bed bigBed"></span>
<div class="format"><code>highlightPriority.<fieldName> <number></code></div>
<P>Sets the display order of highlights on the track configuration page.
Highlights are shown in ascending order of <code>highlightPriority</code> 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.</P>
<P>The setting applies to any highlight declared on <code><fieldName></code>,
regardless of which highlight style is used. <code>highlight.<fieldName></code>,
<code>highlightText.<fieldName></code>, and
<code>highlightValues.<fieldName></code> all share a single
<code>highlightPriority.<fieldName></code> entry.</P>
<P>Numbers may be integers or decimals; only the relative ordering matters,
so values like <code>1 2 3</code> and <code>10 20 30</code> produce the
same layout, as do decimal values such as <code>0.5 1 1.5</code>.
Highlights of different types appear in fixed sections in this order:
numeric range highlights first, then text highlights, then values
(categorical) highlights. <code>highlightPriority</code> orders the
highlights within each section.</P>
<P><B>Example:</B></P>
<pre>
highlightValues.variation_type 3_prime_UTR_variant,5_prime_UTR_variant,...
highlightValues.annot pLoF,missense,synonymous,other
highlightValues.FILTER PASS,InbreedingCoeff,RF,AC0
highlightPriority.variation_type 1
highlightPriority.annot 2
highlightPriority.FILTER 3</pre>
<P>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 <code>highlightValues.*</code>
lines appear in the stanza or the alphabetical order of field names.</P>
</DIV>
<DIV class="itemRgb"><span class="types bed bigBed bedDetail bedGraph bedLogR"></span>
<div class="format"><code>itemRgb on</code></div>
<P>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, <code>itemRgb</code>. 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,
<code>type bigBed 9</code>, or, <code>type bigBed 9+</code>, for additional
<A HREF="../../../FAQ/FAQformat.html#format1" target="_blank">non-standard columns</A>,
in the trackDb stanza for the bigBed file.</P>
<P>Note that the display of color is affected by the <code>maxItems</code> option.
When the track is zoomed to the point that the number of items to display
exceeds <code>maxItems</code>, 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 <code>itemRgb column</code>.
</P>
<P><B>Example:</B></P>
<pre> itemRgb on</pre>
</DIV>
<DIV class="colorFields"><span class="types bigBed bigGenePred"></span>
<div class="format">
<code>colorFields default="<label>" <fieldName1>="<label1>" <fieldName2>="<label2>" ...</code>
</div>
<P>
Enables a <b>Color by:</b> dropdown in the track controls that lets the user switch
among multiple pre-computed color schemes without leaving the track display.
</P>
<P>
Each entry is a <code>fieldName="Human Label"</code> pair. The field name must be an
extra bigBed field (defined in the track's <code>.as</code> file) that contains a
pre-computed <code>R,G,B</code> color string, the same format as the standard
<A onclick="jumpTo(this)" href="#itemRgb">itemRgb</A> field. The label in double
quotes is shown in the dropdown; if omitted, a label is derived automatically by
stripping a leading <code>colorBy</code> prefix and replacing underscores with spaces.
</P>
<P>
The special name <code>default</code> (with an optional label) represents the track's
existing <code>itemRgb</code> field (column 9) and is placed first in the dropdown.
When no <code>default=</code> entry is given, an unlabeled "Default" option
is added automatically.
</P>
<P>
Item coloring must be active for <code>colorFields</code> to work. It is active by
default on bigBed tracks with more than 9 fields; it is suppressed only if the track has
an explicit <code>color</code> setting or <code>itemRgb off</code>. The currently
selected scheme is stored in the cart variable <code><trackName>.colorField</code>.
When a non-default scheme is active, the track long label gains a
<em>(Coloring by: <label>)</em> suffix.
</P>
<P><B>Example:</B></P>
<pre>
colorFields default="Kozak strength" colorByEvidence="Evidence type" colorByHlaClass="HLA class"
</pre>
<P>This creates a three-option dropdown. <code>colorByEvidence</code> and
<code>colorByHlaClass</code> must be extra fields in the bigBed whose values are
<code>R,G,B</code> strings.</P>
</DIV>
<DIV class="maxItems"><span class="types bed bigBed broadPeak psl"></span>
<div class="format"><code>maxItems <integer></code></div>
<P>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 <code>type bigBed</code> tracks, this setting can never
be larger than the hg.conf setting bigBedMaxItems, which by default is 100,000 at UCSC.
</P>
<P>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.</P>
<P><B>Example:</B>
</P>
<pre> maxItems 25</pre>
</DIV>
<DIV class="maxWindowCoverage"><span class="types bed bigBed genePred bigGenePred psl bigPsl chain bigChain narrowPeak bigNarrowPeak broadPeak bam rmsk bedLogR vcf vcfTabix"></span>
<div class="format"><code>maxWindowCoverage <integer></code></div>
<p>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),
<code>maxWindowCoverage</code> will switch the track into density coverage plot when
the window contains more than the specified number of bases.</p>
<P><B>Example:</B></P>
<pre> maxWindowCoverage 10000000</pre>
<p>Browser images that show more than 10,000,000 bases will result in the track data
being displayed as a density coverage graph.</p>
</DIV>
<DIV class="maxWindowToDraw"><span class="types all"></span>
<div class="format"><code>maxWindowToDraw <integer></code></div>
<p>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),
<code>maxWindowToDraw</code> will trigger a choice to display a message
asking users to zoom in to a smaller region.</p>
<p>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 <code>maxWindowToDraw</code> setting allows you to force users to zoom in
as an overriding message will block out the data display. Unlike the <code>maxItems</code>
setting, which controls the display of vertical space and forces a display to dense
when the maximum number of items is exceeded, the <code>maxWindowToDraw</code>
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.</p>
<P><B>Example:</B></P>
<pre> maxWindowToDraw 10000000</pre>
<p>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
<code>zoom in to <= 10,000,000 bases to view items</code>.</p>
</DIV>
<DIV class="minGrayLevel"><span class="types bed bigBed broadPeak narrowPeak bigNarrowPeak bedLogR bigInteract"></span>
<div class="format"><code>minGrayLevel <1-9></code></div>
<P>When a bed track contains the standard
field <code>score</code>, and when that score is used
to present items in gray or color scale (see
<A onclick="jumpTo(this)" HREF="#">spectrum</A>),
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.</P>
<P><B>Example:</B></P>
<pre> minGrayLevel 4</pre>
<P>This sets the lowest scores to slightly
less than medium gray, while the highest scores appear black.</P>
</DIV>
<DIV class="noScoreFilter"><span class="types bed bigBed bedGraph bedLogR gvf"></span>
<div class="format"><code>noScoreFilter on</code></div>
<P>By default, bed
tracks with 5 or more standard bed fields that contain either a '<code>.</code>' or
a '<code>+</code>' in the type setting will be filterable on <code>score</code>;
that is, they will have an assumed setting of "<code>scoreFilter 0</code>". To turn
this old-style default off, include the "<code>noScoreFilter</code>" setting.</P>
<!-- DONNA -- what should they use instead? TIM ANSWERS: The implicit score filtering
bases upon '.' or '+' is confusing and not used by other item based tracks.
Ideally, score filtering is specifically requested by "scoreFilter #", which
would make "noScoreFilter on" the unneeded default. -- -->
<P><B>Example:</B></P>
<pre>
type bigBed 6 +
noScoreFilter on </pre>
</DIV>
<DIV class="useScore"><span class="types bed bigBed bigGenePred psl bigPsl"></span>
<div class="format"><code>useScore 1</code></div>
<P><I>Deprecated. Use <A onclick="return jumpTo(this);" HREF="#">spectrum</A> instead.</I></P>
<P>Shades each item by its <code>score</code> field, so low scores draw in light gray and
high scores draw near black. <code>spectrum on</code> does the same thing and is the
spelling to use in a new track. The Browser treats the two names as one setting, and
<code>scoreMin</code>, <code>scoreMax</code> and
<A onclick="return jumpTo(this);" HREF="#">minGrayLevel</A> tune both the same way.</P>
<P>In a trackDb file or a hub, any value turns the shading on, including
<code>useScore 0</code>, because the Browser only checks whether the setting is present.
In a custom track the value is read, and <code>0</code> turns the shading off.</P>
<P><B>Example:</B></P>
<pre> useScore 1</pre>
</DIV>
<DIV class="spectrum"><span class="types bed bigBed bigGenePred psl bigPsl"></span>
<div class="format">
<code>spectrum on</code><BR>
<code>scoreMax <integer></code><BR>
<code>scoreMin <integer></code></div>
<P>Replaces <code>useScore</code>.</P>
<P>If your track is a
<code>bed 5</code> or greater, then the standard bed <code>score</code>
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 <code>spectrum on</code>.
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:</P>
<UL>
<!-- The below statement about color and altColor is not accurate and removed 1/4/17
<LI> <code><A onclick="jumpTo(this)" HREF="#">color</A></code>
can be used to replace gray scale with a color scale</LI>
<LI> <code><A onclick="jumpTo(this)" HREF="#">altColor</A></code>
with <code><A onclick="jumpTo(this)" HREF="#">color</A></code> can vary items from
color to altColor</LI>
-->
<LI><code><A onclick="jumpTo(this)" HREF="#">minGrayLevel</A></code>
can be used to set the level of the lightest shade</LI>
<LI> <code>scoreMin</code>
and <code>scoreMax</code> can be used to define the lower and upper limits of
the range that will receive graded shading</LI></UL>
<p><b>Note:</b> The file type must be <b>type bigBed x</b> where x is at least
bigBed 5. If only <b>type bigBed</b> is used, the setting will not work as
it is assumed to be a bigBed 3.</p>
<P><B>Example:</B></P>
<pre>
spectrum on
scoreMin 700
scoreMax 900</pre>
<P>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.</P>
</DIV>
<DIV class="searchIndex"><span class="types bed bigBed"></span>
<div class="format"><code>searchIndex <str></code></div>
<P> 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 <A HREF="../bigBed.html#Ex3">HERE</A>
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 (<code>sort -k1,1 -k2,2n</code>), where
newer versions of the tool bedToBigBed (available
<a href="http://hgdownload.gi.ucsc.edu/admin/exe/">here</a>)
are enhanced to catch improper input.
<P><B>Example:</B></P>
<pre> searchIndex name</pre>
</DIV>
<DIV class="searchTrix"><span class="types bed bigBed"></span>
<div class="format"><code>searchTrix <url/relativePath></code></div>
<P> 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 <a href="../trix.html">here</a> for instructions on how
to build a TRIX file and a <a href="../hubQuickStartSearch.html">Searchable
Track Hub Quick Start Guide</a> here.</li>
<P><B>Example:</B></P>
<pre> searchTrix url or relative path </pre>
</DIV>
<DIV class="style"><span class="types bigBed"></span>
<div class="format"><code>style <heatmap></code></div>
<P>BigBed tracks can be created with a variety of extra fields. When created
according to the <a href="../heatmap.html">heatmap schema</a>, 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.</P>
<P><B>Example:</B></P>
<pre> style heatmap</pre>
</DIV>
<DIV class="thickDrawItem"><span class="types bed bigBed"></span>
<div class="format"><code>thickDrawItem <off/on></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> thickDrawItem on</pre>
</DIV>
<DIV class="bedFilter"><span class="types bed"></span>
<div class="format"><code>bedFilter on</code></div>
<P><I>FOR BEDS ONLY</I></P>
<P>
Activating this setting provides the bed filter type controls that allow you to filter
bed items by name with wildcard matching.
</P>
<!-- <P><I>TODO: this should
be rewritten to be allowed on any item based data source and not
exclude other filtering options as well. (That is, convert this
to filterByWild or filterByWildList)</I>
</P> -->
<P><B>Example:</B></P>
<pre> bedFilter on</pre>
<P>The bed track will be be filterable by the bed
item names.</P>
</DIV>
<DIV class="refUrl"><span class="types bam"></span>
<div class="format"><code>refUrl <url>/%s</code></div>
This setting specifies the RefGet reference server by a URL to retrieve genome sequences instead of
the default EBI CRAM Reference Registry. The <tt>%s</tt> is replaced by the RefGet MD5 checksum
that identifies the reference sequence.
</DIV>
<DIV class="bedNameLabel"><span class="types bed bigBed"></span>
<div class="format"><code>bedNameLabel <label></code></div>
<P>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:".</P>
<P><B>Example:</B></P>
<pre> bedNameLabel Gene Id</pre>
</DIV>
<DIV class="scoreLabel"><span class="types bed bigBed bigPsl bigGenePred bigNarrowPeak"></span>
<div class="format"><code>scoreLabel <label></code></div>
<P>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:".</P>
<P><B>Example:</B></P>
<pre> scoreLabel Log of binding Score * 1000</pre>
</DIV>
<DIV class="maxLimit"><span class="types bedGraph bigBarChart"></span>
<div class="format"><code>maxLimit <#></code></div>
<P>The upper limit of the data range in a track is specified with this setting.
</P>
<P><B>Example:</B></P>
<pre> maxLimit 5000</pre>
<P>
</DIV>
<DIV class="mergeSpannedItems"><span class="types bigBed"></span>
<div class="format"><code>mergeSpannedItems <on/off></code></div>
<P>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 <em>on</em> or <em>off</em> denotes what view should be
shown by default.</P>
<P>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.</P>
<P><B>Example:</B></P>
<pre> mergeSpannedItems on</pre>
<P>
</DIV>
<DIV class="linkIdInName"><span class="types bed bigBed"></span>
<div class="format"><code>linkIdInName on</code></div>
<P>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.
</P>
<P><B>Example:</B></P>
<pre> linkIdInName on</pre>
<P>
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 <A onclick="jumpTo(this)" HREF="#">directUrl</A>, where %s
is replaced by the identifier.
</P>
<p>
bigBed files are often created using the UCSC <tt>bedToBigBed</tt> 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 <tt>-tab</tt> option for
<tt>bedToBigBed</tt>. 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 <a href="../bigBed.html">bigBed Track Format</a> page.
</p>
</DIV>
<DIV class="baseColorUseSequence"><span class="types bed bigBed genePred psl bigPsl chain bigChain bam"></span>
<div class="format"><code>baseColorUseSequence <extFile {seqTable} /
hgPcrResult / lfExtra / nameIsSequence / seq1Seq2 / ss / 2bit ></code></div>
<!-- DONNA -- redo -->
<P>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.
</P>
<UL>
<LI>If <code>extFile</code> 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.
</LI>
<LI>If
<code>hgPcrResult</code> is specified then a PCR result is
used.</LI>
<LI>If <code>lfExtra</code>
is specified then the sequence of an item is found in the last
column of the table or remote file.</LI>
<LI>If
<code>nameIsSequence</code> is specified then the 4th column (<code>name</code> or
<code>sequence</code>) contains the sequence. (see
hg/lib/encode/tagAlign.as)</LI>
<LI>If <code>seq1Seq2</code>
is specified then the 7th & 8th columns (<code>seq1</code> and <code>seq2</code>)
contain the left and right pairs of the sequence. (see
hg/lib/encode/pairedTagAlign.as)</LI>
<LI>If <code>ss</code> is specified then a
user-provided blat sequence is looked for.</LI>
<LI>If <code>2bit</code> is specified then looks for sequence in the file specified
by the <code>otherTwoBitUrl</code> tag.
</UL>
</DIV>
<DIV class="baseColorUseCds"><span class="types bed bigBed genePred bigGenePred psl bigPsl"></span>
<div class="format"><code>baseColorUseCds <given></code></div>
<P>Specifies where coding sequence (CDS)
coordinates can be found (if any) so that codons can be drawn
when viewing a sufficiently small region.</P>
<P><B>Example:</B></P>
<pre> baseColorUseCds given</pre>
</DIV>
<DIV class="baseColorDefault"><span class="types bed bigBed genePred bigGenePred psl bigPsl chain bigChain bam"></span>
<div class="format"><code>baseColorDefault
<diffBases/diffCodons/itemBases/itemCodons/genomicCodons></code></div>
<P>Specifies the default drawing mode.
The <code>itemBases</code>, <code>itemCodons</code>, <code>diffBases</code> and
<code>diffCodons</code> options are applicable only if the track has sequence, as
specified by the <code>baseColorUseSequence</code> setting.
The <code>genomicCodons</code>, <code>itemCodons</code> and <code>diffCodons</code> are
applicable only if the track has CDS info, as specified by the <code>baseColorUseCds</code>
setting.</P>
</DIV>
<DIV class="baseColorTickColor"><span class="types bed bigBed psl bigPsl"></span>
<div class="format"><code>baseColorTickColor <lighterShade/contrastingColor></code></div>
<P>Sets the color of the tick marks that mark where item bases differ from the
genome. Those marks appear when the track draws with
<code>baseColorDefault diffBases</code> and the view is zoomed out past base
level. Their default color is red.</P>
<UL>
<LI><code>contrastingColor</code>: a color that stands out against the item
color, often white.</LI>
<LI><code>lighterShade</code>: a lighter version of the item color.</LI>
</UL>
<P>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
<A onclick="return jumpTo(this);" HREF="#">colorByStrand</A>. Without it the
setting is read and ignored, and the tick marks stay red.
<code>itemRgb</code> 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.</P>
<P><B>Example:</B></P>
<pre>
colorByStrand 0,0,200 200,0,0
baseColorDefault diffBases
baseColorTickColor contrastingColor</pre>
</DIV>
<DIV class="showDiffBasesAllScales"><span class="types bed bigBed genePred psl bigPsl chain bigChain bam"></span>
<div class="format"><code>showDiffBasesAllScales on</code></div>
<P>Show base differences for all zoom levels.</P>
<!-- DONNA -- how do you show the differences? -->
</DIV>
<DIV class="showDiffBasesMaxZoom"><span class="types bed bigBed genePred psl bigPsl chain bigChain bam"></span>
<div class="format"><code>showDiffBasesMaxZoom <basesPerPixel></code></div>
<P>Show annotations highlighting base or codon differences
only if current zoom level does not exceed
<code>basesPerPixel</code> (a float). <code>showDiffBasesAllScales</code>
should also be set to make this useful.</P>
</DIV>
<DIV class="showCdsAllScales"><span class="types psl bigPsl"></span>
<div class="format"><code>showCdsAllScales on</code></div>
<P>Show CDS for PSL tracks at all zoom levels.</P>
</DIV>
<DIV class="showCdsMaxZoom"><span class="types psl bigPsl"></span>
<div class="format"><code>showCdsMaxZoom <basesPerPixel></code></div>
<P>Use this setting (a float) to specify the maximum zoom-out allowed for displaying the CDS
for psl tracks.
In conjunction with this setting, <code>showCdsAllScales</code> must be set on and
<code>showDiffBasesMaxZoom</code>
should be set to a value not more than <code>showCdsMaxZoom</code> to make this
display configuration useful.</P>
<P><hr class="example" /><B>Examples:</B></P>
<pre>
baseColorDefault genomicCodons
baseColorUseCds given
showDiffBasesMaxZoom 10000.0
showCdsMaxZoom 10000.0
baseColorUseCds table hgFixed.transMapGeneUcscGenes
baseColorUseSequence lfExtra
baseColorDefault diffCodons
baseColorTickColor lighterShade
showDiffBasesAllScales .
showCdsAllScales . </pre>
<!-- DONNA -- redo
<P><I>TODO: Explain examples, expand option explanation</I></P>
DONNA -- finish -->
</DIV>
<DIV class="exonArrowsDense"><span class="types bed bigBed genePred bigGenePred psl bigPsl chain bigChain narrowPeak bigNarrowPeak broadPeak bam"></span>
<div class="format"><code>exonArrowsDense <off/on></code></div>
<P>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.</P>
</DIV>
<DIV class="itemDetailsHtmlTable"><span class="types bed genePred psl"></span>
<div class="format"><code>itemDetailsHtmlTable <table></code></div>
<P><I>NOT FOR HUBS. Supplemental table must be in local database.</I></P>
<P>Use this setting to specify a table, indexed by item name, that
contains an optional HTML fragment to display on the details page for
this item. The expected columns in the table are "name" and "html".</P>
<P><B>Example</B>:</P>
<pre> itemDetailsHtmlTable pseudoGeneDetails</pre>
</DIV>
<DIV class="itemImagePath"><span class="types bed bigBed"></span>
<div class="format"><code>itemImagePath <path> <suffix></code><BR>
<code>itemBigImagePath <path> <suffix></code></div>
<!-- <P><I>Not found in any of the Genome Browser trackDb.ra files. Custom or dataHub
setting.</I></P> -->
<P>Items can be
associated with images and the images can be made visible with
these two settings. The <code>itemImagepath</code> specifies a
URL path to a directory with image files named in the format
<code>{name}.{suffix}</code>. The name is retrieved from the table or remote data
file. This image will be displayed on the item detaiIs page. If
<code>itemBigImagePath</code> 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.</P>
<P><B>Example</B>:</P>
<pre>
itemImagePath images/myTrackImages png
itemBigImagePath http://bigImages.com/myTrackImages jpg </pre>
<P>When the user clicks
on a item named fred, then the item details page will show
the image <code>images/myTrackImages/fred.png</code> and will also
provide a link to a larger image at
<code>http://bigImages.com/myTrackImages/fred.jpg</code>.</P>
</DIV>
<DIV class="mafTrack"><span class="types bed"></span>
<div class="format"><code>mafTrack <trackName></code></div>
<P><I>NOT FOR HUBS</I></P>
<P>By specifying a multiple alignments track, the item details page
will illustrate the differences for that item across a number of species.
</P>
<P><B>Example:</B></P>
<pre> mafTrack multiz46way</pre>
</DIV>
<DIV class="nextExonText"><span class="types bed bigBed genePred bigGenePred psl bigPsl chain bigChain narrowPeak bigNarrowPeak broadPeak"></span>
<div class="format">
<code>nextExonText <str></code><BR>
<code>prevExonText <str></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre>
nextExonText "Next Match"
prevExonText "Previous Match" </pre>
</DIV>
<DIV class="showTopScorers"><span class="types bed bed5FloatScoreWithFdr bed5FloatScore"></span>
<div class="format"><code>showTopScorers #</code></div>
<P>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.</P>
<P><B>Example</B>:</P>
<pre> showTopScorers 20</pre>
</DIV>
<DIV class="bed_example"><span class="types bed bigBed broadPeak"></span>
<div class="format"><B>Examples of item base types</B></div>
<pre>
type bed 3 </pre>
<P>The simplest bed
format, with nothing more than a chromosome and the start and stop
coordinates for each bed item. There is nothing to configure.</P>
<pre>
type bed 6 +
colorByStrand 255,0,0 0,0,255
...
type bigBed 6 +
colorByStrand 255,0,0 0,0,255
... </pre>
<P>The type setting for
a bed and a bigBed are nearly identical. Here, both type settings
specify a track with the first 6 standard bed fields defined
(up to <code>strand</code>) and with additional fields defined
after those 6 (indicated by the '<code>+</code>'). The
<code>colorByStrand</code> setting configures the plus strand items
to be colored red, while the minus strand items are blue.</P>
<pre>
type bigBed 8 .
scoreFilter 700
scoreFilterLimits 100:1000
thickDrawItem on
spectrum on
scoreMin 700
scoreMax 900
color 0,0,128
minGrayLevel 4
... </pre>
<P>A bigBed track with
the first 8 standard bed fields (through <code>thickEnd</code>),
and no additional fields. The '<code>.</code>' tells
the Browser that the user may configure this track. The score
filter is explicitly declared to default to 700, and the defined
range of 100 - 1000 suggests there are no values of interest below 100.
This example also colors the description text blue and presents
a spectrum or gradation of darkness based upon the score range.
Items with a score or 700 or less are displayed as the lightest
and items with a score of 900 or more are the darkest. Finally,
the <code>minGrayLevel</code> ensures that the lightest shade is visible
to the user. No doubt the value of '4' was chosen after experimentation
with the Browser display.</P>
<pre>
type broadPeak
pValueFilter 2.0
pValueFilterLimits 0.0:300.0 </pre>
<P>This track is a
essentially a bed 6+3 format dataset, but it has been defined with
special features for ENCODE. The pValueFilter applies to a field
named pValue which is one of the 3 additional fields after the
standard 6.</P>
</DIV>
<DIV class="bigBed_example"><span class="types bigBed"></span>
<div class="format"><B>Examples of item base types</B></div>
<pre>
type bigBed 6 +
colorByStrand 255,0,0 0,0,255
... </pre>
<P>The type setting for
a bed and a bigBed are nearly identical. Here, both type settings
would define a track with the first 6 standard bed fields defined
(up to <code>strand</code>) and with additional fields defined
after those 6. Notice that plus strand items are colored red,
while minus strand items are blue.</P><BR>
<pre>
type bigBed 8 .
scoreFilter 700
scoreFilterLimits 100:1000
thickDrawItem on
spectrum on
scoreMin 700
scoreMax 900
color 0,0,255
minGrayLevel 4
... </pre>
<P>A bigBed track with
the first 8 standard bed fields (through <code>thickEnd</code>),
and no additional fields. The '<code>.</code>' is required to tell
the Browser that the user may configure this track. The score
filter is explicitly declared to default to 700, and an allowable
range for the score suggests there are no values below 100 worth
looking at. This example also sets the description text to blue and presents
a spectrum or gradation of darkness based upon the score range.
Items with score 700 or less are the lightest, and items with
score 900 or more are the darkest. Finally the lightest
shade is set to be not too light with the <code>minGrayLevel</code>
setting. No doubt 4 was chosen after experimentation to see how
it actually looks in the Browser.</P><BR>
</DIV>
<!-- - - - - - - - WIG/BIGWIG settings - - - - - - - -->
<DIV class="wig_intro">
<H3>wig, bigWig, and bedGraph: Signal graphing tracks </H3>
<P>
Another set of common track types is one that graphs a density signal along
the genome. The graph can be a continuously varying density plot or
one that displays a density signal in only certain regions. The
oldest and simplest of these is of <code>wig</code> format. This type has been
improved as a <code>bedGraph</code> and then greatly enhanced as a <code>bigWig</code>.
While there are differences among the formats, all support the basic
graph configuration controls. For detailed specifications of each
type and how to prepare them for display in the Genome Browser please
see the <A HREF="../../../FAQ/FAQformat.html">FAQ</A>.</P>
</DIV>
<DIV class="bigWig_intro">
<H3>bigWig: Signal graphing tracks </H3>
<P>Another set of common track types are those that graph a density signal along
the genome. The graph can be a continuously varying density plot or
one that displays a density signal in only certain regions. For data hubs
the most common signal track type is <code>bigWig</code>.
For detailed specifications of the <code>bigWig</code> remote data
file format and how to prepare it for display in the Genome Browser please
see: <A HREF="../bigWig.html">
http://genome.ucsc.edu/goldenPath/help/bigWig.html</A>.</P>
</DIV>
<DIV class="wig"><span class="types wig bigWig"></span>
<div class="format">
<code>type wig <low#> <high#></code><BR>
<code>type bigWig <#> <#></code></div>
<P>MariaDB tables of type
<code>wig</code> and remote data files of type <code>bigWig</code>
must declare the expected signal range for
the data.</P>
<P><em>Examples can be found below.</em></P>
</DIV>
<DIV class="bigWig"><span class="types bigWig"></span>
<div class="format">
<code>type bigWig <#> <#></code></div>
<P>The remote data files of type <code>bigWig</code>
must declare the expected signal range for
the data.</P>
<P><em>Examples can be found below.</em></P>
</DIV>
<DIV class="minLimit"><span class="types bedGraph"></span>
<div class="format">
<code>type bedGraph <field></code><BR>
<code>minLimit <#></code><BR>
<code>maxLimit <#></code></div>
<P>The bedGraph type
track has the same file format as a bed file, but is loaded into
the MariaDB database in a form that can be graphed. By default the
value to be graphed is the fifth standard bed field,
<code>score</code>; however, you can specify a different field to use.
Typically only the first 3 standard bed fields are included
(<code>chrom</code>, <code>start</code>, <code>stop</code>) and the fourth field
contains the signal value. The bedGraph track offers
a couple of important improvements over the wig track. In wig
tracks, the value of the signal is truncated into a single byte,
which is effective for graphing but fails at data storage. Also
the wig type was originally designed for fixed-size windowing, though
variations were added. The bedGraph type allows for variable
windowing and defining values even down to the base level. To be
clear, bigWig tracks are as versatile as bedGraphs. It is
only the wig format that suffers from these limitations.</P>
<P>On the other hand the storage density of wig, particularly the fixed step
variant, is vastly denser than bedGraph. In cases where the data is solely
meant for display, the 256 levels supported by wig more than suffice. For
single-base or even 10-base level resolutions, bedGraph is generally not practical
genome-wide. Note also that wigs converted to bigWigs do not suffer the reduced
precision of wigs loaded directly into the database. A bigWig based on fixedStep
wigs is the best way to represent dense graphs over the genome.</P>
<P>Note that the lower and upper limits of the bedGraph signal are not declared in the type,
but rather are declared with 2 separate settings, <code>minLimit</code> and
<code>maxLimit</code>.
</P>
<!-- <P><I>TODO: Deprecate minLimit/maxLimit.</I></P> -->
<P><em>Examples can be found below.</em></P>
</DIV>
<DIV class="alwaysZero"><span class="types wig bedGraph bigWig"></span>
<div class="format"><code>alwaysZero <off/on></code></div>
<P>When autoScale is set to "on" or "group" in the signal track,
additionally setting <code>alwaysZero</code> to "on" will ensure that the y=0
value will be in view at all times. Default: off.
</P>
</DIV>
<DIV class="autoScale"><span class="types wig bigWig bedGraph hic"></span>
<div class="format"><code>autoScale <off/on/group></code></div>
<P>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.</p>
<p>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 "<code>on</code>" in trackDb will default the track to
<code>auto-scale to data view</code>. The setting will independently
scale its y-axis based on the data within the track. Setting it to
"<code>group</code>" in trackDb will default the track to
<code>group auto-scale</code>. 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 "<code>off</code>" which will set the track to
<code>use vertical viewing range setting</code>.</P>
<P>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 <b>group</b> option declare the setting only in
the parent bigWig composite, not in the individual children tracks.</P>
<p>For Hi-C tracks, higher interaction scores are represented with more
intense colors. When this setting is set to "<code>off</code>", the score
at which the color reaches maximum intensity is a fixed value that can
be chosen with the <code>saturationScore</code> trackDb setting. When this
setting is set to "<code>on</code>", the maximum intensity score
changes dynamically depending on the values in the current viewing window.
The default value for this setting is "<code>on</code>". The
"<code>group</code>" option for autoScale is not available for Hi-C
tracks.</p>
<P><B>Example:</B></P>
<pre> autoScale on</pre>
</DIV>
<DIV class="graphTypeDefault"><span class="types wig bigWig bedGraph"></span>
<div class="format"><code>graphTypeDefault points</code></div>
<P>The signal can be
graphed as either "<code>points</code>" displayed at the signal
value, or the default space-filling "<code>bar</code>".</P>
<P><B>Example:</B></P>
<pre> graphTypeDefault points</pre>
</DIV>
<DIV class="maxHeightPixels"><span class="types wig bigWig bedGraph bigInteract"></span>
<div class="format"><code>maxHeightPixels <max:default:min></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> maxHeightPixels 100:16:8</pre>
<P>The browser will display the track as 16 pixels high, but the user
can scale it up to 100 pixels.</P>
</DIV>
<DIV class="maxWindowToQuery"><span class="types bigWig"></span>
<div class="format"><code>maxWindowToQuery <integer></code></div>
<P><I>For bigWigs only</I></P>
<P>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.</P>
</DIV>
<DIV class="negateValues"><span class="types wig bigWig bedGraph"></span>
<div class="format"><code>negateValues <on></code></div>
<P>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 <B>altColor</B> not <B>color</B> 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.</p>
</DIV>
<DIV class="spanList"><span class="types wig"></span>
<div class="format"><code>spanList <s1>[,s2…]</code></div>
<P><I>NOT FOR HUBS. For wig tracks only.</I></P>
<!-- DONNA - redo -->
Sets the data point span to just be the first span in table or list of spans in
the loaded table you can find the spans by doing:
"<code>select span from <table> group by span</code>".
Typically spanList is only one as the example shows. Rarely there may be
more: <BR>"<code>spanList 1,1000</code>".
Special efforts must be made to load extra
spans into the table for special purposes.</P>
<P><B>Example:</B></P>
<pre> spanList 1</pre>
</DIV>
<DIV class="setColorWith"><span class="types bigWig"></span>
<div class="format"><code>setColorWith <url/relativePath></code></div>
<P> 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.</p>
<p>An example of this in use can be seen with <a
href="https://raw.githubusercontent.com/ucscGenomeBrowser/kent/refs/heads/master/src/hg/makeDb/trackDb/human/cadd1_7.ra"
target="_blank">CADD 1.7</a>. It may also be helpful to reference our
<a href="https://raw.githubusercontent.com/ucscGenomeBrowser/kent/refs/heads/master/src/hg/makeDb/scripts/wigColorByColors/makeWigColorByRevelCadd.py"
target="_blank">previously used script</a> for a method on how to
generate this file based on score thresholds, colors, and an
input bigWig track. It is recommended to use
<code>windowingFunction minimum</code> alongside this setting
in order to prevent confusing coloring when items are averaged
at zoomed out levels.</p>
<P><B>Example:</B></P>
<pre> setColorWith url or relative path </pre>
</DIV>
<DIV class="smoothingWindow"><span class="types wig bigWig bedGraph"></span>
<div class="format"><code>smoothingWindow <off/1-16></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> smoothingWindow 4</pre>
</DIV>
<DIV class="transformFunc"><span class="types wig bigWig bedGraph bed"></span>
<div class="format"><code>transformFunc <NONE/LOG></code></div>
<P>The track's signal
can be presented in log scale with this user-configurable setting. Default: NONE.</P>
<P><B>Example:</B></P>
<pre> transformFunc LOG</pre>
</DIV>
<DIV class="logo"><span class="types bigWig"></span>
<div class="format"><code>logo on</code></div>
<P>Enables <a target="_blank" href="https://kundajelab.github.io/dynseq-pages/">
dynseq display</a>, 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 <code>logo</code>
dynseq display on the <a href="../bigWig.html#Ex4" target="_blank">bigWig</a> help page.</p>
<P><B>Example:</B></P>
<pre> logo on</pre>
</DIV>
<DIV class="logoMaf"><span class="types wig bigWig bigMaf"></span>
<div class="format"><code>logoMaf <url/relativePath></code></div>
<P>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.</p>
<P><B>Example:</B></P>
<pre> logoMaf https://hgdownload.gi.ucsc.edu/goldenPath/hg38/multiz470way/multiz470way.bigMaf</pre>
</DIV>
<DIV class="mouseOverFunction"><span class="types wig bigWig bedGraph"></span>
<div class="format"><code>mouseOverFunction <noAverage></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> mouseOverFunction noAverage</pre>
</DIV>
<DIV class="viewLimits"><span class="types wig bigWig bedGraph"></span>
<div class="format">
<code>viewLimits <lower:upper></code><BR>
<code>viewLimitsMax <lower:upper></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre>
viewLimits 5:20
viewLimitsMax0:100 </pre>
<P>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.</P>
</DIV>
<DIV class="wigColorBy"><span class="types wig"></span>
<div class="format"><code>wigColorBy <bedTable></code></div>
<P><I>NOT FOR HUBS. For wig tracks only.</I></P>
<P>Regions of the
graphed signal may be highlighted by color. Use a bed
table and the <code>color</code> settings to shade regions of the wig
track.</P>
<P><B>Example:</B></P>
<pre>
wigColorBy myBed
color 175,150,128
altColor 255,128,0 </pre>
<P>The bed-type table "myBed" is used to highlight
regions of graphed signal based upon the scores in that table.
The table may itself be a visible track, or may exist only for the
purpose of highlighting the signal track.</P>
</DIV>
<DIV class="windowingFunction"><span class="types wig bigWig bedGraph"></span>
<div class="format"><code>windowingFunction <mean/mean+whiskers/maximum/minimum></code></div>
<P>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 <code>mean+whiskers</code>
display, though the <code>maximum</code>, <code>mean</code>,
or <code>minimum</code> can alternatively be displayed.
The <code>mean+whiskers</code> 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.</P>
<P><B>Example:</B></P>
<pre> windowingFunction mean</pre>
<P>When zoomed out, this track will show the mean
signal but include shading representing higher scores. The user
may change this setting.</P>
</DIV>
<DIV class="yLineMark"><span class="types wig bigWig bedGraph"></span>
<div class="format">
<code>yLineMark <#></code><BR>
<code>yLineOnOff <off/on></code><BR>
<code>gridDefault on</code></div>
<P>It can be useful to
draw a line across the track's signal graph at some fixed y
coordinate. Do this by setting <code>yLineOnOff</code> to "on" and specifying the
y coordinate with <code>yLineMark</code>. These two settings are
configurable by the user. Defaults: off and 0.0.</P>
<P>Often confused with
these configurable settings is the <code>gridDefault</code>, 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.</P>
<P><B>Example:</B></P>
<pre>
yLineOnOff on
yLineMark 2.5
gridDefault on </pre>
<P>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.</P>
</DIV>
<DIV class="wig_example"><span class="types wig bigWig bedGraph"></span>
<div class="format"><B>Examples of signal graphing tracks</B></div>
<pre>
type wig 0 100
windowingFunction maximum
viewLimits 5:20
viewLimitsMax 0:100
maxHeightPixels 100:16:8
spanList 1
wigColorBy myBed
... </pre>
<P>This wiggle track is
composed of a MariaDB table and binary "wib" files that
are referenced in the table. The default windowing
function is the maximum signal in each window (under each pixel)
shown. The span of bases covered by each row in
the table is identical and can be gathered from the first row in
the table. The wiggle has colors supplied by the bed
table, myBed.</P>
<pre>
type bigWig -0.25 37.6
windowingFunction mean+whiskers
viewLimits 5:20
viewLimitsMax 0:37.6
maxHeightPixels 100:32:8
yLineOnOff on
yLineMark 15
gridDefault on
color 128,0,128
... </pre>
<P>This bigWig format
signal is held in a data file (which may be remote). The more
informative mean+whiskers windowing function is used by default in
this track, and the signal will be 32 pixels high in the Browser
image display. Note that even though the signal value may be
less than zero, that portion of the signal will not be
displayed. The Browser will display a line at y=0 and another at y=15, which
may be a threshold value for this signal. The track will be colored purple.</P>
<pre>
bedGraph 4
minLimit 0
maxLimt 20
viewLimits 5:8
viewLimitsMax 0:20
maxHeightPixels 100:16:8
... </pre>
<P>This bedGraph style signal track is composed of
a MariaDB table of items, each with a score defined in the fourth
column. While a wiggle track is usually composed of fixed
interval windows of signal (e.g. 200 bp), the bedGraph table may
define a signal in varying granularities of windows with or
without gaps.
</P>
</DIV>
<DIV class="bigWig_example"><span class="types bigWig"></span>
<div class="format"><B>Example of signal graphing tracks</B></div>
<pre>
type bigWig -0.25 37.6
windowingFunction mean+whiskers
viewLimits 5:20
viewLimitsMax 0:37.6
maxHeightPixels 100:32:8
yLineOnOff on
yLineMark 15
gridDefault on
color 128,0,128
... </pre>
<P>This bigWig format
signal is held in a data file (which may be remote). The more
informative mean+whiskers windowing function is used by default in
this track, and the signal will be 32 pixels high in the Browser
image display. Notice that even though the signal value may be
less than zero, that portion of the signal will not be
displayed. The Browser will display a line at y=0 and another at y=15, which
may be a threshold value for this signal. The track will be colored purple.</P><BR>
</DIV>
<!-- - - - - - - - GENEPRED settings - - - - - - - -->
<DIV class="genePred_intro">
<H3>genePred: Gene models and predictions</H3>
<P><I>NOT FOR HUBS. (None of the settings in this section apply to hubs.)</I></P>
<P>genePred is a variation of item-based tracks
designed especially for displaying gene
models. Gene models can be represented in <code>bed 12</code> or <code>bigBed 12</code>
type tracks, but the genePred table format allows for more detail,
such as distinguishing between transcript, coding region, and coding
vs. non-coding exons. Please refer to the
<A HREF="http:../../../FAQ/FAQformat.html#format9">FAQ</A>
for information on how to prepare genePred tables for inclusion in
the Genome Browser.</P>
</DIV>
<DIV class="genePred"><span class="types genePred"></span>
<div class="format"><code>type genePred [pepTable [mrnaTable]]</code></div>
<P>This type of track, based on MariaDB tables, is for gene models and predictions.
</P>
<UL>
<LI>pepTable - Optional protein sequence table</LI>
<LI>mrnaTable - Optional representative mRNA table</LI>
</UL>
<P>Note that missing
options can be filled with a '<code>.</code>' dot. Additional settings
described below allow the grouping of gene models into classes and
the coloring and filtering of the models by class.</P>
<P><em>Examples can be found below.</em></P>
</DIV>
<DIV class="geneClasses"><span class="types genePred bed"></span>
<div class="format"><I>Related settings:</I><BR>
<code>geneClasses <cl1 cl2...></code></div>
<P>Genes can be grouped into classes for the
purposes of coloring and filtering. The trick is how to
associate each named gene with its class. Use <code>geneClasses</code> to create a
list of all gene class names delimited by white space.</P>
</DIV>
<DIV class="gClass_"><span class="types genePred bed"></span>
<div class="format"><code>gClass_<xxx> <red,green,blue></code></div>
<P>Declare an RGB color for a named class.</P>
</DIV>
<DIV class="itemClassTbl"><span class="types genePred bed"></span>
<div class="format"><code>itemClassTbl <table></code></div>
<P>Declare a MariaDB table that will link classes
to named gene models.</P>
</DIV>
<DIV class="itemClassNameColumn"><span class="types genePred"></span>
<div class="format"><code>itemClassNameColumn <col></code></div>
<P>Optionally declare the column of the
itemClassTbl that will hold the genePred names. Default:
<code>name</code>.</P>
</DIV>
<DIV class="itemClassClassColumn"><span class="types genePred"></span>
<div class="format"><code>itemClassClassColumn <col></code></div>
<P>Optionally declare the column of the
itemClassTbl that will hold the class. Default: <code>class</code>.</P>
<P><hr class="example" /><B>Example:</B></P>
<pre>
geneClasses rRNA tRNA snRNA
gClass_rRNA 255,0,0
gClass_tRNA 0,255,0
gClass_snRNA 0,0,255
itemClassTbl rnaTypes
itemClassNameColumn rnaName
itemClassClassColumn rnaType </pre>
<P>In this genePred type track, RNA gene models
are divided into 3 classes that are colored red, green or blue.
The association of named gene models in the genePred table
with the three classes is defined in the "rnaType" table.
That table holds the RNA type in the "rnaType" column and the
gene name in the "rnaName" column.</P>
</DIV>
<DIV class="filterBy_genePred"><span class="types genePred"></span>
<div class="format"><code>filterBy <field1:title=[+]option1a...>
[field2:title=[+]opt2a...]</code></div>
<P>Filtering gene models by table column or even
itemClassTbl column can be achieved by this setting. Complete
description of this setting can be found in the
<A HREF="#filterBy">bed/bigBed</A> item-based track settings. Here is an example for
referencing the class as found in the table defined by <code>itemClassTbl</code>. Not all
track types will support externally referenced tables using <code>filterBy</code>
as <code>genePred</code> type does. But if you understand the CGI code that
performs the table select, then filterBy can provide a powerful extension to
the SQL selection used.</P>
<P><B>Example:</B></P>
<pre>
geneClasses rRNA tRNA snRNA
gClass_rRNA 255,0,0
gClass_tRNA 0,255,0
gClass_snRNA 0,0,255
itemClassTbl rnaTypes
itemClassClassColumn rnaType
filterBy rnaTypes.rnaType:Class=\
rRNA|Ribosomal_RNA{color:#FF0000},\
tRNA|Transfer_RNA{color:#00FF00},\
snRNA|Small_Nuclear_RNA{color:#0000FF} </pre>
<P>When gene models are
selected from the genePred table for display in the Browser,
their class is also selected from the "rnaTypes" table. Using the
<code>filterBy</code> setting creates a user selectable drop-down list box of
3 choices or "all". When the user filters by tRNA and snRNA (the
green and blue choices), the SQL select statement used by the
Browser will be limited by the where clause "<code>where
rnaTypes.rnaType in ('tRNA','snRNA')</code>".
</P>
</DIV>
<DIV class="autoTranslate"><span class="types genePred"></span>
<div class="format"><code>autoTranslate 0</code></div>
<P>By default, a
predicted protein translation is generated for a gene model when
a user views it on the details page. This feature may be blocked
by setting <code>autoTranslate</code> to zero.</P>
<P><B>Example:</B></P>
<pre> autoTranslate 0</pre>
<P> The genPred track
will NOT show auto-generated protein sequence, perhaps because
this track is for RNA genes.</P>
</DIV>
<DIV class="intronGap"><span class="types genePred bigGenePred psl bigPsl"></span>
<div class="format"><code>intronGap <#bases></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> intronGap 12</pre>
<P>Don't draw exon arrows when the gap between
exons is 12 bases or less.</P>
</DIV>
<DIV class="defaultLinkedTables"><span class="types genePred bigGenePred"></span>
<div class="format"><code>defaultLinkedTables <table1>[,table2...]</code></div>
<P>In hgTables, when selecting output fields,
display these all.joiner-linked tables by default.</P>
<P><B>Example:</B></P>
<pre> defaultLinkedTables kgXref</pre>
</DIV>
<DIV class="idXref"><span class="types genePred bigGenePred"></span>
<div class="format"><code>idXref <idColumn> <altIdColumn></code></div>
<P>By using this setting you can link alternative
names to the gene models found in a genePred. This is used by
the Table Browser to establish links to other tables.</P>
<P><B>Example:</B></P>
<pre>
track knownGenes
idXref kgAlias kgID alias </pre>
<P>The ID in the name column of the knownGenes
table is related to the alias found in the kgAlias table.</P>
</DIV>
<DIV class="oldToNew"><span class="types genePred"></span>
<div class="format"><code>oldToNew <tableName></code></div>
<P>In successive versions of gene models, it can
be helpful to map older genes to their newer models. This can be
done by providing a MariaDB table that maps the change, and then using
this setting to ensure the gene details page shows any changes.</P>
<P><B>Example:</B></P>
<pre>
track knownGeneOld5
oldToNew kg5ToKg6 </pre>
<P>The older version of UCSC Genes references
changes that are seen in the newer version.</P>
</DIV>
<DIV class="genePred_example"><span class="types genePred"></span>
<div class="format"><B>Examples of genePred tracks</B></div>
<pre>
type genePred
oldToNew kg5ToKg6
baseColorUseCds given
baseColorDefault genomicCodons
geneClasses coding nonCoding pseudo
itemClassTbl myClasses
gClass_coding 12,12,120
gClass_nonCoding 0,153,0
gClass_pseudo 255,51,255
filterBy myClasses.transcriptClass:Class=\
coding{color:#0C0C78},\
nonCoding{color:#009900},\
pseudo{color:#FF33FF}
... </pre>
<P>Gene model track
with defined classes and the option to filter by the color-coded
classes. Note the base level coloring option.</P>
<pre>
type genePred . mrna
url https://www.ncbi.nlm.nih.gov/IEB/Research/Acembly/av.cgi?db=hg17&l=$$
urlLabel AceView Gene Summary: </pre>
<P>This gene prediction
track has associated representative mRNAs found in the "mrna"
table. There is also an "AceView Gene Summary" url
presented on the details page.</P>
</DIV>
<!-- - - - - - - - BAM settings - - - - - - - -->
<DIV class="bam_intro">
<H3>bam/cram: Compressed Sequence Alignment/Map tracks</H3>
<P>The bam/cram format is an
indexed compressed data format for sequence alignments. It is ideal
for remote access of high-throughput sequence tags and is a native
output format for some high-throughput sequencing (HTS) aligners.
The format of bam data is data-file pairs, with an index in a separate file.
CRAM files are compressed versions of BAM files where the reference sequence is not included.
CRAM files should be listed as "type bam" in trackDb.
These are frequently remote datasets, not residing on the UCSC server. Please refer to
the <A HREF="../bam.html">BAM track format page</A> or <A HREF="../cram.html">CRAM track format page</A>
and the <A HREF="http://samtools.sourceforge.net/" TARGET=_blank>SAMtools website</A>
for information on how to create and deploy these remote data files
for inclusion in the Genome Browser.</P>
</DIV>
<DIV class="bam"><span class="types bam"></span>
<div class="format"><code>type bam</code></div>
<P>Declares configuration settings for a track of type bam. If the <code>bigDataUrl</code>
setting is included, that data at the location specified by that URL will be
displayed. Otherwise, a database table with a single column <code>fileName</code>
can specify the location of a local file or a URL.
If the database table includes a column <code>seqName</code>, a different
BAM file or URL can be specified for each assembly sequence.</P>
<P><em>Example can be found below.</em></P>
</DIV>
<DIV class="bamColorMode"><span class="types bam"></span>
<div class="format"><I>Related settings:</I><BR>
<code>bamColorMode <strand/gray/tag/off></code></div>
<P>There are numerous ways to color bam tracks
to highlight certain aspects of the data. All of these are
user-configurable.</P>
<P>Possible settings:</P>
<UL>
<LI><code>strand</code>: (Default) When colored by strand, mismatched bases are highlighted in
<B style="color:#FF0000;">bright red</B>, alignments on the reverse strand are
colored <B style="color:#880000;">dark red</B>, and alignments on the forward strand are
colored <B style="color:#000088;">dark blue</B>.</LI>
<LI><code>gray</code>: When colored in grayscale, items are shaded according to the
method specified by <code>bamGrayMode</code>: alignment quality, base qualities, or unpaired
ends.</LI>
<LI><code>tag</code>: 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 <code>bamColorTag</code> setting.</LI>
<!-- DONNA - don't understand what he means by "tag named here". TIM answers: I welcome a rewrite
here. In this section "tag" is being used in 2 ways. Sequence "tags" are the bam "items"
(akin to bed items). But "bamColorMode tag" refers to special "tags imbedded in the bam
data file. In both cases I was using the terminology of the art. High-throughput
sequencing often refers to sequence tags as the short stretches of 20-100bp that are
aligned to the reference genome. But the "YC" style codes imbedded in the bam file are
also referred to as tags by bam documentation. Honestly I do not know much about these
color tags in the data and tried to use wording that would be recognizable to a bam
file creator. -->
<LI><code>off</code>: No additional coloring.</LI>
</UL>
</DIV>
<DIV class="bamGrayMode"><span class="types bam"></span>
<div class="format">
<code>bamGrayMode <aliQual/baseQual/unpaired></code><BR>
<code>aliQualRange <min:max></code><BR>
<code>baseQualRange <min:max></code></div>
<P>When <code>bamColorMode</code> is set to "gray", you
can highlight one of the following:</P>
<UL>
<LI><code>aliQual</code>: (Default) The "alignment qualities" of the items are
shaded on a scale of 0 (lightest) to 99 (darkest). Use <code>aliQualRange</code>
to specify a default range.</LI>
<LI><code>baseQual</code>: "Base qualities" are shaded on a
scale of 0 (lightest) to 40 (darkest). Use <code>baseQualRange</code>
to specify a default range.</LI>
<LI><code>unpaired</code>: 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.</LI>
</UL>
<P>Refer to the
<A HREF="http://samtools.sourceforge.net/" TARGET=_blank>SAM format details</A>
for a discussion of these values.</P>
</DIV>
<DIV class="bamColorTag"><span class="types bam"></span>
<div class="format"><code>bamColorTag <XX></code></div>
<P>You can also use RGB data associated with
individual tags within the bam file itself. Refer to the
<A HREF="http://samtools.sourceforge.net/" TARGET=_blank>SAM documentation</A>
to understand how the RGB values are included.
When the <code>bamColorMode</code> is set to "tag", the standard "YC" tag
is used as the default. The default may be overridden with this setting.
</P>
</DIV>
<DIV class="noColorTag"><span class="types bam"></span>
<div class="format"><code>noColorTag .</code></div>
<P>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.</P>
<P><hr class="example" /><B>Examples:</B></P>
<pre>
bamColorMode strand
noColorTag </pre>
<P>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.</P>
<pre>
bamColorMode gray
bamGrayMode aliQual
aliQualRange 20:80 </pre>
<P>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.</P>
<pre>
bamColorMode tag
bamColorTag YC </pre>
<P>The bam file includes RGB values in the YC
field that will be used to color tags.</P>
<pre>
bamColorMode off </pre>
<P>No special coloring will be applied to items.</P>
</DIV>
<DIV class="bamSkipPrintQualScore"><span class="types bam"></span>
<div class="format"><code>bamSkipPrintQualScore .</code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> bamSkipPrintQualScore .</pre>
</DIV>
<DIV class="indelDoubleInsert"><span class="types bam psl bigPsl"></span>
<div class="format">
<code>indelDoubleInsert <off/on></code><BR>
<code>indelQueryInsert <off/on></code><BR>
<code>indelPolyA <off/on></code></div>
<P>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.</P>
<UL>
<LI> <code>indelDoubleInsert</code>: Use to highlight alignment gaps in both the target
(reference) and query (tag) sequence with double (<B>=</B>) lines.</LI>
<LI> <code>indelQueryInsert</code>: Use to highlight an insert in the query
sequence only by drawing an orange (<B style="color:orange;">|</B>)
or purple (<B style="color:purple;">|</B>) vertical line.
Orange lines show unalignable regions in the middle of a sequence,
and purple highlights regions at the end of the query sequence.</LI>
<LI><code>indelPolyA</code>: Use to highlight an apparently valid
poly-a tail by drawing a vertical green line (<B style="color:green;">|</B>).</LI>
</UL>
<P><B>Example:</B></P>
<pre>
baseColorUseSequence genbank
indelDoubleInsert on
indelQueryInsert on
indelPolyA on </pre>
</DIV>
<DIV class="minAliQual"><span class="types bam"></span>
<div class="format"><code>minAliQual <#></code></div>
<!-- <P><I>Not found in UCSC's trackDbs</I></P> -->
<P>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.</P>
<P><B>Example:</B>
</P>
<pre> minAliQual 20</pre>
</DIV>
<DIV class="pairEndsByName"><span class="types bam"></span>
<div class="format"><I>Related settings:</I><BR>
<code>pairEndsByName .</code></div>
<P>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.</P>
</DIV>
<DIV class="pairSearchRange"><span class="types bam"></span>
<div class="format"><code>pairSearchRange <#></code></div>
<!-- <P><I>Not found in UCSC's trackDbs</I></P> -->
<P>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.</P>
<P><hr class="example" /><B>Example:</B></P>
<pre>
pairedEndsByName .
pairSearchRange 5000 </pre>
<P>The dataset includes paired end tags. The maximum search range to join tag pairs
by name is capped at 5000.</P>
</DIV>
<DIV class="showNames"><span class="types bam"></span>
<div class="format"><code>showNames <on/off></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> showNames off</pre>
</DIV>
<div class="doWiggle"><span class="types bam"></span>
<div class="format"><code>doWiggle on</code></div>
<p>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."</p>
<p><b>Example:</b></p>
<pre> doWiggle on</pre>
</div>
<DIV class="bam_example"><span class="types bam"></span>
<div class="format"><B>Example of a bam track</B></div>
<pre>
type bam
bigDataUrl http://hgdownload/ucsc.edu/goldenPath/hg19/bambam/barneysSon.bam
pairEndsByName on
showNames off
bamColorMode off
bamGrayMode aliQual
indelDoubleInsert on
indelQueryInsert on
maxWindowToDraw 10000
... </pre>
<P>The bam data is held in the file "barneysSon.bam" which is at an
internet-accessible location. In addition to the data file, an
associated index file must reside at the same location. The index file must have the
same name as the data file, with ".bai" appended (e.g. <code>barneysSon.bam.bai</code>).</P>
</DIV>
<!-- - - - - - - - PSL settings - - - - - - - -->
<DIV class="psl_intro">
<H3>psl: Sequence alignments</H3>
<P><I>NOT FOR HUBS. (None of the settings in this section are available for hubs,
although it is likely that hub support will be added in the future.)</I></P>
<P>PSL is an alignment format in which the data is typically taken from files generated
by BLAT or psLayout. For further information about this format
please refer to the <A HREF="../../../FAQ/FAQformat.html#format2">FAQ</A> and
<A HREF="../hgTracksHelp.html#BLATAlign" TARGET="_blank">BLAT
documentation</A>.</P>
</DIV>
<DIV class="psl"><span class="types psl"></span>
<div class="format"><code>type psl <subtype> [otherDb]</code></div>
<P>The psl type tracks
require the specification of a subtype: <code>est</code>, <code>mrna</code>,
<code>protein</code> or <code>xeno</code>. The default, which is
represented as ".", is regular human mRNA. When the <code>xeno</code> subtype
is selected, an additional optional parameter may be set to specify the other species
assembly. If present, the alignments can be color-coded by
chromosome, and the chromosome and position (in kilobases) are shown
in the alignments label.</P>
<P><em>Examples can be found below.</em></P>
</DIV>
<DIV class="blastRef"><span class="types psl"></span>
<div class="format"><code>blastRef <assembly.table></code></div>
<P>Include a blastRef
to an assembly and table that contains geneId and position
retrievable by accession id. This information will be displayed
in the item name.</P>
<!-- DONNA - what is a blastRef? -->
<P><B>Example:</B></P>
<pre> blastRef hg17.blastKGRef02</pre>
</DIV>
<DIV class="colorChromDefault"><span class="types psl"></span>
<div class="format"><code>colorChromDefault off</code></div>
<P>For psl tracks of
subtype <code>xeno</code>, the alignments may be colored to indicated their
location in the other species. This setting is turned on by default
when the other species is specified in the <code>type psl</code>
setting. Use this setting to turn off chromosome coloring by default,
offering the user the choice to turn it on.
</P>
<P><B>Example:</B></P>
<pre>
type psl xeno loxAfr1
otherDb loxAfr1
colorChromDefault off </pre>
</DIV>
<DIV class="pred"><span class="types psl"></span>
<div class="format"><code>pred <assembly.table></code></div>
<P>Use the pred setting
to name an assembly and table containing protein sequence data for
the named alignments.</P>
<P><B>Example:</B></P>
<pre> pred hg18.blastKGPep04</pre>
</DIV>
<DIV class="transMapGene"><span class="types psl"></span>
<div class="format">
<code>transMapGene <assembly.table></code><BR>
<code>transMapInfo <table></code><BR>
<code>transMapSrc <assembly.table></code><BR>
<code>transMapTypeDesc <label></code></div>
<P>For alignment tracks generated using the TransMap cross-species alignment
algorithm, these settings are used to connect the transMap
detailed information with the alignments.
<UL>
<LI><code>transMapInfo</code>: Use to name the table in the current assembly that
ties an alignment with the source assembly and feature. </LI>
<LI><code>transMapSrc</code>: Use
to name the table in the source species assembly that contains
the details of the feature's source location.
<LI><code>transMapGene</code>: Use to name the table mapping the alignment
to gene names in the relevant species. Note that tables that are
common to multiple species should be put in the <code>hgFixed</code>
database. </LI>
<LI><code>transMapTypeDesc</code>: Use to
set a label for the type of transMapping that the alignment covers.
</P>
<P><B>Example:</B></P>
<pre>
transMapInfo transMapInfoUcscGenes
transMapSrc hgFixed.transMapSrcUcscGenes
transMapGene hgFixed.transMapGeneUcscGenes
transMapTypeDesc UCSC Gene
baseColorUseCds table hgFixed.transMapGeneUcscGenes
baseColorUseSequence extFile hgFixed.transMapSeqUcscGenes </pre>
<P>Note that several of the named tables are in
<code>hgFixed</code>, which is a database containing tables that
are shared by multiple species and assemblies. Also notice that
the same table that was named in <code>transMapGene</code> is
also used in this example for <code>baseColorUseCds</code>.
</P>
</DIV>
<DIV class="ucscRetroInfo"><span class="types psl"></span>
<div class="format"><code>ucscRetroInfo</code></div>
<P>For alignments
illustrating retrotransposition, use this setting to name a table
with details of the source location.</P>
<P><B>Example:</B></P>
<pre> ucscRetroInfo ucscRetroInfo1</pre>
</DIV>
<DIV class="psl_example"><span class="types psl"></span>
<div class="format"><B>Examples of psl alignment tracks</B></div>
<pre>
track ucscRetroAli1
type psl
ucscRetroInfo ucscRetroInfo1
baseColorDefault diffCodons
baseColorUseCds table ucscRetroCds
baseColorUseSequence extFile ucscRetroSeq1 ucscRetroExtFile1
indelDoubleInsert on
indelQueryInsert on
showDiffBasesAllScales .
showDiffBasesMaxZoom 10000.0
... </pre>
<P>In this example of
retroposed genes, mature mRNA has been aligned to the genome.
Notice there is a ucscRetroInfo table that describes the
non-transposed gene location. Also notice the use of the
baseColor settings for coloring the coding sequence (CDS).</P><BR>
<pre>
track protBlat
color 0,100,0
altColor 255,240,200
type psl protein
... </pre>
<P>In this example of
protein sequence blat results, the color of matching sequence is
green, while indels (in this case introns) are highlighted with
yellow.</P><BR>
<pre>
track rgdEst
spectrum on
color 12,12,120
type psl est
... </pre>
<P>This expressed
sequence tag example will have colored alignments that are graded
by a score thanks to "<code>spectrum on</code>". Though psl tracks do not have
a <code>score</code> column as part of the format, a score is
generated based upon matches and mismatches in the alignment. The
shading is even more subtle in that the weight given to inserts
varies depending upon whether the alignment is to the same or a
different species.</P><BR>
<pre>
track blastzTetNig1
color 0,0,0
altColor 50,128,50
spectrum on
type psl xeno tetNig1
otherDb tetNig1
... </pre>
<P>This psl track is for foreign species or "xeno"
alignments, in this case the sequence reads of a species of fish
aligned to human.</P>
</DIV>
<!-- - - - - - - - CHAIN/NETALIGN settings - - - - - - - -->
<DIV class="chain_intro">
<H3>chain and netAlign: paired species alignments</H3>
<P><I>NOT FOR HUBS. Nor are any of the settings in this section.</I></P>
<P>While "<code>chain</code>" and
"<code>netAlign</code>" formats are different, they often are paired to show two
different views of the same data.
</P>
<P>Chain tracks show
alignments of a "query" species to a "target" genome assembly. For
example, a chimp panTro2 can be aligned to the human hg19 genome.
The chain format allows for gaps in both sequences simultaneously.
When chains are viewed in the Browser, they show solid boxes for
alignments, separated by either single or double lines. The single
lines appear when an insertion occurs in the target or a deletion
occurs in the querying species. Double lines represent gaps in both
species that could result from a number of causes (e.g. an inversion
in one species). For more information on the "chain" format, please
refer to <A HREF="../chain.html">
http://genome.ucsc.edu/goldenPath/help/chain.html</A>.</P>
<P>A netAlign track
represents the best chain for each region in the target genome. The net
track will show the largest, highest scoring chains that span a
region. When these chains have gaps, they may be filled in
with additional chains, shown at a lower level, and gaps in these
chains may in turn be filled at an even lower level. These levels
help in visualizing genome rearrangements such as inversions and
retroposed elements. For more information on the netAlign
format, please refer to
<A HREF="../net.html">
http://genome.ucsc.edu/goldenPath/help/net.html</A>.</P>
</DIV>
<DIV class="chain"><span class="types chain"></span>
<div class="format">
<code>type chain <otherDb></code><BR>
<code>otherDb <otherDb></code></div>
<P>Tracks of type <code>chain</code> show sequence alignments
from another species to the reference genome. This type
requires the assembly database of the other species to be named in both the
type setting and in the "<code>otherDb</code>" setting.</P>
<P><em>Example can be found below.</em></P>
</DIV>
<DIV class="netAlign"><span class="types netAlign"></span>
<div class="format">
<code>type netAlign <otherDb> <otherChainTable></code><BR>
<code>otherDb <otherDb></code></div>
<P>Tracks of type netAlign show the best chains of
sequence alignments from another species to the reference genome.
Gaps are filled in levels, where possible. This type requires the
assembly database of the other species to be named in both the type setting and
in the "<code>otherDb</code>" setting.</P>
<P><em>Example can be found below.</em></P>
</DIV>
<DIV class="chainColor"><span class="types chain bigChain"></span>
<div class="format"><code>chainColor <scheme></code></div>
<P>By default chains are colored by the alignment
chromosome of the query species. This can be overridden with this
setting. The three options are:</P>
<UL>
<LI><code>Chromosome</code> - default</LI>
<LI><code>Normalized Score</code> - chains are colored by score</LI>
<LI><code>Black</code> - no coloring occurs</LI>
</UL>
<P>This setting affects
<code>chain</code> but not <code>netAlign</code> type tracks.</P>
<P><B>Example:</B></P>
<pre> chainColor Black</pre>
</DIV>
<DIV class="chainLinearGap"><span class="types chain netAlign bed psl"></span>
<div class="format"><code>chainLinearGap <loose/medium></code></div>
<P>The chainLinearGap setting should reflect the
"<code>-linearGap</code>" parameter used in axtChain to generate
the track. It represents the gap scoring matrix used and will be
either:</P>
<UL>
<LI><code>loose</code> - chicken/human linear gap costs</LI>
<LI><code>medium</code> - mouse/human linear gap costs</LI>
</UL>
<P>This setting is for both <code>chain</code> and <code>netAlign</code>
type tracks.</P>
<P><B>Example:</B></P>
<pre> chainLinearGap medium</pre>
</DIV>
<DIV class="chainMinScore"><span class="types chain netAlign bed psl"></span>
<div class="format"><code>chainMinScore <#></code></div>
<P>The chainMinScore setting should reflect the
"<code>-minScore</code>" parameter used in axtChain to generate the
track. It represents the score threshold for chains to be
included in the set. Default is 1000. This setting is for both
chain and netAlign type tracks.</P>
<P><B>Example:</B></P>
<pre> chainMinScore 5000</pre>
</DIV>
<DIV class="chainNormScoreAvailable"><span class="types chain bigChain netAlign bed"></span>
<div class="format"><code>chainNormScoreAvailable <yes/no></code></div>
<P>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 <code>yes</code>.
Item coloring based upon score as selected by the
<code>chainColor Normalized Score</code> setting also requires
this setting to be <code>yes</code>.</P>
<P><B>Example:</B></P>
<pre>
chainNormScoreAvailable yes
chainColor Normalized Score </pre>
</DIV>
<DIV class="matrix"><span class="types chain netAlign bed psl"></span>
<div class="format">
<code>matrix <size> <#,#,#,#,…></code><BR>
<code>matrixHeader <b1,b2,b3,b4></code><BR>
<code>$matrix</code> token in html.</div>
<P>The method for scoring and selecting chains and
generating netAligns relies upon a matrix of costs for base
substitutions. The matrix used in the generation of any given
paired alignment can vary depending upon such things as
evolutionary distance and the species involved. The matrix used
can be dynamically included in the HTML description using three
elements:</P>
<OL>
<LI>The HTML description must have the <code>$matrix</code> token in it.</LI>
<LI>The <code>matrix</code> to be used must be defined
with this trackDb setting. The format of this setting is the cell
size of the matrix which for DNA alignments is 16. This size is
separated by a space from the comma-delimited array of all the
values as the matrix cells are filled in left to right and top to
bottom.</LI>
<LI>The <code>matrixHeader</code> setting should be
used to define the order of base transitions in the matrix.
Typically it is “A,C,G,T “.</LI>
</OL>
<P><B>Example:</B></P>
<pre>
html chainNet
matrixHeader A,C,G,T
matrix 16 91,-114,-31,-123,\
-114,100,-125,-31,\
-31,-125,100,-114,\
-123,-31,-114,91 </pre>
<P>Here the <code>$matrix</code> token found in the
chainNet.html file will be replaced by the following matrix:</P>
<!-- Note that this table is within "settingsTable" so CSS must be defined here -->
<TABLE BORDER=1 CELLPADDING=7 class="matrixTable">
<TR><TH></TH><TH>A</TH><TH>C</TH><TH>G</TH><TH>T</TH></TR>
<TR><TH>A</TH><TD>91</TD><TD>-114</TD><TD>-31</TD><TD>-123</TD></TR>
<TR><TH>C</TH><TD>-114</TD><TD>100</TD><TD>-125</TD><TD>-31</TD></TR>
<TR><TH>T</TH><TD>-31</TD><TD>-125</TD><TD>100</TD><TD>-114</TD></TR>
<TR><TH>G</TH><TD>-123</TD><TD>-31</TD><TD>-114</TD><TD>91</TD></TR>
</TABLE>
</DIV>
<DIV class="chain_netAlign_example"><span class="types chain netAlign"></span>
<div class="format"><B>Examples of chain and netAlign tracks</B></div>
<pre>
track chainRheMac2
type chain rheMac2
otherDb rheMac2
color 0,0,0
altColor 100,50,0
matrix 16 91,-114,-31,-123,-114,100,-125,-31,-31,-125,100,-114,-123,-31,-114,91
matrixHeader A,C,G,T
chainMinScore 3000
chainLinearGap medium
html chainNet
...
track netRheMac1
type netAlign rheMac1 chainRheMac2
otherDb rheMac2
matrix 16 91,-114,-31,-123,-114,100,-125,-31,-31,-125,100,-114,-123,-31,-114,91
matrixHeader A,C,G,T
chainMinScore 3000
chainLinearGap medium
html chainNet
... </pre>
<P>Both the chain and netAlign tracks above are
for alignments of the query species/assembly <code>rheMac2</code>
against the target species determined by the database this trackDb
belongs to (e.g., human/hg19). Because the netAlign track is
based upon the data in the chain track, it references the track in its
type setting. Both tracks use the same matrix, chainMinScore and
linear gap settings. Methods to group these two tracks into a
single set that share settings are described later in this
document.</P>
</DIV>
<!-- - - - - - - - WIGMAF settings - - - - - - - -->
<DIV class="wigMaf_intro">
<H3>wigMaf: Multiple alignments</H3>
<P><I>NOT (currently) FOR HUBS. Nor are any of the settings in this section.</I></P>
<P>Multiple pairwise
alignments can be displayed with "<code>wigMaf</code>" type tracks. Tracks of
this type may actually be composed of multiple tables and data files.
The type setting will name the one MAF format table (with an
associated "maf" file in /gbdb). The optional "<code>wiggle</code>" setting will
name one or more wig format tables (with an associated "wib" files)
that contain conservation signals. Please refer to the
<A HREF="../../../FAQ/FAQformat.html#format9">FAQ</A>
for information on how to prepare multiple alignment format datasets.</P>
</DIV>
<DIV class="wigMaf"><span class="types wigMaf"></span>
<div class="format"><code>type wigMaf <minVal> <maxVal></code></div>
<P>A wigMaf type track
is composed both of MAF format alignment (loaded with hgLoadMaf).
The track may optionally include one or more conservation signals. The
signals must be within the same data range defined with the min
and max values in the type setting.
</P>
<P><em>Examples can be found below.</em></P>
</DIV>
<DIV class="frames"><span class="types wigMaf bigMaf"></span>
<div class="format"><code>frames <table/url></code></div>
<P>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 <a href="../bigMaf.html#frames_summary">bigMaf supporting files</a> on the help page.</p>
<P><B>Example:</B></P>
<pre> frames myCodonFrames</pre>
<pre> frames myCodonFrames.bb</pre>
</DIV>
<DIV class="irows"><span class="types wigMaf bigMaf"></span>
<div class="format"><code>irows off</code></div>
<P>By default, gaps in the non-reference species are filled with the placeholder
character:
<UL>
<LI><B>Single Line</B> '<code>-</code>': 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.</LI>
<LI><B>Double line</B> '<code>=</code>': 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.</LI>
<LI><B>Pale yellow coloring</B>:
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.</LI>
</UL>
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 <code>irows</code> to "<code>off</code>".
</P>
<P><B>Example:</B></P>
<pre> irows off</pre>
</DIV>
<DIV class="itemFirstCharCase"><span class="types wigMaf bigMaf"></span>
<div class="format"><code>itemFirstCharCase noChange</code></div>
<P>This controls if
species names in the multiple alignment should be capitalized in
the pairwise display. Set "<code>noChange</code>" to avoid forcing
the first letter to lower case.
</P>
<P><B>Example:</B></P>
<pre> itemFirstCharCase noChange</pre>
</DIV>
<DIV class="pairwiseHeight"><span class="types wigMaf bigMaf"></span>
<div class="format"><code>pairwiseHeight <#></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> pairwiseHeight 10</pre>
</DIV>
<DIV class="speciesCodonDefault"><span class="types wigMaf bigMaf"></span>
<div class="format"><code>speciesCodonDefault <species></code></div>
<P>This setting, which
is used with "frames", declares the default species
for the codon reading frame.</P>
<P><B>Example:</B></P>
<pre>
speciesCodonDefault hg19
frames myCodonFrames </pre>
</DIV>
<DIV class="speciesDefaultOff"><span class="types wigMaf bigMaf"></span>
<div class="format"><code>speciesDefaultOff <species1> [species2 ...]</code></div>
<P>To control which of
the stacked pairwise alignments are displayed or hidden by default, use
<code>speciesDefaultOff</code> 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).</P>
<P><B>Example:</B></P>
<pre> speciesDefaultOff galGal2 fr1 danRer1</pre>
</DIV>
<DIV class="speciesOrder"><span class="types wigMaf bigMaf"></span>
<div class="format"><I>Related settings:</I><BR>
<code>speciesOrder <species1> [species2 …]</code></div>
<P>Use <code>speciesOrder</code> to declare the order of the
stacked alignments. If there are many species in your track,
it may make sense to use the <code>speciesGroups</code> setting instead.</P>
</DIV>
<DIV class="speciesLabels"><span class="types wigMaf bigMaf"></span>
<div class="format"><code>speciesLabels <species1=newLabel1> [species2=newLabel2 …]</code></div>
<P>Use <code>speciesLabels</code> to specify new labels that map to sequence names.</P>
<P><B>Example:</B></P>
<pre> speciesLabels mm10=mouse_mm10 mm39=mouse_mm39</pre>
</DIV>
<DIV class="speciesGroups"><span class="types wigMaf bigMaf"></span>
<div class="format">
<code>speciesGroups <sgroup1> [sgroup2 …]</code><BR>
<code>sGroup_<sgroupN> <species1> [species2 …]</code></div>
<P>You can include a list of "clades"
to group the species into. This option is an alternative to
<code>speciesOrder</code>, used when there are many species. Each
<code>speciesGroup</code> in the list must have its own setting
(sGroup_<group>), followed by a list of species,
specified as for speciesOrder.</P>
<P><hr class="example" /><B>Examples:</B></P>
<pre>
speciesOrder panTro1 canFam1 mm5 rn3 \
galGal2 fr1 danRer1
speciesGroups Mammal Vertebrate
sGroup_Mammal mm9 rn4
sGroup_Vertebrate galGal2 fr1 danRer1</pre>
<P>Choose one of these two alternatives to display species.</P>
</DIV>
<DIV class="speciesUseFile"><span class="types wigMaf bigMaf"></span>
<div class="format"><code>speciesUseFile <cartVariableName></code></div>
<P><I>Deprecated</I></P>
<P>Much more rarely used, this setting can
replace <code>speciesOrder</code> and <code>speciesGroups</code>.
The value is not a file name. It is the name of a cart variable, and the
Browser reads the species list from the file that variable points to. That
file has to be one the Browser itself wrote for this user, so a track cannot
supply it directly; it arrives through the track's own configuration page.
The file holds one species name as the first word of each line.</P>
<P><B>Example:</B></P>
<pre> speciesUseFile myTrack.speciesList</pre>
</DIV>
<DIV class="summary"><span class="types wigMaf bigMaf"></span>
<div class="format"><code>summary <tableName/url></code></div>
<P>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 <code>hgLoadMafSummary</code> (SQL track) or
<code>mafToBigMafSummary</code> (bigMaf). For bigMaf, the value is assumed to be bigBed,
Read about <a href="../bigMaf.html#frames_summary">bigMaf supporting files</a> on the help page.</p>
<P><B>Example:</B></P>
<pre> summary hg17Maf8waySummary</pre>
</DIV>
<DIV class="treeImage"><span class="types wigMaf bigMaf"></span>
<div class="format"><code>treeImage <imageFile></code></div>
<P>The phylogenetic tree
can used to show the relations of the species in the multiple
alignment should be included as an image file. This path is
relative to the htdocs images directory (usually /images).</P>
<P><B>Example:</B></P>
<pre> treeImage phylo/hg17Maf8way.jpg</pre>
</DIV>
<DIV class="wiggle"><span class="types wigMaf"></span>
<div class="format"><code>wiggle <table1> <leftLabel1> <uiLabel1>
[table2 leftLabel2 uiLabelN ...]</code></div>
<P>Optionally more than
one conservation signal can be included with your MAF display by
using this setting. When you include conservation wiggles, you
can also include the standard settings for controlling signal type
tracks. The setting includes three parts, then (optionally)
additional sets of three, all delimited by white space. The first
table is the default. The <code>leftLabel</code> is used to
prefix the label "Cons" in the left label area of the Browser
image. The <code>uiLabel</code> is displayed in the track
configuration page. If only one table is listed, and no label is
present, the default label "Conservation" will be
displayed. The labels cannot contain spaces, but underscores (<code>_</code>)
will be translated to spaces in the display.</P>
<P>Note: directly
pairing the conservation signals within the wigMaf track is an
older way of doing things. It is easier to give users control of
what they want to see, by including your wigMaf track and separate
signal type tracks as subtracks within a composite track. See the
composite track description below.</P>
<P><B>Example:</B></P>
<pre>
wiggle phastCons8wayMammal Mammal Placental_Mammal \
phastCons8way Vertebrate Vertebrate </pre>
</DIV>
<DIV class="wigMaf_example"><span class="types wigMaf"></span>
<div class="format"><B>Examples of wigMaf tracks</B></div>
<pre>
track hg17Maf8way
type wigMaf 0.0 1.0
summary hg17Maf8waySummary
wiggle phastCons
treeImage phylo/hg17Maf8way.jpg
speciesOrder panTro1 canFam1 mm5 rn3 galGal2 fr1 danRer1
speciesDefaultOff galGal2 fr1 danRer1
irows off
pairwiseHeight 10
maxHeightPixels 100:16:8
viewLimits 0.5:0.9
viewLimitsMax 0.0:1.0
... </pre>
<P>This 8-way
multi-alignment for the hg17 human assembly is defined to include
a summary table, tree image and one wiggle table containing the
conservation score for the 8 species. Notice that the pairwise alignments
for the last three species are turned off by default, and each
pairwise alignment will have a height of 10 pixels. With few
species displayed by default, irows defaults to "off" as
well, which will result in a cleaner display. Since there is a
conservation wiggle, there are additional settings for that
signal.
</P><BR>
<pre>
track multiz46way
type wigMaf 0.0 1.0
summary multiz46waySummary
frames multiz46wayFrames
speciesCodonDefault hg19
itemFirstCharCase noChange
treeImage phylo/hg19_46way.gif
speciesGroups Primate Placental_Mammal Vertebrate
sGroup_Primate panTro2 gorGor1 ponAbe2 rheMac2 papHam1 calJac1 tarSyr1 micMur1 otoGar1
sGroup_Placental_Mammal tupBel1 mm9 rn4 …
sGroup_Vertebrate macEug1 monDom5 ornAna1 …
speciesDefaultOff panTro2 gorGor1 ponAbe2 papHam1 …
pairwiseHeight 10
... </pre>
<P>For this wigMaf
track, there is no wiggle defined. In this actual
example taken from the hg19 Genome Browser, the several conservation signals
displayed in concert with this multiple alignment are separate
signal-type tracks defined as part of the "Conservation"
composite track (see discussion of composites below). Notice
that the 46 species in this alignment are organized into clades
using the "<code>speciesGroups</code>" setting. Each clade has its
own "<code>sGroup</code>" setting to declare the order within (not
all species shown).</P>
</DIV>
<!-- - - - - - - - EXPRATIO settings - - - - - - - -->
<DIV class="expRatio_intro">
<H3>expRatio: Microarray expression data</H3>
<P><I>NOT FOR HUBS. Nor are any of the settings in this section.</I></P>
<P>Though
many microarray experiments have been superseded by high-throughput
sequencing (e.g., ChIP-seq) experiments, several microarray tracks
still exist. Further, microarray experiments can be the economical
or practical choice in many instances. The datasets for the built-in
microarray tracks in the Genome Browser are stored in bed 12+3 (bed
15) format that includes three additional fields: expCount, expIds,
and expScores. To display correctly in the Genome Browser,
microarray tracks require the setting of several attributes in the
trackDb file associated with the track's genome assembly. Each
microarray track set must also have an associated
microarrayGroups.ra configuration file that contains additional
information about the data in each of the arrays. Please refer to the
<A HREF="http://genomewiki.ucsc.edu/index.php/Microarray_track">microarray track</A>
section of the UCSC genomewiki
for information on how to prepare microarray tracks. In particular,
that document describes the format of the groupings.ra file that
must be associated with an expRatio track.</P>
<P>Note: The <code>expRatio</code> data formats are reused for the
<code>factorSource</code> type.</P>
</DIV>
<DIV class="expRatio"><span class="types expRatio"></span>
<div class="format"><code>type expRatio</code></div>
<P>Microarray data is
displayed in the Browser by <code>expRatio</code> type tracks.
The type requires additional settings: expScale, expStep and
groupings.</P>
<P><em>Example can be found below.</em></P>
</DIV>
<DIV class="expDrawExons"><span class="types expRatio"></span>
<div class="format"><code>expDrawExons on</code></div>
<P>If microarray data
includes gene model or blocks within items, then the data can
be viewed as exons and introns by setting <code>expDrawExons</code>
to on. The setting is configurable by the user.</P>
<P><B>Example:</B></P>
<pre> expDrawExons on</pre>
</DIV>
<DIV class="expScale"><span class="types expRatio bed"></span>
<div class="format"><code>expScale <#></code></div>
<P>Maximum expression
value.</P>
<P><B>Example:</B></P>
<pre> expScale 3.0</pre>
</DIV>
<DIV class="expStep"><span class="types expRatio bed"></span>
<div class="format"><code>expStep <#></code></div>
<P>Amount to step in
visible expression scale. A round number close to <code>expScale</code> divided
by 8 is best.</P>
<P><B>Example:</B></P>
<pre>
expScale 3.0
expStep 0.5 </pre>
</DIV>
<DIV class="expTable"><span class="types expRatio bed"></span>
<div class="format"><code>expTable <tableName></code></div>
<P>This setting specifies
the name of a table in the common <code>hgFixed</code>
database that contains names of experiments, etc.</P>
<!-- <P><I>TODO: Don't know where this gets read
in C code???</I></P> -->
</DIV>
<DIV class="groupings"><span class="types expRatio"></span>
<div class="format"><code>groupings <fileName></code></div>
<P>A microarray dataset
must refer to a specific set of configurations to load from the
microArrayGroups.ra file. Please refer to the
<A HREF="http://genomewiki.ucsc.edu/index.php/Microarray_track">microarray track</A>
section of the UCSC genomewiki
for detailed instructions on the location of this file and its
format. Use the "<code>groupings</code>" setting to point to a stanza keyed on
"<code>name</code>" in that file.</P>
<P><B>Example:</B></P>
<pre> groupings gnfHumanAtlas2Groups</pre>
</DIV>
<DIV class="expRatio_example"><span class="types expRatio"></span>
<div class="format"><B>Example of an expRatio track</B></div>
<pre>
track sestanBrainAtlas
type expRatio
expScale 3.0
expStep 0.5
expTable sestanBrainAtlasExps
groupings sestanBrainAtlasGroups
... </pre>
<P>This microarray dataset refers to groupings
defined in the "<code>gnfHumanAtlas2Groups</code>" stanza of the
makeDb/hgCgiData/Human/microarrayGroups.ra file.
</P>
</DIV>
<DIV class="extraDetailsTable"><span class="types bigBed"></span>
<div class="format"><code>extraDetailsTable <url/relativePath></code></div>
<p>This setting was renamed June 2022. Please use <a href="#detailsStaticTable">detailsStaticTable</a> instead.</p>
<p>
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:
<a href="http://hgdownload.gi.ucsc.edu/gbdb/hg38/gnomAD/v3.1/variants/v3.1.genomes.popTable.txt">http://hgdownload.gi.ucsc.edu/gbdb/hg38/gnomAD/v3.1/variants/v3.1.genomes.popTable.txt</a>, where
the strings such as "${AC_afr}" will be substituted for the data in that
field for the particular item from the bigBed.
</p>
<p>
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 <a href="#detailsDynamicTable">detailsDynamicTable</a>.
</p>
</DIV>
<DIV class="extraTableFields"><span class="types bigBed"></span>
<div class="format"><code>extraTableFields <fieldName1|table title,fieldName2|table title,...></code></div>
<p>This setting was renamed June 2022. Please use <a href="#detailsDynamicTable">detailsDynamicTable</a> instead.</p>
<p>
Tells the system that the data in <fieldName1,...> contains an <em>encoded</em> 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.
<p>An example of both formats is shown below, along with the
corresponding trackDb statements:<br>
<br>
trackDb line:
<pre>extraTableFields _jsonField1|JSON Title Example,tableField2|NON-JSON Title Example</pre>
the two columns from the bigBed (or external file):<br>
<pre>_jsonField1 tableField2
{key:val, key1: val1, key2: val2} key|val;key1|val1;key2|val2
</pre>
And when clicking on an item in the browser, the following would be displayed:<br>
<table class='bedExtraTbl'>
<tr><td>JSON Title Example</td><td>
<table class='bedExtraTbl'>
<tr><td>key</td><td>val</td>
<tr><td>key1</td><td>val1</td>
<tr><td>key2</td><td>val2</td>
</table></td></tr>
<tr><td>NON-JSON Title Example</td><td>
<table class='bedExtraTbl'>
<tr><td>key</td><td>val</td>
<tr><td>key1</td><td>val1</td>
<tr><td>key2</td><td>val2</td>
</table></td></tr>
</table>
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:
<pre>{"transcript1": {annot1: val1, annot2: val2}, "transcript2": {annot3: val3}}</pre>
then the following nested table would be shown on the details page:
<table class='bedExtraTbl'>
<tr><td>JSON Title Example</td><td>
<table class='jsonTable'>
<tr>
<td>transcript1</td><td>
<table class='jsonTable'>
<tr><td>annot1</td><td>val1</td></tr>
<tr><td>annot2</td><td>val2</td></tr>
</table>
</td>
</tr>
<tr>
<td>transcript2</td><td>
<table class='jsonTable'>
<tr><td>annot3</td><td>val3</td></tr>
</table>
</td>
</tr>
</table></td></tr>
</table>
</p>
</DIV>
<DIV class="detailsStaticTable"><span class="types bigBed"></span>
<div class="format"><code>detailsStaticTable <url/relativePath></code></div>
<p>
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:
<a href="http://hgdownload.gi.ucsc.edu/gbdb/hg38/gnomAD/v3.1/variants/v3.1.genomes.popTable.txt">http://hgdownload.gi.ucsc.edu/gbdb/hg38/gnomAD/v3.1/variants/v3.1.genomes.popTable.txt</a>, where
the strings such as "${AC_afr}" will be substituted for the data in that
field for the particular item from the bigBed.
</p>
<p>
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 <a href="#detailsDynamicTable">detailsDynamicTable</a>.
</p>
</DIV>
<DIV class="detailsDynamicTable"><span class="types bigBed"></span>
<div class="format"><code>detailsDynamicTable <fieldName1|table title,fieldName2|table title,...></code></div>
<p>
Tells the system that the data in <fieldName1,...> contains an <em>encoded</em> 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.
<p>An example of both formats is shown below, along with the
corresponding trackDb statements:<br>
<br>
trackDb line:
<pre>detailsDynamicTable _jsonField1|JSON Title Example,tableField2|NON-JSON Title Example</pre>
the two columns from the bigBed (or external file):<br>
<pre>_jsonField1 tableField2
{key:val, key1: val1, key2: val2} key|val;key1|val1;key2|val2
</pre>
And when clicking on an item in the browser, the following would be displayed:<br>
<table class='bedExtraTbl'>
<tr><td>JSON Title Example</td><td>
<table class='bedExtraTbl'>
<tr><td>key</td><td>val</td>
<tr><td>key1</td><td>val1</td>
<tr><td>key2</td><td>val2</td>
</table></td></tr>
<tr><td>NON-JSON Title Example</td><td>
<table class='bedExtraTbl'>
<tr><td>key</td><td>val</td>
<tr><td>key1</td><td>val1</td>
<tr><td>key2</td><td>val2</td>
</table></td></tr>
</table>
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:
<pre>{"transcript1": {annot1: val1, annot2: val2}, "transcript2": {annot3: val3}}</pre>
then the following nested table would be shown on the details page:
<table class='bedExtraTbl'>
<tr><td>JSON Title Example</td><td>
<table class='jsonTable'>
<tr>
<td>transcript1</td><td>
<table class='jsonTable'>
<tr><td>annot1</td><td>val1</td></tr>
<tr><td>annot2</td><td>val2</td></tr>
</table>
</td>
</tr>
<tr>
<td>transcript2</td><td>
<table class='jsonTable'>
<tr><td>annot3</td><td>val3</td></tr>
</table>
</td>
</tr>
</table></td></tr>
</table>
</p>
</DIV>
<DIV class="detailsScript"><span class="types bigBed"></span>
<div class="format"><code>detailsScript.<plotType>.<fieldName> <jsonConfig></code></div>
<p>
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.
</p>
<p>
The setting name has three dot-separated parts:
</p>
<ul>
<li><code><plotType></code> — determines which JavaScript module to load
(<code>hgc.<plotType>.js</code>) and which exported function to call.</li>
<li><code><fieldName></code> — 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.</li>
</ul>
<p>
The <code><jsonConfig></code> 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.
</p>
<p>
Multiple fields can be visualized by using multiple <code>detailsScript</code> settings
with different field names. Fields sharing the same <code><plotType></code> are
grouped together and passed to a single JavaScript function call.
</p>
<p>
The currently available plot type is <code>histogram</code>, which draws an SVG bar chart
from data encoded as space-separated <code>key=value</code> pairs (logfmt format).
The histogram plot type accepts the following JSON config keys:
<code>title</code> (chart heading) and <code>xLabel</code> (x-axis label).
</p>
<P><B>Example:</B></P>
<pre>
detailsScript.histogram.afrHist {"title":"AFR Allele Frequencies","xLabel":"Allele size (repeat copies)"}
detailsScript.histogram.eurHist {"title":"EUR Allele Frequencies","xLabel":"Allele size (repeat copies)"}
</pre>
<p>
In this example, the bigBed fields <code>afrHist</code> and <code>eurHist</code> contain
logfmt-encoded histograms such as <code>15=0.025 22=0.016 23=0.747 24=0.211</code>.
On the details page, each field's table row is replaced by an SVG bar chart drawn by
the <code>hgc.histogram.js</code> module.
</p>
</DIV>
<!-- - - - - - - - SNP settings - - - - - - - -->
<DIV class="snp_intro">
<H3>snp<em>NNN</em>: specialized subclass of BED 6 for dbSNP variants</H3>
<P><I>NOT FOR HUBS. Nor are any of the settings in this section.</I></P>
<P>This particular variant of bed 6, identified by table name,
is for UCSC's subset of
<A HREF="https://www.ncbi.nlm.nih.gov/projects/SNP/" TARGET=_BLANK>dbSNP</A>,
NCBI's database of short genetic variants.</P>
</DIV>
<DIV class="snp"><span class="types snp"></span>
<div class="format"><code>type bed 6 + # Track name starts with "snp"
followed by the 3-digit dbSNP build number </code></div>
<P>UCSC's subset of dbSNP could be described as "bed 6 + 19"
and is produced by a complex process starting with downloading
several database dump files and fasta files from dbSNP, and ending
with the creation of snp<em>NNN</em> and several auxiliary data
tables. This type is not supported as a custom track type.</P>
</DIV>
<DIV class="chimpDb"><span class = "types snp"></span>
<div class="format"><code>chimpDb <db></code></div>
<P>If chimp chains/nets were used to identify the chimp reference
assembly allele at the location homologous to the human SNP, this
specifies which chimp genome assembly was used, e.g. <code>panTro2</code>.</P>
</DIV>
-<DIV class="chimpMacaqueOrthoTable"><span class="types snp"></span>
+<DIV class="chimpMacaqueOrthoTable"><span class="types bed"></span>
<div class="format"><code>chimpMacaqueOrthoTable <table></code></div>
<P>If chains/nets from chimp and rhesus macaque were use to identify
the chimp or macaque reference assembly allele at the location
homologous to the human SNP, this specifies the database table
that contains the mapped alleles.</P>
</DIV>
-<DIV class="chimpOrangMacOrthoTable"><span class="types snp"></span>
+<DIV class="chimpOrangMacOrthoTable"><span class="types bed"></span>
<div class="format"><code>chimpOrangMacOrthoTable <table></code></div>
<P>If chains/nets from chimp, orangutan and rhesus macaque were use to identify
the chimp/orangutan/macaque reference assembly allele at the location
homologous to the human SNP, this specifies the database table
that contains the mapped alleles.</P>
</DIV>
-<DIV class="codingAnnoLabel_table"><span class="types snp"></span>
+<DIV class="codingAnnoLabel_table"><span class="types bed"></span>
<div class="format"><code>codingAnnoLabel_<table> <text></code></div>
<P><I>Deprecated; will probably be removed.</I>
This specifies a text label for display of <table>'s
predictions of a SNP's effect on a protein-coding gene.</P>
</DIV>
-<DIV class="codingAnnotations"><span class="types snp"></span>
+<DIV class="codingAnnotations"><span class="types bed"></span>
<div class="format"><code>codingAnnotations <table>[,table]</code></div>
<P><I>Deprecated; will probably be removed.</I>
This specifies one or more tables containing predictions of SNP
effects on protein-coding genes.</P>
</DIV>
-<DIV class="defaultGeneTracks"><span class="types snp"></span>
+<DIV class="defaultGeneTracks"><span class="types bed bigDbSnp"></span>
<div class="format"><code>defaultGeneTracks <genesTrack>[,genesTrack]</code></div>
<P>The details page of a SNP can display the predicted functional
affect on a gene from any genePred track.
Since there are often many gene tracks and models, the prediction
will depend upon the gene model used. The user has a chance to
choose from those available, but this setting establishes
a default gene track or tracks to base predictions on.</P>
<P><B>Example</B>:</P>
<pre> defaultGeneTracks knownGenes</pre>
</DIV>
-<DIV class="defaultMaxWeight"><span class="types snp"></span>
+<DIV class="defaultMaxWeight"><span class="types bed"></span>
<div class="format"><code>defaultMaxWeight <1|2|3></code></div>
<P>dbSNP assigns a weight of 1, 2 or 3 to each variant, depending
on how many distinct mappings a variant's flanking sequences have
to the genome.
If this is set to <code>1</code>, only uniquely mapped variants will
be displayed by default. If <code>2</code>, only uniquely mapped
variants and variants with a small number of duplicate mappings will
be displayed. If <code>3</code>, all variants will be shown regardless
of weight. Note: some tables such as snp<em>NNN</em>Common and
snp<em>NNN</em>Flagged contain only uniquely mapped variants, so this
setting has no effect on those tables.</P>
</DIV>
-<DIV class="hapmapPhase"><span class="types snp"></span>
+<DIV class="hapmapPhase"><span class="types bed"></span>
<div class="format"><code>hapmapPhase <II|III></code></div>
<P>The SNP details page looks for the SNP's ID in HapMap track tables
that have different names and contents depending on whether they
were loaded from HapMap phase II or HapMap phase III data.
(This setting is also used by HapMap SNPs tracks.)</P>
</DIV>
-<DIV class="macaqueDb"><span class="types snp"></span>
+<DIV class="macaqueDb"><span class="types bed"></span>
<div class="format"><code>macaqueDb <db></code></div>
<P>If macaque chains/nets were used to identify the macaque reference
assembly allele at the location homologous to the human SNP, this
specifies which macaque genome assembly was used, e.g. <code>rheMac2</code>.</P>
</DIV>
-<DIV class="orangDb"><span class="types snp"></span>
+<DIV class="orangDb"><span class="types bed"></span>
<div class="format"><code>orangDb <db></code></div>
<P>If orangutan chains/nets were used to identify the orangutan reference
assembly allele at the location homologous to the human SNP, this
specifies which orangutan genome assembly was used, e.g. <code>ponAbe2</code>.</P>
</DIV>
-<DIV class="snpExceptions"><span class="types snp"></span>
+<DIV class="snpExceptions"><span class="types bed"></span>
<div class="format"><code>snpExceptions <table></code></div>
<P>This specifies an auxiliary table that contains annotations of unusual
properties of variants. This setting applies only to versions prior to dbSNP
build 132; starting with build 132, exceptions are incorporated into the
main snp<em>NNN</em> table and an auxiliary table is no longer needed.</P>
</DIV>
-<DIV class="snpExceptionDesc"><span class="types snp"></span>
+<DIV class="snpExceptionDesc"><span class="types bed"></span>
<div class="format"><code>snpExceptionDesc <table></code></div>
<P>This specifies an auxiliary table that maps exception keywords
to one-sentence descriptions.</P>
</DIV>
-<DIV class="snpSeq"><span class="types snp"></span>
+<DIV class="snpSeq"><span class="types bed"></span>
<div class="format"><code>snpSeq <table></code></div>
<P>This specifies an auxiliary table that maps variant IDs to
file offsets at which flanking sequences are stored.</P>
</DIV>
-<DIV class="snpSeqFile"><span class="types snp"></span>
+<DIV class="snpSeqFile"><span class="types bed"></span>
<div class="format"><code>snpSeqFile <path></code></div>
<P>This specifies an auxiliary file that contains the flanking
sequences of each variant's representative submitted SNP.</P>
</DIV>
<DIV class="snp_example"><span class="types snp"></span>
<div class="format"><B>Example of a SNP track</B></div>
<pre>
track snp135Common
shortLabel Common SNPs(135)
longLabel Simple Nucleotide Polymorphisms (dbSNP 135) Found in >= 1% of Samples
group varRep
priority 99.0911
visibility dense
url https://www.ncbi.nlm.nih.gov/SNP/snp_ref.cgi?type=rs&rs=$$
urlLabel dbSNP:
snpSeq snp135Seq
snpExceptionDesc snp135ExceptionDesc
defaultGeneTracks knownGene
maxWindowToDraw 10000000
type bed 6 +
</pre>
<P>This track displays variants from dbSNP build 135 with Minor Allele Frequency (MAF)
of at least 1%. Flanking sequence file offsets come from the snp135Seq table,
descriptions of unusual properties are taken from the snp135ExceptionDesc table,
and effects of variants on protein-coding genes are shown with respect to the table
knownGene (UCSC Genes track) by default. If the viewed region is more than
10,000,000 base pairs, the data will not be loaded and drawn.</P>
</DIV>
<!-- - - - - - - - VCFTABIX settings - - - - - - - -->
<DIV class="vcfTabix_intro">
<H3>vcfTabix: Variant Call Format indexed by tabix</H3>
<P><A HREF="http://www.1000genomes.org/wiki/Analysis/Variant%20Call%20Format/vcf-variant-call-format-version-41"
TARGET=_BLANK>Variant Call Format</A> (VCF)
is a flexible and extendable line-oriented text format developed by the
<A HREF="http://www.1000genomes.org/" TARGET="_blank">1000
Genomes Project</A> for releases of single nucleotide
variants, indels, copy number variants and structural variants
discovered by the project. The format has been subsequently adopted by other large
projects. When a VCF file is compressed and indexed
using <A HREF="http://samtools.sourceforge.net/tabix.shtml" TARGET="_blank">tabix</A>
and then made web-accessible, the Browser will fetch only the portions of
the file necessary to display items in the viewed region. In other
words, this is a remote data file format, as are the BAM, bigBed and bigWig formats.
Please refer to the
<A HREF="../vcf.html">VCF and tabix track format page</A>
for a complete description of how to prepare and display VCF data.
</P>
</DIV>
<DIV class="vcfTabix"><span class="types vcfTabix"></span>
<div class="format"><code>type vcfTabix</code></div>
<P>If the <code>bigDataUrl</code> setting is included, the data at the location
specified by that URL will be
displayed. Otherwise, a database table with a single column <code>fileName</code>
can specify the location of a local file or a URL.
If the database table includes a column <code>seqName</code>, a different
VCF file or URL can be specified for each assembly sequence.</P>
<P><em>Example can be found below.</em></P>
</DIV>
<DIV class="hapClusterEnabled"><span class="types vcf vcfTabix"></span>
<div class="format"><code>hapClusterEnabled <true|false></code></div>
<P>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
<A HREF="../hgVcfTrackHelp.html">Configuring VCF tracks</A> page.
</P>
</DIV>
<div class="hapClusterMethod"><span class="types vcf vcfTabix"></span>
<div class="format"><code>hapClusterMethod <centerWeighted|fileOrder|treeFile <em>url</em>></code></div>
<p>Assuming <code>hapClusterEnabled</code> is <code>true</code>, this specifies how
genotypes are ordered for display:
<ul>
<li><code>centerWeighted</code>: 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.
<li><code>fileOrder</code>: Genotypes are displayed in the order in which they appear in
the VCF file.
<li><code>treeFile <em>url</em></code>: Genotypes are displayed in the order in which they
appear in <code><em>url</em></code>, a
<a href="https://en.wikipedia.org/wiki/Newick_format">Newick</a>-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.
</ul>
</p>
</div>
<DIV class="hapClusterColorBy"><span class="types vcf vcfTabix"></span>
<div class="format"><code>hapClusterColorBy <altOnly|function|refAlt|base></code></div>
<P>Assuming <code>hapClusterEnabled</code> is <code>true</code>,
this specifies one of three ways that reference and alternate alleles are colored:
<UL>
<LI><code>altOnly</code>: reference allele is white (invisible),
alternate allele is black. This emphasizes haplotypes with alternate alleles. (default)
<LI><code>function</code>: If the <code>geneTrack</code> 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.
<LI><code>refAlt</code>: reference allele is blue, alternate allele is red.
<LI><code>base</code>: A is red, C is blue, G is green and T is magenta.
</UL>
</P>
</DIV>
<div class="geneTrack"><span class="types vcf vcfTabix vcfPhasedTrio"></span>
<div class="format"><code>geneTrack <<em>track</em>></code></div>
<p>This is for use with <code>hapClusterColorBy function</code>; it specifies the gene track
to use when determining the functional effect of each variant.</p>
</div>
<DIV class="hapClusterTreeAngle"><span class="types vcf vcfTabix"></span>
<div class="format"><code>hapClusterTreeAngle <triangle|rectangle></code></div>
<P>Assuming <code>hapClusterEnabled</code> is <code>true</code>,
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):
<code>triangle</code> for the <B><</B> shape (default), <code>rectangle</code>
for the <B>[</B> shape.
</P>
</DIV>
<DIV class="labelFields"><span class="types bigBarChart bigBed bigGenePred bigNarrowPeak bigPsl"></span>
<div class="format"><code>labelFields <<EM>fieldName[,fieldName]</EM>></code></div>
<P>A list of fields from the bigBed based file that can be used as a label. The special value <B>none</B> can be specified if no labels are desired.
</P>
</DIV>
<DIV class="defaultLabelFields"><span class="types bigBarChart bigBed bigGenePred bigNarrowPeak bigPsl"></span>
<div class="format"><code>defaultLabelFields <<EM>fieldName[,fieldName]</EM>></code></div>
<P>A list of fields from the bigBed based file that should be used as a label by default. Only applicable if <B>labelFields</B> is set. If <B>defaultLabelFields</B> is not specified, the first field in labelFields is used as the default. The special value <B>none</B> can be specified if no label should be the default.
</P>
</DIV>
<DIV class="labelSeparator"><span class="types bigBed bigGenePred bigNarrowPeak bigPsl"></span>
<div class="format"><code>labelSeparator <<EM>text</EM>></code></div>
<P>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.
</P>
</DIV>
<DIV class="showSnpWidth"><span class="types halSnake"></span>
<div class="format"><code>showSnpWidth <<EM>integer</EM>></code></div>
<P>The maximum width (in bases) of a window where the halSnake will show SNPs between the reference and the other species.
</P>
</DIV>
<DIV class="hapClusterHeight"><span class="types vcf vcfTabix"></span>
<div class="format"><code>hapClusterHeight <<EM>N</EM>></code></div>
<P>Assuming <code>hapClusterEnabled</code> is <code>true</code>,
this specifies the height in pixels of the haplotype sorting display.
</P>
</DIV>
<DIV class="applyMinQual"><span class="types vcf vcfTabix"></span>
<div class="format"><code>applyMinQual <true|false></code></div>
<P>If <code>true</code>, then variants whose QUAL column contains a value less
than the <code>minQual</code> setting will not be displayed.
</P>
</DIV>
<DIV class="minQual"><span class="types vcf vcfTabix"></span>
<div class="format"><code>minQual <<EM>Q</EM>></code></div>
<P>
<P>Assuming <code>applyMinQual</code> is <code>true</code>,
this is the minimum QUAL value required for a variant to be displayed.
</P>
</DIV>
<DIV class="minFreq"><span class="types vcf vcfTabix"></span>
<div class="format"><code>minFreq <<EM>F</EM>></code></div>
<P>
The minimum minor allele frequency required for a variant to be displayed.
By default this is 0.0 (i.e. display all variants).
</P>
</DIV>
<DIV class="vcfDoFilter"><span class="types vcf vcfTabix vcfPhasedTrio"></span>
<div class="format"><code>vcfDoFilter <on/off></code></div>
<p>
Turn on/off the FILTER options available by default for VCF tracks
</p>
</DIV>
<DIV class="vcfDoQual"><span class="types vcf vcfTabix vcfPhasedTrio"></span>
<div class="format"><code>vcfDoQual <on/off></code></div>
<p>
Turns on/off the QUAL filter options available by default for VCF tracks
</p>
</DIV>
<DIV class="vcfDoMaf"><span class="types vcf vcfTabix vcfPhasedTrio"></span>
<div class="format"><code>vcfDoMaf <on/off></code></div>
<p>
Turns on/off the Minor Allele Frequency filter options available by default for VCF tracks
</p>
</DIV>
<DIV class="sampleMetadataFile"><span class="types vcf vcfTabix vcfPhasedTrio"></span>
<div class="format"><code>sampleMetadataFile <url></code></div>
<P>
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 <code>#sample</code>,
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.
</P>
<P>Example metadata file:</P>
<pre>
#sample Population Superpopulation Region
HG00096 GBR EUR Europe
HG00099 GBR EUR Europe
NA18939 JPT EAS East Asia</pre>
<P>Example trackDb entry:</P>
<pre>
track myVcf
type vcfTabix
bigDataUrl /path/to/myVcf.vcf.gz
sampleMetadataFile /path/to/sampleMeta.txt
...</pre>
</DIV>
<DIV class="vcfTabix_example"><span class="types vcfTabix"></span>
<div class="format"><B>Example of a VCF track</B></div>
<pre>
track myVcf
type vcfTabix
bigDataUrl http://myorg.edu/mylab/myVcf.gz
hapClusterEnabled false
maxWindowToDraw 3000000
... </pre>
<P>The data for this VCF track is stored in the remote file,
"myVcf.gz". That file is paired with a tabix-generated index file named
"myVcf.gz.tbi" found in the same remote location.
</P>
</DIV>
<!-- - - - - - - - VCFPHASEDTRIO settings - - - - - - - -->
<DIV class="vcfPhasedTrio_intro">
<H3>vcfPhasedTrio: VCF+tabix with extra metadata</H3>
<P>
After preparing a VCF file as noted in the <A HREF="vcfTabix">VCF</A> section, if your
data contains information on trios, you may want to use the vcfPhasedTrio track type to obtain
a haplotype display. For more information on this display, please see the
<A HREF="../vcf.html#trio">VCF Trio</a> documentation for a full explanation of the vcfPhasedTrio track type.
</P>
</DIV>
<DIV class="vcfPhasedTrio"><span class="types vcfPhasedTrio"></span>
<div class="format"><code>type vcfPhasedTrio</code></div>
<P>
There are no extra options that can appear on the type vcfPhasedTrio line.
</P>
</DIV>
<DIV class="vcfChildSample"><span class="types vcfPhasedTrio"></span>
<div class="format"><code>vcfChildSample <sampleName|altName></code></div>
<P>
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.
</P>
</DIV>
<div class="vcfParentSamples"><span class="types vcfPhasedTrio"></span>
<div class="format"><code>vcfParentSamples <sampleName|altName,sampleName|altName></code></div>
<P>
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.
</P>
</div>
<DIV class="vcfUseAltSampleNames"><span class="types vcfPhasedTrio"></span>
<div class="format"><code>vcfUseAltSampleNames <on/off></code></div>
<P>
Make the display use the aliases as the default labels for each haplotype lane instead of the
ID from the VCF.
</P>
</DIV>
<DIV class="vcfPhasedTrio_example"><span class="types vcfPhasedTrio"></span>
<div class="format"><B>Example of a VCF Phased Trio track</B></div>
<pre>
track myVcf
type vcfPhasedTrio
bigDataUrl http://myorg.edu/mylab/myVcf.gz
vcfChildSample NA123456|son
vcfParentSamples NA654321|mother,NA321654|father
vcfUseAltSampleNames on
... </pre>
<P>The data for this VCF track is stored in the remote file,
"myVcf.gz". That file is paired with a tabix-generated index file named
"myVcf.gz.tbi" found in the same remote location. "NA123456" is the ID of one
of the Genotype columns in the VCF, and the parent haplotypes will displayed
relative to their similarity to this sample.
</P>
</DIV>
<!-- - - - - - - - PGSNP settings - - - - - - - -->
<DIV class="pgSnp_intro">
<H3>pgSnp: Personal Genome SNP format</H3>
<P><I>NOT FOR HUBS. (None of the settings in this section apply to hubs.)</I></P>
<P>This format is used to
display SNPs from personal genomes. It is used for
the Genome Variants and Population Variants tracks. Please refer to
the <A HREF="../../../FAQ/FAQformat.html#format10">FAQ</A>
for information on how to prepare personal genome SNP datasets.</P>
</DIV>
<DIV class="pgSnp"><span class="types pgSnp"></span>
<div class="format"><code>type pgSnp</code></div>
<P>Personal Genome SNP
type tracks are essentially in "bed 4 + 3" format.
The fourth column, <code>name</code>, is filled with one or more variants
(including insertions and deletions) delimited with a '<code>/</code>'
character. The fifth column contains the number of variants found
in the <code>name</code> column, while the sixth and seventh columns contain
comma-delimited arrays of frequencies and scores respectively.
Files in this format can be loaded into MariaDB with hgLoadBed using
the "pgSnp.sql" schema.
</P>
<P>The browser image
displays variants as stacked boxes that show the frequency for
each variant, if that information is in the table. The details page for each variant item
computes any amino acid change if the variant is
in a coding region.</P>
</DIV>
<DIV class="pgPolyphenPredTab"><span class="types pgSnp"></span>
<div class="format"><code>pgPolyphenPredTab <table></code></div>
<P><I>Not supported for custom tracks</I></P>
<P>Auxiliary table with likelihoods of variant damage to proteins from polyPhen.</P>
</DIV>
<DIV class="pgSiftPredTab"><span class="types pgSnp"></span>
<div class="format"><code>pgSiftPredTab <table></code></div>
<P><I>Not supported for custom tracks</I></P>
<P>Auxiliary table with likelihood of variant damage to proteins from SIFT.</P>
</DIV>
<DIV class="pgSnp_example"><span class="types pgSnp"></span>
<div class="format"><B>Example of a Personal Genome SNP track</B></div>
<pre>
track mySnps
type pgSnp
... </pre>
<P>A personal genome SNPs track displaying single
nucleotide polymorphisms from the reference genome.
</P>
</DIV>
<!-- - - - - - - - ALTGRAPHX settings - - - - - - - -->
<DIV class="altGraphX_intro">
<H3>altGraphX: Alternate splicing gene model tracks</H3>
<P><I>NOT FOR HUBS.</I></P>
<P>Gene models with
alternate splicing can be displayed in the Browser with this type of
track. It supports no trackDb settings beyond the common ones.
</P>
</DIV>
<DIV class="altGraphX"><span class="types altGraphX"></span>
<div class="format"><code>type altGraphX</code></div>
<P>Alternate slicing gene models specialized track
used to show genome coverage.
</P>
</DIV>
<DIV class="altGraphX_example"><span class="types altGraphX"></span>
<div class="format"><B>Example of an altGraphX track</B></div>
<pre>
track sibTxGraph
shortLabel SIB Alt-Splicing
type altGraphX
url http://ccg.vital-it.ch/cgi-bin/tromer/tromergraph2draw.pl?species=H.+sapiens&tromer=$$
urlLabel SIB link:
idInUrlSql select name from sibTxGraph where id=%s
... </pre>
<P>The Swiss Institute of Biology's
alternative splicing track provides an external link via the <code>url</code>
setting. But the actual "tromer" term in the value
will be filled in with the results of a query to the sibTxGraph
table. With enough obscure settings, the Browser accomplishes
subtle things.</P>
</DIV>
<!-- - - - - - - - BEDDETAIL settings - - - - - - - -->
<DIV class="bedDetail_intro">
<H3>bedDetail: Text extended bed track</H3>
<P><I>NOT FOR HUBS.</I></P>
<P>This is an extension of
BED format. BED detail uses the first 4 to 12 columns of BED format,
plus 2 additional fields that are used to enhance the track details
pages. The first additional field is an ID, which can be used in
place of the name field for creating links from the details pages.
The second additional field is a description of the item, which can
be a long description and can consist of html, including tables and
lists.</P>
</DIV>
<DIV class="bedDetail"><span class="types bedDetail"></span>
<div class="format"><code>type bedDetail <#></code></div>
<P>Extended bed type
format that has a text description embedded in the table for each
item. The format can vary between 4 and 12 standard bed columns
plus two additional ones. The number of columns (including the 2
bedDetail specific columns) must follow the "<code>bedDetail</code>" term in
the type setting.</P>
<P><em>Example can be found below.</em></P>
</DIV>
<DIV class="bedDetail_example"><span class="types bedDetail"></span>
<div class="format"><B>Example of a bedDetail track</B></div>
<pre>
track microattrLoci
type bedDetail 14
itemRgb on
url https://www.ncbi.nlm.nih.gov/entrez/viewer.fcgi?db=nucleotide&sendto=t&extrafeatpresent=1&list_uids=$$
... </pre>
<P>This bedDetail contains details for each item
formatted for HTML display. In addition each item has an "id" as
distinct from the "name" and that id is used in the outside link
url displayed in the item details page.</P>
</DIV>
<!-- - - - - - - - CLONEPOS settings - - - - - - - -->
<DIV class="clonePos_intro">
<H3>clonePos: Genome coverage tracks</H3>
<P><I>NOT FOR HUBS.</I></P>
<P>This is a specialized
format track that is only used for showing the coverage in the human
genome. It supports no trackDb settings beyond the common ones.</P>
</DIV>
<DIV class="clonePos"><span class="types clonePos"></span>
<div class="format"><code>type clonePos</code></div>
<P>A specialized track used to show genome
coverage.
</P>
</DIV>
<DIV class="clonePos_example"><span class="types clonePos"></span>
<div class="format"><B>Example of a clonePos track</B></div>
<pre>
track clonePos
shortLabel Coverage
longLabel Clone Coverage/Fragment Position
type clonePos
altColor 180,180,180
... </pre>
<P>The Coverage track for the human genome will
vary in color between black and light gray, based upon the cloned
sequence coverage depth.</P>
</DIV>
<!-- - - - - - - - CTGPOS settings - - - - - - - -->
<DIV class="ctgPos_intro">
<H3>ctgPos: Physical map contigs tracks</H3>
<P><I>NOT FOR HUBS.</I></P>
<P>This is a specialized
format track that is used for "physical map contigs" on
the human genome. It supports no trackDb settings beyond the common
ones.</P>
</DIV>
<DIV class="ctgPos"><span class="types ctgPos"></span>
<div class="format"><code>type ctgPos</code></div>
<P>A specialized track used to show the locations
of contigs on the physical map.
</P>
</DIV>
<DIV class="ctgPos_example"><span class="types ctgPos"></span>
<div class="format"><B>Example of a ctgPos track</B></div>
<pre>
track ctgPos2
shortLabel GRC Map Contigs
type ctgPos
url none
... </pre>
<P>The GCR Map Contigs track would normally
generate a URL to NCBI, but in this case, the URL has been
explicitly blocked.</P>
</DIV>
<!-- - - - - - - - DOWNLOADSONLY settings - - - - - - - -->
<DIV class="downloadsOnly_intro">
<H3>downloadsOnly: Specialized track that contains only downloadable files</H3>
<P><I>NOT FOR HUBS.</I></P>
<P>The ENCODE tracks all
have a special directory and CGI support for downloading files. This
can be very helpful for organizing access to the often very large
number of downloadble files associated with an ENCODE track. There
are a handful of datasets that don't readily lend themselves for
visualization in our Browser but are nonetheless a necessary
component of the ENCODE data as a whole. Therefore, <code>downloadsOnly</code>
type was developed to provide easy access to these sets of
downloadable files.</P>
</DIV>
<DIV class="downloadsOnly"><span class="types downloadsOnly"></span>
<div class="format"><code>type downloadsOnly</code></div>
<P>A specialized track
that provides access to a set of downloadable files, and is
currently ENCODE only. A downloadsOnly type track does not get
visualized in the Browser.</P>
<P><em>Example can be found below.</em></P>
</DIV>
<DIV class="fileSortOrder_downloadsOnly"><span class="types downloadsOnly"></span>
<div class="format"><code>fileSortOrder ...</code></div>
<P>The fileSortOrder setting is required for
downloadsOnly type tracks. A complete description can be found in
composite tracks section of this document. It requires each file
to be defined as an object in the metaDb and each of those objects
to refer to a "composite" which will be the name of this track and
the directory name where the files are located. The
"<code>fileSortOrder</code>" defines the column and default sort order. The
user will be able to sort and filter the list of files.</P>
</DIV>
<DIV class="downloadsOnly_example"><span class="types downloadsOnly"></span>
<div class="format"><B>Example of a Downloads Only track</B></div>
<pre>
track wgEncodeUmassWengTfbsValid
type downloadsOnly
fileSortOrder cell=Cell_Line \
dccAccession=UCSC_Accession \
fileSize=Size \
fileType=File_Type \
dateSubmitted=Submitted \
dateUnrestricted=RESTRICTED<BR>Until
wgEncode 1
... </pre>
<P>The Browser will not provide visualization of
this track but will provide access to downloading any number of
files organized into a single group. The downloads page
presents those files in a table with a number of columns that are
sortable and possibly filterable. Much of the presentation and
organization relies upon settings established in the metaDb for
this track. However, the <code>fileSortOrder</code> setting has requested six
specific columns to be presented in the desired order.</P>
</DIV>
<!-- - - - - - - - ENCODEFIVEC settings - - - - - - - -->
<DIV class="encodeFiveC_intro">
<H3>encodeFiveC: Five C Chromatin interaction track</H3>
<P><I>NOT FOR HUBS.</I></P>
<P>This is a specialized
format track that was used for displaying long distance
chromatin/chromatin interaction evidence. Essentially a "<code>bed</code>"
type track displaying locations in the genome. The details page of
each location presents a list of other locations within the genome
that may have functional interactions.</P>
</DIV>
<DIV class="encodeFiveC"><span class="types encodeFiveC"></span>
<div class="format"><code>type encodeFiveC</code></div>
<P>A specialized track that was used to show the
locations where chromatin may have interactions with other
chromatin locations.
</P>
</DIV>
<DIV class="interTable"><span class="types encodeFiveC"></span>
<div class="format"><code>interTable <tableName></code></div>
<P>Each location found in the track's main table
should have associated regions defined in the interactions table
named with this setting. The interactions table format
is essentially a "bed 7 + 1".</P>
</DIV>
<DIV class="interTableKind"><span class="types encodeFiveC"></span>
<div class="format"><code>interTableKind <label></code></div>
<P>The table of interactions is presented on each
item's details page and is titled as "Top ___ interactions"</P>
</DIV>
<DIV class="encodeFiveC_example"><span class="types encodeFiveC"></span>
<div class="format"><B>Example of an encodeFiveC track</B></div>
<pre>
track encodeUw5cGM06990dS9013DhsLoci
type encodeFiveC
color 200,100,0
interTable encodeUw5cGM06990dS9013DhsInter
interTableKind TSS
... </pre>
<P>This Five C interactions track will be
displayed as colored items. The associated chromatin regions are
drawn from a second table. The kind of associations are
transcription start sites.</P>
</DIV>
<!-- - - - - - - - FACTORSOURCE settings - - - - - - - -->
<DIV class="factorSource_intro">
<H3>factorSource: Combined items tracks</H3>
<P><I>NOT FOR HUBS.</I></P>
<P>Factor source is not a
group track, but a track that is made from a group of sources, which
may themselves be Browser tracks. This is a specialized type of
"item" based track of "<code>bed 15</code>" format, the same format
used for type <code>expRatio</code>. Its purpose is to
display transcription factors as detected in multiple cell lines,
though it might be adaptable for any type of item that piles up
into overlapping locations and will belong to one of several
categories. However, this type was specifically designed for
combining transcription factor (TF) binding evidence from multiple
cell lines into a single track. As a bed type track, it consists of
items or regions where there is evidence of TF binding. To the left
of each item, the factor name is displayed, while to the right a
coded list of cell types where the evidence has been found is
displayed. Unlike most item-based tracks, a second table is required
to describe the cell lines. Use the program hgBedsToBedExp to create
the tables from a collection of simpler beds, one for each
transcription factor/cell interaction.</P>
</DIV>
<DIV class="factorSource"><span class="types factorSource"></span>
<div class="format"><code>type factorSource</code></div>
<P>A bed 15 based table
format with overlapping items. This is a specialized track type
designed for holding transcription factor binding evidence across
multiple cell lines. The format is the same as used for
microarray expression.</P>
<P><em>Example can be found below.</em></P>
</DIV>
<DIV class="sourceTable"><span class="types factorSource"></span>
<div class="format"><code>sourceTable <table></code></div>
<P>The factorSource type tracks need a secondary
table that holds descriptions of the sources. This is where cell
line abbreviations are declared and associated with actual cell
lines.</P>
</DIV>
<DIV class="inputTrackTable"><span class="types factorSource bed"></span>
<div class="format"><code>inputTrackTable <table></code></div>
<P>When viewing the details for a factorSource
track item (typically a TF binding site), additional information
about the cell line evidence can be displayed. This setting names
a table that will hold the additional information. It is used in
conjunction with the <code>inputTableFieldDisplay</code> setting.</P>
</DIV>
<DIV class="inputTableFieldDisplay"><span class="types factorSource bed"></span>
<div class="format"><code>inputTableFieldDisplay <f1> [f2...]</code></div>
<P>If there is an <code>inputTrackTable</code> defined with
your track, the fields that are to be displayed should be declared
with this associated setting.</P>
</DIV>
<DIV class="filterBy_factorSource"><span class="types factorSource"></span>
<div class="format"><code>filterBy <field1:title=[+]option1a...>
[field2:title=[+]opt2a...]</code></div>
<P>This setting provides user filtering of factorSource items by factor name.
The simplest use is to include a comma-separated list of all factor names in the track as
an argument to the setting.
A complete description of this setting can be found in the
<A HREF="#filterBy">bed/bigBed</A> item-based track settings.</P>
</DIV>
<DIV class="motifTable"><span class="types factorSource"></span>
<div class="format"><code>motifTable <table></code></div>
<P>
A <code>bed 6</code> table that holds motif regions
to highlight within factorSource items.</P>
</DIV>
<DIV class="motifMapTable"><span class="types factorSource"></span>
<div class="format"><code>motifMapTable <table></code></div>
<P> If motif names differ from or are not unique for factorSource item names
in the <code>motifTable</code>, this table can used to remap the names.
This table has a simple 2 column format: char(255) factor, char(255) motif.</P>
</DIV>
<DIV class="motifPwmTable"><span class="types factorSource bed6FloatScore bigBed"></span>
<div class="format"><code>motifPwmTable <table></code></div>
<P>When viewing the details of a factorSource track item containing
a binding motif in the <code>motifTable</code>, the
consensus motif sequence and sequence logo image can be displayed.
This setting names the table holding the position weight matrices
that provide this information.</P>
</DIV>
<DIV class="motifMaxWindow"><span class="types factorSource"></span>
<div class="format"><code>motifMaxWindow <integer></code></div>
<P>Display of highlighted motifs in a factorSource track can be limited using
this setting. In large genomic regions motifs are not well distinguished in
the display, and performance is improved by suppressing the feature.</P>
</DIV>
<DIV class="motifDrawDefault"><span class="types factorSource"></span>
<div class="format"><code>motifDrawDefault <on/off></code></div>
<P>If a factorSource track has a motifTable, this setting controls whether motifs
are drawn by default. It is also configurable by the user.</P>
</DIV>
<DIV class="factorSource_example"><span class="types factorSource"></span>
<div class="format"><B>Example of a factorSource track</B></div>
<pre>
track tfbsByCellLines
type factorSource
sourceTable myCellLines
inputTrackTable myCellLineAssociations
inputTableFieldDisplay cellType treatment lab
motifTable transfacMotif
motifPwmTable transfacMotifPwm
motifMapTable transfacMotifTarget
motifMaxWindow 30000
motifDrawDefault on
...</pre>
<P>This track will show transcription factor (TF)
binding evidence found in multiple cell lines. Each item represents
a particular TF, along with the cell lines that show
evidence of binding in that location. The secondary <code>sourceTable</code>
holds the definitions of each cell line abbreviation. A third
table is declared with <code>inputTrackTable</code> and carries details for
each cell line that should be seen in the Browser. When viewed in
item detail, 3 fields (cellType, treatment and lab) will be seen
for each cell associated with the particular TF binding location.</P>
</DIV>
<!-- - - - - - - - RMSK settings - - - - - - - -->
<DIV class="rmsk_intro">
<H3>rmsk: Repeat masking tracks</H3>
<P><I>NOT FOR HUBS.</I></P>
<P>This is a specialized
format track that is used only for the repeat-masking track. For
completeness it is being briefly described here. These tracks are
created created by using Arian
Smit's <A HREF="http://www.repeatmasker.org/" TARGET="_blank">RepeatMasker</A>
program, which screens DNA sequences for interspersed repeats and low
complexity DNA sequences.</P>
</DIV>
<DIV class="rmsk"><span class="types rmsk"></span>
<div class="format"><code>type rmsk</code></div>
<P>The repeat masker
tracks contain uniquely formattted data for the special function
of repeat-masking.
</P>
<P><em>Example can be found below.</em></P>
</DIV>
<DIV class="rmsk_example"><span class="types rmsk"></span>
<div class="format"><B>Example of a Repeat Masking track</B></div>
<pre>
track rmsk
spectrum on
type rmsk
maxWindowToDraw 10000000
... </pre>
<P>The repeat masker track will have individual
repeat items shaded by a measure of how exact a repeated element
is withing the stretch of repetition. This track is restricted to
display at less than 10 million base resolution.
</P>
</DIV>
<!-- - - - - - - - SNAKE settings - - - - - - - -->
<DIV class="snake_intro">
<H3>snake: Self referencing alignment tracks -
<I>EXPERIMENTAL</I></H3>
<P><I>NOT FOR HUBS.</I></P>
<P>This is a specialized
format track that shows the snaking course of bi-directional and
overlapping alignments. This format can help illustrate inversion-type
rearrangements that align to the plus strand, then the minus strand,
and again to the plus strand. It can also be used to illustrate overlapping
alignments, such as when a duplication has occurred compared to the
reference genome.</P>
</DIV>
<DIV class="snake"><span class="types snake"></span>
<div class="format">
<code>type snake <db></code><BR>
<code>otherDb <otherDb></code></div>
<P>A specialized track
used to show the path of snaking alignments that represent
chromosomal rearrangements, duplications and inversions. Since
this type is almost always a mapping between two species or two
assemblies of the same species, the type must also declare that
species/assembly by database name.</P>
<P>As with chains and netAligns, which typically show mappings between two assemblies,
the "<code>otherDb</code>" setting is also needed to declare which other genome and assembly
the data in this track represents.</P>
</DIV>
<DIV class="snake_example"><span class="types snake"></span>
<div class="format"><B>Example of a snake track</B></div>
<pre>
track snakeMm9
type snake mm9
otherDb mm9
color 100,50,0
altColor 255,240,200
spectrum on
... </pre>
<P>This snake track will illustrate chromosome
rearrangements that have occurred on the mouse mm9 genome as seen
when it is aligned to the human genome.
</P>
</DIV>
<!-- - - - - - - - bigInteract settings - - - - - - - -->
<DIV class="bigInteract_intro">
<H3>bigInteract: Pairwise interactions</H3>
<P>
The bigInteract format stores interactions between pairs of regions in the genome.
BigInteract files are created using the program bedToBigBed with a special
AutoSQL file that defines the fields. The resulting files are in an indexed binary format
that supports efficient remote access, so the file can be hosted on your web accessible server
and displayed at UCSC.
For the complete bigInteract format definitions please see the
<A HREF="../interact.html">bigInteract help page</A>.</P>
</DIV>
<DIV class="interactDirectional"><span class="types bigInteract"></span>
<div class="format"><code>interactDirectional <true|offsetSource|offsetTarget|clusterSource|clusterTarget></code></div>
<P>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.
</P>
<P>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.
</P>
</DIV>
<DIV class="interactUp"><span class="types bigInteract"></span>
<div class="format"><code>interactUp <true|false></code></div>
<P>This setting flips the curved full visibility display so that the peak of the curves is 'up' (hills instead of valleys).
</P>
</DIV>
<DIV class="interactMultiRegion"><span class="types bigInteract"></span>
<div class="format"><code>interactMultiRegion <true|padding></code></div>
<P>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.
</P>
</DIV>
<DIV class="detailsBoxesEnabled"><span class="types bigInteract"></span>
<div class="format"><code>detailsBoxesEnabled <true|false></code></div>
<P>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.
</P>
</DIV>
<DIV class="endsVisible"><span class="types bigInteract"></span>
<div class="format"><code>endsVisible two</code></div>
<P>This setting makes the default behavior for the track show only interactions with both ends in the window.
</P>
</DIV>
<DIV class="interact_example"><span class="types bigInteract"></span>
<div class="format"><B>Example of an interact/bigInteract track</B></div>
<pre>
track snpGeneInteractions
type bigInteract
interactDirectional true
maxHeightPixels 300:150:20
bigDataUrl http://...
</pre>
</div>
<!-- - - - - - - - bigLolly settings - - - - - - - -->
<DIV class="bigLolly_intro">
<H3>bigLolly: Lollipop Charts</H3>
<P>
Lollipop graphs are usually used to display data that is local to a single base that
has one to three data values assigned to it which can be displayed using the lollipop
height, the color, and the size of the circle at the top of the lollipop. For examples
visit the <a href="../bigLolly.html">bigLolly help page</a>.
</DIV>
<DIV class="bigLolly_example"><span class="types bigLolly"></span>
<div class="format"><B>Example of a bigLolly track</B></div>
</DIV>
<!-- - - - - - - - hic settings - - - - - - - -->
<DIV class="hic_intro">
<H3>hic: Hi-C contact matrices</H3>
<P>
The hic track type is for displaying chromatin-chromatin interaction data via heat
maps. Currently this track type supports one file format: the .hic file format created
by the <a href="https://www.aidenlab.org" target="_blank">Aiden Lab</a> at <a target="_blank"
href="https://www.bcm.edu">Baylor College of Medicine</a>. This is an indexed
binary format that supports remote access, so the file can be hosted on any web accessible
server and displayed at UCSC. More details on .hic display at UCSC can be found at the
<a href="../hic.html">hic help page</a>.
For more information on the .hic file format and the Juicer tool that generates these files,
see the documentation on <a target="_blank"
href="https://github.com/aidenlab/juicer/wiki/Data">github</a>.</p>
</DIV>
<div class="drawMode"><span class="types hic"></span>
<div class="format"><code>drawMode <triangle|square|arc></code></div>
<p>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.
</p>
</div>
<div class="normalization"><span class="types hic"></span>
<div class="format"><code>normalization <NONE|VC|VC_SQRT|KR></code></div>
<p>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.
</p>
</div>
<div class="resolution"><span class="types hic"></span>
<div class="format"><code>resolution <Auto|integer></code></div>
<p>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 <code>Auto</code> 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.
</p>
</div>
<div class="saturationScore"><span class="types hic"></span>
<div class="format"><code>saturationScore <float></code></div>
<p>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.
</p>
</div>
<div class="hicDistanceMin"><span class="types hic"></span>
<div class="format"><code>hicDistanceMin <integer></code></div>
<p>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.
</p>
</div>
<div class="hicDistanceMax"><span class="types hic"></span>
<div class="format"><code>hicDistanceMax <integer></code></div>
<p>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.
</p>
</div>
<div class="hicArcLimit"><span class="types hic"></span>
<div class="format"><code>hicArcLimit <integer></code></div>
<p>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.
</p>
</div>
<div class="hicArcLimitEnabled"><span class="types hic"></span>
<div class="format"><code>hicArcLimitEnabled <true|false></code></div>
<p>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.
</p>
</div>
<DIV class="hic_example"><span class="types hic"></span>
<div class="format"><B>Example of a hic track</B></div>
<pre>
track myHiCData
type hic
drawMode arc
color 0,0,255
saturationScore 12
normalization KR
bigDataUrl http://...
</pre>
</div>
<!-- - - - - - - - bigBarChart settings - - - - - - - -->
<DIV class="bigBarChart_intro">
<H3>bigBarChart: Bar charts of variables displayed on genomic regions</H3>
<P>
The bigBarChart format stores values of a set of variables for each genomic region
in the file. BigBarChart files are created using the program bedToBigBed with a special
AutoSQL file that defines the fields. The resulting files are in an indexed binary format
that supports efficient remote access, so the file can be hosted on your web accessible server
and displayed at UCSC.
For the complete bigBarChart format definitions please see the
<A HREF="../barChart.html">bigBarChart help page</A>.</P>
</DIV>
<DIV class="barChartBars"><span class="types barChart bigBarChart"></span>
<div class="format"><code>barChartBars <label1 label2...></code></div>
<P>This setting is a list of labels for the categorical variables (bars).
It is required for this track type.
</P>
</DIV>
<DIV class="barChartUnit"><span class="types barChart bigBarChart"></span>
<div class="format"><code>barChartUnit <unit></code></div>
<P>The unit label is attached to values in the display, charts and plots of the track.
</P>
</DIV>
<DIV class="barChartLabel"><span class="types barChart bigBarChart"></span>
<div class="format"><code>barChartLabel <label></code></div>
<P>This setting provides a label for the category selection list.</p>
</P>
</DIV>
<DIV class="barChartMaxSize"><span class="types bigBarChart"></span>
<div class="format"><code>barChartMaxSize <small/medium/large></code></div>
<P>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".
</P>
</DIV>
<DIV class="barChartSizeWindows"><span class="types bigBarChart"></span>
<div class="format"><code>barChartSizeWindows <largeMax> <smallMin></code></div>
<P>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.</p>
<table>
<tr><td><i>large</i></td><td> window size < largeMax</td></tr>
<tr><td><i>medium</i></td><td> window size >= largeMax and < smallMin</td></tr>
<tr><td><i>small</i></td><td>window size >= smallMin</td></tr>
</table>
<P><B>Example:</B></P>
<pre> barChartSizeWindows 500 8000</pre>
<P>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.
</P>
</DIV>
<DIV class="barChartStretchToItem"><span class="types bigBarChart"></span>
<div class="format"><code>barChartStretchToItem on</code></div>
<P>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.
</P>
</DIV>
<DIV class="barChartMetric"><span class="types barChart bigBarChart"></span>
<div class="format"><code>barChartMetric <metric></code></div>
<P>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).</p>
</P>
</DIV>
<DIV class="barChartColors"><span class="types bigBarChart"></span>
<div class="format"><code>barChartColors <color1 color2...></code></div>
<P>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: <div class='dot' style='background: #000000'></div>black,
<div class='dot' style='background: silver'></div>silver,
<div class='dot' style='background: gray'></div>gray,
<div class='dot' style='height: 8px; width: 8px; background: white; border: 1px solid black'></div>white,
<div class='dot' style='background: maroon'></div>maroon,
<div class='dot' style='background: red'></div>red,
<div class='dot' style='background: purple'></div>purple,
<div class='dot' style='background: fuchsia'></div>fuchsia,
<div class='dot' style='background: green'></div>green,
<div class='dot' style='background: lime'></div>lime,
<div class='dot' style='background: olive'></div>olive,
<div class='dot' style='background: yellow'></div>yellow,
<div class='dot' style='background: navy'></div>navy,
<div class='dot' style='background: blue'></div>blue,
<div class='dot' style='background: teal'></div>teal,
<div class='dot' style='background: aqua'></div>aqua.
</P>
</DIV>
<DIV class="barChartMatrixUrl"><span class="types bigBarChart"></span>
<div class="format"><code>barChartMatrixUrl <url></code></div>
<P>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.
</P>
</DIV>
<DIV class="barChartSampleUrl"><span class="types bigBarChart"></span>
<div class="format"><code>barChartSampleUrl <url></code></div>
<P>Specifies a tab-separated file that provides categories for samples in the
barChartMatrixUrl file. Used for generating a box plot on the details page.
</P>
</DIV>
<DIV class="barChartCategoryUrl"><span class="types bigBarChart"></span>
<div class="format"><code>barChartCategoryUrl <url></code></div>
<P>Specifies a tab-separated file that provides labels and optionally colors for the
categories (bars).
This setting can replace the <code>barChartBars</code> and <code>barChartColors</code> settings,
and is particularly useful for tracks with large numbers of categories.
</P>
</DIV>
<DIV class="barChartFacets"><span class="types bigBarChart"></span>
<div class="format"><code>barChartFacets <column1,column2,...columnN></code></div>
<P>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 <a target="_blank"
href="../barChart.html#example6">barChart help page</a>.
</P>
</DIV>
<DIV class="barChartStatsUrl"><span class="types bigBarChart"></span>
<div class="format"><code>barChartStatsUrl <url></code></div>
<P>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 <i>color</i> 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 <i>count</i> 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 <a target="_blank"
href="../barChart.html#example6">barChart help page</a>.
</P>
</DIV>
<DIV class="singleCellColumnNames"><span class="types bigBarChart"></span>
<div class="format"><code>singleCellColumnNames off</code></div>
<P>This setting changes <B>cell count</B> to <B>count</B> in the track details page
for the column named <i>count</i> in the facets file specified by
<code>barChartStatsUrl</code>. This setting is useful for non-single-cell datasets
such as bulk RNA-seq, where <i>count</i> represents the number of samples or
replicates rather than cells. See an example with images of barChartStatsUrl on the
<a target="_blank" href="../barChart.html#example6">barChart help page</a>.
</P>
</DIV>
<DIV class="barChartMerge"><span class="types bigBarChart"></span>
<div class="format"><code>barChartMerge on</code></div>
<P>This setting enables the <i>merge</i> 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
<a target="_blank" href="../barChart.html#example6">barChart help page</a>.
</P>
</DIV>
<DIV class="barChartBarMinPadding"><span class="types bigBarChart"></span>
<div class="format"><code>barChartBarMinPadding <num></code></div>
<P>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 <a target="_blank"
href="../barChart.html#example5">barChart help page</a>.</p>
</DIV>
<DIV class="barChartBarMinWidth"><span class="types bigBarChart"></span>
<div class="format"><code>barChartBarMinWidth <num></code></div>
<P>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 <a target="_blank"
href="../barChart.html#example5">barChart help page</a>.
</P>
</DIV>
<DIV class="bigBarChart_example"><span class="types bigBarChart"></span>
<div class="format"><B>Example of a bigBarChart track</B></div>
<pre>
track brainRegionRna
type bigBarChart
maxLimit 8000
barChartUnit RPKM
barChartLabel Brain Regions
barChartMetric median
barChartBars Amygdala Cerebellum Cortex Hippocampus
barChartColors #ff0000 0,255,0 maroon navy
shortLabel Brain RNA
longLabel Brain Gene Expression
spectrum on
labelFields gene, name
defaultLabelFields gene
bigDataUrl http://...
barChartMatrixUrl http://...
barChartSampleUrl http://...
</pre>
</div>
<!-- - - - - - - - GROUP settings - - - - - - - -->
<DIV class="group_intro">
<H3>Predefined major track groupings</H3>
<P><I>NOT FOR HUBS.</I></P>
<P>The simplest grouping:</P>
</DIV>
<DIV class="group"><span class="types group"></span>
<div class="format"><code>group <groupId></code></div>
<P>All tracks belong to
one of several groups. Hub tracks belong to the group that
encompasses their hub. Other tracks belong to one of the
predefined groups. For hg19 the following groups are defined:</P>
<UL>
<LI><code>map</code> - "Mapping and Sequence"</LI>
<LI><code>phenDis</code> - "Phenotype and Disease Associations"</LI>
<LI><code>genes</code> - "Genes and Gene Prediction"</LI>
<LI><code>rna</code> - "mRNA and EST"</LI>
<LI><code>expression</code> - "Expression"</LI>
<LI><code>regulation</code> - "Regulation"</LI>
<LI><code>compGeno</code> - "Comparative Genomics"</LI>
<LI><code>neandertal</code> - "Neandertal Assembly and Analysis"</LI>
<LI><code>varRep</code> - "Variation and Repeats"</LI>
</UL>
<P>If no group is set for a built-in track, then the track will end up
in the Experimental Tracks section at the bottom.</P>
</DIV>
<DIV class="group_example"><span class="types group"></span>
<div class="format"><B>Example of a track belonging to a predefined group</B></div>
<pre>
track myTrack
group regulation
... </pre>
</DIV>
<!-- - - - - - - - SUPERTRACK settings - - - - - - - -->
<DIV class="superTrack_intro">
<H3>Supertrack settings</H3>
<P>The first
hierarchical container is called the supertrack, which may be thought of as
a folder that holds other tracks that by default are closed, unless the
setting <code>show</code> is added. The Browser currently supports only one
level of supertrack folders. Generally the subtracks
of a supertrack are of differing types. If all the children are
of the same type, it is often better to use the <a href="#compositeTrack">compositeTrack</a> grouping
described below. If all of the children are wig or bigWig tracks, it may
be of interest to use a signal overlay "container multiWig" grouping. Signal
overlay tracks display the signal data from several subtracks as colored
transparencies, making it possible to see the data of several tracks together
in a condensed view. See the <A HREF="#aggregate">multiWig</A> section for more information.</P>
<P>Supertracks can contain
composite tracks and container multiWigs, but not vice versa. With supertracks,
composite tracks, and container multiWigs, children will inherit the settings
from their parents, but can override their parent settings within their own stanzas.</P>
</DIV>
<DIV class="superTrack"><span class="types superTrack"></span>
<div class="format"><code>superTrack on show</code></div>
<p>
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,
<code>superTrack on show</code>, to the end of the statement. To have
the supertrack not display by default use only <code>superTrack on</code>.
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 <code>show</code>.</p>
<p>
All tracks that claim membership to the supertrack should set their
own visibilities in lower stanzas by declaring settings such as
<code>parent superTrack1</code> and also by having a separate
<code>visibility dense</code> 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.</p>
<p>
Do not confuse the parent line with how it is used in composites. For example,
in supertracks DO NOT follow the example of <strike><code>parent superTrack1 [off/on]</code></strike>,
where <code>[off/on]</code> will only work with composite tracks. When attempting to debug visibility
settings, it may be helpful to read the <A href='#inheritance'>note about
inheritance</A> found below.</p>
</DIV>
<DIV class="parent_supertrack"><span class="types superTrack"></span>
<div class="format"><code>parent <superTrack></code></div>
<P>Membership in a supertrack, composite, or aggregate track is declared by the
child, not the supertrack itself with a line such as <code>parent superTrack1</code>.</p>
<p>
Do not confuse the parent line with how it is used in composites. For example,
in supertracks DO NOT follow the example of <code>parent compositeTrack1 [off/on]</code>,
which will only work with composite tracks.</p>
<p>
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.</p>
<p>
All tracks that claim membership to the supertrack should set their
own visibilities in lower stanzas by declaring separate settings such as
<code>visibility dense</code>.When attempting to debug visibility settings, it may be
helpful to read the <A href='#inheritance'>note about
inheritance</A> found below.</p>
</DIV>
<DIV class="superTrack_example"><span class="types superTrack"></span>
<div class="format"><B>Example of a Supertrack</B></div>
<p>
Example 1
<pre>
track myFolder
superTrack on show
shortLabel My Folder
longLabel My folder keeps my tracks together
...
track myFirstTrack
parent myFolder
visibility dense
...
track mySecondTrack
parent myFolder
visibility hide
... </pre>
<p>The track called "My Folder" is declared as a supertrack and
contains two children who claim membership with parent lines.
Notice that the first track, <code>track myFirstTrack</code>, is visible by
default with <code>visibility dense</code> (because the supertrack itself,
<code>myFolder</code>, has the light-switch-like setting
of <code>show</code> to display all the contents of the supertrack).
The second track, <code>track mySecondTrack</code>, is not displayed,
however, with <code>visibility hide</code> and will require clicking a
box on the Track Setting page to display.</p>
<p>Note: do not confuse the parent
line with how it is used in composites. For example,
in supertracks DO NOT follow the example of <strike><code>parent superTrack1 [off/on]</code></strike>,
which will only work with composite tracks. See the
<a href="../hubQuickStartGroups.html" target="_blank">Quick Start Guide to
Organizing Track Hubs into Groupings</a> for more examples.</p>
</p>
</DIV>
<!-- - - - - - - - COMPOSITE settings - - - - - - - -->
<DIV class="compositeTrack_intro">
<H3>Composite Tracks</H3>
<P>Composite tracks are
another level of hierarchy and are meant to group very similar tracks
(called "subtracks") together such that they can all
share the same configuration settings. In its simplest form a
composite holds tracks all of the same type (such as bigBed).
Initially, all track within the set are configured identically.
Usually only some of the subtracks are visible by default, and these
will have the same display mode (e.g., <code>dense</code>)
and optional settings (e.g., <code>viewLimits</code>).
While default settings cover the entire composite of related tracks,
in most cases individual subtracks can be configured by the user
independently of the composite settings. However, once individual
subtrack settings are made, they can be overridden by new choices made at
the composite level. It may be helpful to read the "<A href='#inheritance'>Note about
inheritance</A>" found below.</P>
<P><I>Currently only the following track types can be organized into a
composite: item-based tracks (bed, bigBeg, broadPeaks, etc.), signal-based
tracks (wig, bigWig, etc.), other remote file-based tracks (bams,
vcf, etc.), chains/nets, genePred, psl, and wigMaf-type tracks.</I></P>
</DIV>
<DIV class="compositeTrack_hub_intro">
<H3>Composite Tracks</H3>
<P>Composite tracks are
another level of hierarchy and are meant to group very similar tracks
(called "subtracks") together such that they can all
share the same configuration settings. In its simplest form a
composite holds tracks all of the same type (such as bigBed).
Initially, all track within the set are configured identically.
Usually only some of the subtracks are visible by default, and these
will have the same display mode (e.g., <code>dense</code>)
and optional settings (e.g., <code>viewLimits</code>).
While default settings cover the entire composite of related tracks,
in most cases individual subtracks can be configured by the user
independently of the composite settings. However, once individual
subtrack settings are made, they can be overridden by new choices made at
the composite level. It may be helpful to read the "<A href='#inheritance'>Note about
inheritance</A>" found below.</P>
</DIV>
<DIV class="compositeTrack"><span class="types compositeTrack"></span>
<div class="format"><code>compositeTrack on</code></div>
<P>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.</P>
Note that since children of composites inherit their parent's
settings, many more trackDb settings will be found at the
composite level than at the supertrack level.</P>
</DIV>
<DIV class="parent"><span class="types compositeTrack"></span>
<div class="format"><code>parent <composite> [off/on]</code></div>
<P>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 <code>parent</code> 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.</p>
</DIV>
<DIV class="allButtonPair"><span class="types compositeTrack"></span>
<div class="format"><code>allButtonPair on</code></div>
<P>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 "<B>All</B>
<img style='vertical-align:middle;' src='/images/add_sm.gif' /><img style='vertical-align:middle;' src='/images/remove_sm.gif' />"
<!-- Don't break the long line above, so that the buttons have no daylight between them -->
(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).
</P>
</DIV>
<DIV class="centerLabelsDense"><span class="types compositeTrack"></span>
<div class="format"><code>centerLabelsDense <off/on></code></div>
<!-- <P><I>TODO: Should be made obsolete, with subtracks always sharing one label.</I> </P> -->
<P>By default, only the composite track's single center label is shown when the
subtracks are displayed together in the Browser dense mode.
If <code>centerLabelsDense</code> is set to "on", the Browser will display a center
label for each subtrack.
</P>
</DIV>
<DIV class="dragAndDrop"><span class="types compositeTrack"></span>
<div class="format"><code>dragAndDrop subTracks</code></div>
<!-- <P><I>TODO: Should be made obsolete (and default behavior)</I></P> -->
<P>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
<A onclick="return jumpTo(this);" HREF="#">sortOrder</A> 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 <code>dragAndDrop subTracks</code> 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.</P>
</DIV>
<DIV class="hideEmptySubtracks"><span class="types compositeTrack"></span>
<div class="format">
<code>hideEmptySubtracks <on/off></code></div>
<p>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 <code>on</code> is specified, the feature is on by default (the checkbox is checked).
</p>
</DIV>
<DIV class="hideEmptySubtracksMultiBedUrl"><span class="types compositeTrack"></span>
<div class="format">
<code>hideEmptySubtracksMultiBedUrl file.bb</code></div>
<p>
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
<code>hideEmptySubtracks</code> feature.
Instructions for creating these files are at the MultiBed help page (TBD).</p>
<p>
NOTE: These settings are required to use the <code>hideEmptySubtracks</code> feature
with multi-view composites.</p>
</DIV>
<DIV class="hideEmptySubtracksSourcesUrl"><span class="types compositeTrack"></span>
<div class="format">
<code>hideEmptySubtracksSourcesUrl file.tab</code></div>
<p>
This setting is used in conjunction with the <code>hideEmptySubtracksMultiBedUrl</code>
setting, described above.</p>
</DIV>
<DIV class="hideEmptySubtracksLabel"><span class="types compositeTrack"></span>
<div class="format">
<code>hideEmptySubtracksLabel <label></code></div>
<P>This setting is used in conjunction with the <code>hideEmptySubtracks</code> 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").
</p>
</DIV>
<DIV class="compositeTrack_example"><span class="types compositeTrack"></span>
<div class="format"><B>Example of a Composite track</B></div>
<pre>
track myComposite
compositeTrack on
parent myFolder
shortLabel My Composite
type bigWig 0 1.0
viewLimits 0.0:0.2
allButtonPair on
...
track myFirstSubtrack
parent myComposite on
...
track mySecondSubtrack
parent myComposite
... </pre>
<P>The composite with two subtracks shown. All
subtracks are of type bigWig and all have a default <code>viewLimits</code> of 0 - 0.2.
Notice the first subtrack is checked by default, but the second is not
(<code>parent</code> setting). However, the Browser will display two buttons
(<code>allButtonPair</code> setting) that allow the user to
select all subtracks, or deselect all of them and then check only those of
interest.</p>
</DIV>
<!-- - - - - - - - SUBGROUPS settings - - - - - - - -->
<DIV class="subGroups_intro">
<H3>Subgroups</H3>
<P>Within a composite track, two different grouping styles can be used to allow
the user to select tracks for display in the Browser.
This section describes the configuration of "subgroups"; "views" are discussed in
a subsequent section.</P>
<P>
The subgroup can be used for selecting sets of subtracks for display based on certain
characteristics of the data. For instance, if "cell" and "antibody" are
defined as subgroups within a composite track, the user will be able to select
subtracks based on specific cell types and antibodies to display in the Browser. Up to 9
subgroup types can be defined for a composite. However, to minimize the complexity,
it is strongly recommended that only two subgroups be defined
for a given composite track. These will be presented in a simple X/Y matrix that is easy for
the user to understand and navigate. It is possible to define more subgroups in additional
"abc" dimensions that will be presented to the user as drop-down multi-select dialogs,
but use of these should be avoided or minimized.</P>
</DIV>
<DIV class="subGroupN"><span class="types subGroups"></span>
<div class="format">
<code>subGroup1 <gTag1> <gTitle1> <mTag1a=mTitle1a>
[mTag1b=mTitle1b…]</code><BR>
<code>subGroup2 <gTag2> <gTitle2> <mTag2a=mTitle2a>
[mTag2b= mTitle2b…]</code></div>
<P>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 '<code>=</code>' equals sign. </P>
<ul>
<li> <code>tag</code>: 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.</li>
<li> <code>title</code>: 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 '<code>_</code>'. 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.</li>
</ul>
<P>Because subgroup settings are often lengthy, it is recommended that the
'<code>\</code>' line continuation character be used to break up the setting over
multiple lines for easier reading.
</DIV>
<DIV class="noInherit"><span class="types all"></span>
<div class="format"><code>noInherit on</code></div>
<P><I>Deprecated.</I></P>
<P>Placed on a subtrack, this stops the subtrack from taking settings from its composite
parent. Without it a subtrack inherits the parent's <code>type</code> and
<code>group</code>, plus every parent setting the subtrack does not define itself.</P>
<P>The Browser only checks whether the setting is present, so any value turns it on,
including <code>noInherit off</code>. Defining a setting on the subtrack already
overrides the inherited value, so this setting is rarely needed.</P>
<P><B>Example:</B></P>
<pre> noInherit on</pre>
</DIV>
<DIV class="subGroups"><span class="types subGroups"></span>
<div class="format"><code>subGroups <gTag1=mTag1?> [gTag2= mTag2?]</code></div>
<P>The subtracks themselves declare their
membership in a group with the <code>subGroups</code> 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).</P>
</DIV>
<DIV class="dimensions"><span class="types subGroups"></span>
<div class="format"><code>dimensions <dimX=gTag#> [dimY=gTag#] [dimA=gTag# ...]</code></div>
<P>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.</P>
<P>Note that the order of the subgroups in a dimension is exactly the same as
the order they appear in the <code>subGroup#</code> 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 <code>allButtonPair on</code> will prevent the matrix from displaying.</p>
</DIV>
<DIV class="filterComposite"><span class="types subGroups"></span>
<div class="format"><code>filterComposite <dim[A/B/C][=one]> [dimB dimC ...]</code></div>
<P>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
<code>filterBy</code> setting discussed
above. Declare the subtrack filter boxes with the <code>filterComposite</code>
setting. Filter composites may work with or without the X/Y
matrix, but are restricted to the "abc" dimensions.</P>
<P>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 "<code>=one</code>" 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.</P>
</DIV>
<DIV class="dimensionAchecked"><span class="types subGroups"></span>
<div class="format"><code>dimension<?>checked <mTag1a>
[mTag1b …]</code></div>
<P>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.</P>
</DIV>
<DIV class="controlledVocabulary"><span class="types subGroups"></span>
<div class="format"><code>controlledVocabulary <pathToFile> <gTag#=mdbVar>
[gTag#=mdbVar …]</code></div>
<P><I>NOT FOR HUBS. Currently used only by ENCODE</I></P>
<P>In ENCODE, subgroups
are often based on metadata terms declared in the metaDb table and defined
in the "controlled vocabulary", which is
stored as an ra file. In this situation, the labels of these
terms, as they are displayed in the track configuration page, can
be linked to the controlled vocabulary definitions. These links
can be quite useful, as the term definition may include protocol
documents and validation evidence. In order to establish the
links, each subGroup's tag must be tied to the actual metaDb
term.
</P>
<!-- <P><I>TODO: Currently the file declared in this
setting is not used, as the cv.ra file is always found in its
standard location.</I></P> -->
</DIV>
<DIV class="sortOrder"><span class="types subGroups"></span>
<div class="format"><code>sortOrder <gTag#=+/-> [gTag#=- …]</code></div>
<P>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
<A onclick="return jumpTo(this);" HREF="#">dragAndDrop</a> 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
<code>subGroup#</code> and <code>subGroups</code> settings. By sorting
on tags, non-alphanumeric orders can be defined.</P>
</DIV>
<DIV class="fileSortOrder"><span class="types subGroups downloadsOnly"></span>
<div class="format"><code>fileSortOrder <var=val> [var=val ...]</code></div>
<P><I>NOT FOR HUBS. Currently used only by ENCODE</I></P>
<P>Some composite track sets have their own
directories of downloadable files and a special CGI for accessing
those files. In order to see the CGI interface for the download
directory, the composite needs an object for each file defined in
the metaDb. The trackDb stanza for the composite also needs to
have the fileSortOrder setting defined. The setting is defined as
a set of variable=value pairs, which defines the default sort
order on metaDb variables. The "var" portion of the each pair is
a term defined in the metaDb for all of the file objects in the
directory. The "var" may also be "<code>fileType</code>" or "<code>fileSize</code>",
which are not defined in the metaDb. The "val" is the title that the
user will see as the column header for the sortable table of
files. This value can contain and '<code>_</code>' for spaces and limited HTML
codes and special characters. As always, you are encouraged to
experiment. The '<code>\</code>' continuation character should be used to
break up this long setting into readable lines.
</P>
</DIV>
<DIV class="subGroups_example"><span class="types subGroups"></span>
<div class="format"><B>Examples of Composite tracks with Subgroups</B></div>
<pre>
track myComposite
compositeTrack on
subGroup1 cellLine Cell_Line \
A1GM12=GM12878 \
CD14=CD14+ …
subGroup2 ab Antibody \
H3K04ME3=H3K4me3 \
H3K36ME3=H3K36me3 …
dimensions dimX=ab dimY=cellLine
sortOrder cell=+ ab=+
...
track myFirstSubtrack
parent myComposite on
subGroups cellLine=CD14 ab=H3K04ME3
... </pre>
<P>This examples shows a composite with
one subtrack and two subgroups. The
dimensions setting declares X and Y dimensions, which will display
a 2D matrix on the composite's configuration page. Notice that the
title of the cellLine subgroup contains a blank space filled in
with '<code>_</code>'. The second cell line, "CD14+", includes an HTML encoding
for '<code>+</code>' in its title, The two subgroups participate in the default
sort order of subtracks, but they each have non-standard sort orders. In the
cellLine subgroup, GM12878 sorts first by starting its tag with "A". The
antibodies have numbers in their titles, but the tags expand
the number with "0" to pad the spacing. This ensures
H3K4me3 sorts before H3K36me3.</P>
<pre>
track myCompositeIs3D
compositeTrack on
subGroup1 cellLine Cell_Line \
A1GM12=GM12878 \
CD14=CD14+ …
subGroup2 ab Antibody \
H3K04ME3=H3K4me3 \
H3K36ME3=H3K36me3 …
subGroup3 treat Treatment \
TNFA=TNF-alpha \
ZNONE=None …
dimensions dimX=ab dimY=cellLine dimA=treat
filterComposite dimA
dimensionAchecked ZNONE
controlledVocabulary encode/cv.ra cellLine=cell \
ab=antibody \
treat=treatment
sortOrder cell=+ ab=+ treat=-
fileSortOrder cell=Cell_Line \
antibody=Antibody \
fileSize=Size
...
track myFirstSubtrackIn3D
parent myCompositeIs3D on
subGroups cellLine=CD14 ab=H3K04ME3 treat=ZNONE
... </pre>
<P>In this second example composite,
one subtrack and three subgroups are shown. As in the previous example, the
dimensions setting declares X and Y dimensions, resulting in
a 2D matrix of "Antibody" and "Cell Line" options. A third "Treatment" subgroup is
declared as the "A"
dimension; the user will be able to select subtracks for this
dimension via a dropdown multi-select filter box. All three subgroups
participate in the default sort order of subtracks, and the treatment subgroup is
sorted in reverse order by default. The "None" treatment
sorts before all others (in reverse order) by beginning the tag with
a "Z". Note that for this "A" dimension,
the "None" treatment will be selected by default. By
declaring the proper settings, using subGroups to organize a
composite can be quite powerful.</P>
<P>This example illustrates that
subgroups, dimensions, and (in the case of ENCODE) controlled vocabulary and
metadata all must be linked together for the composite to fully
work. Further, the actual terms, programmatic "tags"
and user visible titles all have different constraints and roles
to play in establishing this cohesion. Subgroup tags are used to
organize subtracks, while lettered dimensions organize the
configuration page to more easily select subgroups of subtracks.
For ENCODE tracks, the subgroups may be represented as metadata
"terms" (distinct from tags) that are often carefully
defined by a controlled vocabulary. In the example above, the tag
"ab" is used to organize subtracks into subgroups but
is also tied to dimension X. This ensures that antibodies will
appear as the horizontal dimension in the 2D matrix on the
configuration page, and the selection of an antibody will select the
associated subtracks. Of course the user does not see the
antibody as "ab" but "Antibody". Going
further, the term as defined in controlled vocabulary is
"antibody", so that for all the tables and files
associated with this composite track, their metaDb objects should
contain an "antibody" var and a given antibody (e.g.
H3K4me3) will be found in the controlled vocabulary with a
validation document. All the relationships can be confusing, but
the trackDb settings, if done correctly, can tie all these
elements together in a nice cohesive package.</P>
<!-- DONNA Above needs rewrite -->
</DIV>
<DIV class="subGroups_hub_example"><span class="types subGroups"></span>
<div class="format"><B>Examples of Composite tracks with Subgroups</B></div>
<pre>
track myComposite
compositeTrack on
subGroup1 cellLine Cell_Line \
A1GM12=GM12878 \
CD14=CD14+ …
subGroup2 ab Antibody \
H3K04ME3=H3K4me3 \
H3K36ME3=H3K36me3 …
dimensions dimX=ab dimY=cellLine
sortOrder cell=+ ab=+
...
track myFirstSubtrack
parent myComposite on
subGroups cellLine=CD14 ab=H3K04ME3
... </pre>
<P>This examples shows a composite with
one subtrack and two subgroups. The
dimensions setting declares X and Y dimensions, which will display
a 2D matrix on the composite's configuration page. Notice that the
title of the cellLine subgroup contains a blank space filled in
with '<code>_</code>'. The second cell line, "CD14+", includes an HTML encoding
for '<code>+</code>' in its title, The two subgroups participate in the default
sort order of subtracks, but they each have non-standard sort orders. In the
cellLine subgroup, GM12878 sorts first by starting its tag with "A". The
antibodies have numbers in their titles, but the tags expand
the number with "0" to pad the spacing. This ensures
H3K4me3 sorts before H3K36me3.</P>
<pre>
track myCompositeIs3D
compositeTrack on
subGroup1 cellLine Cell_Line \
A1GM12=GM12878 \
CD14=CD14+ …
subGroup2 ab Antibody \
H3K04ME3=H3K4me3 \
H3K36ME3=H3K36me3 …
subGroup3 treat Treatment \
TNFA=TNF-alpha \
ZNONE=None …
dimensions dimX=ab dimY=cellLine dimA=treat
filterComposite dimA
dimensionAchecked ZNONE
sortOrder cell=+ ab=+ treat=-
...
track myFirstSubtrackIn3D
parent myCompositeIs3D on
subGroups cellLine=CD14 ab=H3K04ME3 treat=ZNONE
... </pre>
<P>In this second example composite,
one subtrack and three subgroups are shown. As in the previous example, the
dimensions setting declares X and Y dimensions, resulting in
a 2D matrix of "Antibody" and "Cell Line" options. A third "Treatment" subgroup is
declared as the "A"
dimension; the user will be able to select subtracks for this
dimension via a dropdown multi-select filter box. All three subgroups
participate in the default sort order of subtracks, and the treatment subgroup is
sorted in reverse order by default. The "None" treatment
sorts before all others (in reverse order) by beginning the tag with
a "Z". Note that for this "A" dimension,
the "None" treatment will be selected by default. By
declaring the proper settings, using subGroups to organize a
composite can be quite powerful.</P>
</DIV>
<!-- - - - - - - - VIEW settings - - - - - - - -->
<DIV class="view_intro">
<H3>Views</H3>
<P>In addition to subgroups, a single
composite can be divided into multiple "views". Recall
that a composite should be made up of subtracks of the same <code>type</code>.
However, different types of subtracks can be combined into the same
composite track if they are in separate "views". While
views are like subgroups in many ways, they can carry their own
settings. This is necessary because the views within a composite may be for different
types that have their own distinct configuration settings, for example bigBeds and
bigWigs. </P>
<P>The "view" (or
"multi-view") organization is typically used when the
same basic data is stored in multiple formats and granularities. For
example, a collection of views may include short read sequence alignments (type bam), signals
representing pile-ups of aligned reads (type bigWig), and the peaks (type
bigBed) that are called in regions where the evidence of experimental result is
deemed significant. These three "views" of the same
experimental data can be seen more informatively as a cohesive set
within a multi-view composite track.</P>
<P>Views are declared both
as a subgroup and as a separate track stanza. A composite with
multiple views has only views as children, and each view will have one
or more subtracks as children. The three levels must be defined
together with indenting to make the hierarchy obvious.</P>
<P id='inheritance'><div class="hintBox"><I><U>A note about
inheritance.</U></I> Subtracks
will inherit settings from their parents (both from composites and
from views). This is true when the setting is inheritable, which is generally
the case. Obvious exceptions are settings that are
relevant only to the higher level. Inheritance follows the "closest
to home" paradigm in which a setting at the subtrack level
takes precedence, followed by the view level setting, and finally
the composite level setting. This inheritance applies to both the trackDb default settings
and the choices made by a user. Settings made
by the user involve a timing element as well: a change to
a parent-level setting will override all settings of
the same type for its children. If the user subsequently makes a subtrack
setting, it will override the inherited setting for that one
subtrack.<BR><BR>
An anomaly within the inheritance scheme is the "<code>visibility</code>" (display mode)
setting. Unlike other settings, visibility is cumulatively restrictive from the
supertrack level. That is, if the parent has a visibility of "<code>dense</code>" and the
child's visibility is
"<code>pack</code>", the child will be displayed as "<code>dense</code>". If the parent is
subsequently changed to "<code>full</code>" display mode, the child will now be shown in
"<code>pack</code>" mode. At the trackDb
level, default visibility is always cumulatively restrictive.
However, when a user explicitly changes a subtrack visibility to be
greater than what was inherited from parents, that subtrack's
visibility will override the inheritance. While the subtleties of
inheritance can be hard to explain, they are often intuitive in
practice. In composite subtracks, visibility settings are directly
inherited from the parent composite, therefore, any visibility lines
added at the child subtrack level of a composite will be ignored.
Also note the <a href="#parent">parent</a> line should be referenced as
<code>parent myComposite on</code> if one desires the child subtrack
in a composite to be visible (checked, selected) by default.</p></div></P>
</DIV>
<DIV class="view"><span class="types view"></span>
<div class="format">
<code>subGroup1 view <Views> <vTag1a=vTitle1a> [vTag1b=vTitle1b…]</code><BR>
<code>track <viewName></code><BR>
<code>view <viewTag></code></div>
<P>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
<code>view</code> 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.</P>
</DIV>
<DIV class="parent_view"><span class="types view"></span>
<div class="format">
<code>subGroups view=<vTag1>…</code><BR>
<code>parent <viewName> [off/on]</code></div>
<P>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 <em>implicit</em> grandparent.</P>
</DIV>
<DIV class="viewUi"><span class="types view"></span>
<div class="format"><code>viewUi on</code></div>
<P>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.</P>
</DIV>
<DIV class="configurable"><span class="types view composite"></span>
<div class="format"><code>configurable <off/on></code></div>
<P>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.</P>
</DIV>
<DIV class="view_example"><span class="types view"></span>
<div class="format"><B>Example of a Composite track with Views</B></div>
<pre>
track myMultiViewComposite
compositeTrack on
visibility dense
subGroup1 view Views PK=Peaks SIG=Signals
subGroup2 cell Cell_Line \
A1GM12=GM12878 \
CD14=CD14+ …
subGroup3 ab Antibody \
H3K04ME3=H3K4me3 \
H3K36ME3=H3K36me3 …
dimensions dimX=ab dimY=cell
sortOrder cell=+ ab=+ view=+
type bed 3
...
track myViewPeaks
parent myMultiViewComposite
shortLabel Peaks
view PK
visibility pack
type bigBed 6 +
scoreFilter 0
scoreFilterLimits 0:1000
viewUi on
...
track myFirstPeakSubtrack
parent myViewPeaks on
subGroups cell=CD14 ab=H3K04ME3 view=PK
... </pre>
<P>The composite has two views, one of which is
shown, along with a single subtrack belonging to that view.
Notice that the view does not participate in the dimensions
setting, as it is an implicit dimension controlled by a row of
visibility dialogs at the top of the composite configuration page.
Notice that the view does participate in the sortOrder setting
like other subgroups. In this example, the peaks view contains
bigBed subtracks that all share the scoreFilter defaults
defined at the view level. Almost any setting that is common to
the whole tree can be defined at the composite level; any setting
that is common to the view can be set at the view level; and any
setting that is specific to one subtrack should be set at that
level. Remembering <A href='#inheritance'>inheritance</A>, we
can see that the subtrack shown inherits its track type from
the view, but has its default visibility limited by the composite.
That is, it inherits packed visibility from the view but the
composite will show all visible subtracks as dense.</P>
<P>One additional thing to note is that this composite track is
"<code>type bed 3</code>". Composites do not need a type to define
their data format, since all data is associated with subtracks. Further,
multi-view composites almost always have multiple data formats.
But the "type" also controls what configuration options may be offered
for a track. Typically, a single level composite has the same type as
all of its subtracks and offers user configuration options at the top
level. But a multi-view composite is most often given the bare-bones
"<code>type bed 3</code>", and offers user configuration options at
the view level. Exceptions to this pattern do exist but they are rare.</P>
</DIV>
<DIV class="view_exampleTwo"><span class="types view"></span>
<div class="format"><B>Example hub of a superTrack with a composite track containing different track types with Views</B></div>
<pre>
hub fiberSeqExample
shortLabel fiberSeqExampleShort
longLabel fiberSeqExampleLong
useOneFile on
email nnnn@nnn.com
descriptionUrl https://www.example.com
genome hg38
track fiberSeq
superTrack on show
shortLabel FiberSeq SuperTrack
longLabel Fiber-Seq LongLabel
html TrackDescription.html
track myMultiViewComposite
compositeTrack on
shortLabel FiberSeq Composite
longLabel FiberSeq Composite LongLabel
parent fiberSeq
visibility dense
subGroup1 view Views PK=Peaks SIG=Signals
subGroup2 cell Cell_Line \
A1GM12=GM12878 \
CD14=CD14+
dimensions dimY=cell
sortOrder cell=+ view=+
type bed 3
html TrackDescription.html
track myViewPeaks
parent myMultiViewComposite
shortLabel Peaks
view PK
visibility pack
type bigBed 12 +
track myFirstPeakSubtrack
parent myViewPeaks on
shortLabel Peak One
longLabel Peak One Long
bigDataUrl https://hgdownload.gi.ucsc.edu/gbdb/hg38/bbi/ENCODE4/TFrPeakClusters.bb
subGroups cell=CD14 view=PK
track mySecondPeakSubtrack
parent myViewPeaks on
shortLabel Peak Two
longLabel Peak Two Long
bigDataUrl https://hgdownload.gi.ucsc.edu/gbdb/hg38/bbi/ENCODE4/TFrPeakClusters.bb
subGroups cell=A1GM12 view=PK
track myViewSignals
parent myMultiViewComposite
shortLabel Peaks
view SIG
visibility pack
type bigWig
track myFirstSignalsSubtrack
parent myViewSignals on
shortLabel Sig One
longLabel Sig One Long
bigDataUrl https://hgdownload.gi.ucsc.edu/gbdb/hg38/bbi/wgEncodeRegDnase/wgEncodeRegDnaseUwK562Signal.bw
subGroups cell=CD14 view=SIG
track mySecondSignalsSubtrack
parent myViewSignals on
shortLabel Sig Two
longLabel Sig Two Long
bigDataUrl https://hgdownload.gi.ucsc.edu/gbdb/hg38/bbi/wgEncodeRegDnase/wgEncodeRegDnaseUwK562Signal.bw
subGroups cell=A1GM12 view=SIG
</pre>
<p>
Similar to the example above, except this example shows a composite track containing two views, one with
bigBeds and one with bigBeds, all inside of a superTrack.</p>
</DIV>
<!-- - - - - - - - FACETED COMPOSITE settings - - - - - - - -->
<DIV class="faceted_composite_intro">
<H3>Faceted Composite Tracks</H3>
<p>Some data sets fit easily into the view- and subgroup-based organization scheme. Other datasets, however,
may consist of too many tracks to easily coerce into that structure, and may also benefit from mixing
datasets with different underlying types (e.g. signals and peaks) together under the same heading.
For those situations, a "faceted composite" track may be appropriate. A discussion of this composite
type with some worked examples is available on our
<a href="/docs/hubs/facetedComposite.html">Faceted Composite Tracks</a> page.</p>
<p>A faceted composite track is a composite with no views or subgroups to organize the subtracks. Instead,
the subtracks are organized by a list of facets drawn from an accompanying tsv (tab-separated values) file.
These facets can be combined with an optional <code>dataTypes</code> setting to control which subtracks are
visible. When <code>dataTypes</code> is absent, each row in the list represents an individual track
that can be turned on or off. When <code>dataTypes</code> is present, the rows instead represent sample
IDs that are combined with the active dataTypes to control which tracks are turned on.</p>
<p>Important: for this setting to be used, the subtrack names must be arranged carefully.
Subtrack names in a faceted composite are derived from the parent track name and the metadata
instead of being assigned freely. The exact format depends on whether the <code>dataTypes</code>
setting is present.</p>
<p>Without <code>dataTypes</code>:
<br>
<pre> <parentTrackName>_<primaryKeyValue></pre>
Each subtrack name is the composite's track name, an underscore, and the value from the primaryKey column
in the metadata file indicated by metaDataUrl for that subtrack's row. For example, if the composite is
called "rnaseq" and the primaryKey is "sampleId", then a row with sampleId=liver in the metadata yields
a subtrack named <code>rnaseq_liver</code>.</p>
<p>With <code>dataTypes</code>:
<br>
<pre> <parentTrackName>_<primaryKeyValue>_<datatype></pre>
When <code>dataTypes</code> is set (a space-separated list of data type names), each sample can have
multiple subtracks - one per data type. The subtrack name appends an additional underscore and the data type
name. For example, if the composite is "chipSeq", primaryKey is "sampleId", dataTypes includes "H3K27ac",
and a row has sampleId=K562, then the subtrack for that row is <code>chipSeq_K562_H3K27ac</code>.
</p>
</DIV>
<DIV class="faceted"><span class="types faceted composite"></span>
<div class="format"><code>compositeTrack faceted</code></div>
<p>
This version of the <code>compositeTrack</code> setting indicates that the UI for this composite track
should be handled with facets.
</p>
<p>
A faceted composite also treats its own <A HREF="#visibility">visibility</A> 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 <A HREF="#onlyVisibility">onlyVisibility</A> for how a subtrack picks
its own mode within that maximum.
</p>
</div>
<DIV class="metaDataUrl"><span class="types faceted composite"></span>
<div class="format"><code>metaDataUrl <url></code></div>
<p>
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.
<br> Example:
<br><pre>
accession group cell_type
DRX118406 CellLine iPSC
DRX118407 CellLine iPSC
DRX118408 CellLine iMeLC
</pre>
</p>
</div>
<DIV class="primaryKey"><span class="types faceted composite"></span>
<div class="format"><code>primaryKey <field></code></div>
<p>
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.
</p>
</div>
<DIV class="maxCheckboxes"><span class="types faceted composite"></span>
<div class="format"><code>maxCheckboxes <integer></code></div>
<p>
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.
</p>
</div>
<DIV class="dataTypes"><span class="types faceted composite"></span>
<div class="format"><code>dataTypes <name1(|"table title") name2(|"table title") ...></code></div>
<p>
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.</p>
<p>Example:
<pre>
dataTypes sig|"Raw signal" peak|Peaks
</pre>
</p>
</div>
<DIV class="defaultSortField"><span class="types faceted composite"></span>
<div class="format"><code>defaultSortField <name></code></div>
<p>
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.
</p>
<p>Example:
<pre>
defaultSortField tissue
</pre>
</p>
</div>
<DIV class="subtrackUrls"><span class="types faceted composite"></span>
<div class="format"><code>subtrackUrls <field1>=<url1> <field2>=<url2> ...</code></div>
<p>
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.
</p>
<p>Example:
<pre>
subtrackUrls accession=https://www.ncbi.nlm.nih.gov/sra/$$ project=https://www.ncbi.nlm.nih.gov/bioproject/$$
</pre>
</p>
</div>
<DIV class="faceted_example1"><span class="types view"></span>
<div class="format"><B>Example of a faceted composite track containing different track types:</B></div>
<pre>
track facetedExample
shortLabel Facet example
longLabel Example of a faceted composite with subtracks
type bed3
metaDataUrl https://server.com/path/to/metadata.tsv
primaryKey accession
compositeTrack faceted
track facetedExample_type1
type bigWig
parent facetedExample off
bigDataUrl https://server.com/path/to/bigWig1.bw
track facetedExample_type2
type bigWig
parent facetedExample off
bigDataUrl https://server.com/path/to/bigWig2.bw
track facetedExample_type3
type bigBed
parent facetedExample off
bigDataUrl https://server.com/path/to/bigBed.bb
</pre>
<p>Here, the metadata tsv file contains three rows - one for type1, one for type2,
and one for type3.</p>
</div>
<DIV class="faceted_example2"><span class="types view"></span>
<div class="format"><B>Example of a faceted composite track containing different samples and data types</B></div>
<pre>
track facetedExample
shortLabel Facet example
longLabel Example of a faceted composite with subtracks
type bed3
metaDataUrl https://server.com/path/to/metadata.tsv
primaryKey accession
dataTypes signal peaks
compositeTrack faceted
track facetedExample_pk1_signal
type bigWig
parent facetedExample off
bigDataUrl https://server.com/path/to/bigWig1.bw
track facetedExample_pk2_signal
type bigWig
parent facetedExample off
bigDataUrl https://server.com/path/to/bigWig2.bw
track facetedExample_pk1_peaks
type bigBed
parent facetedExample off
bigDataUrl https://server.com/path/to/bigBed1.bb
track facetedExample_pk2_peaks
type bigBed
parent facetedExample off
bigDataUrl https://server.com/path/to/bigBed2.bb
</pre>
<p>Here, the metadata tsv file contains two rows, one for pk1 and one for pk2.
Each row provides metadata details for the collection of data type tracks associated with
that row. For example, the pk1 row of the table describes the peaks and signals tracks
for the pk1 sample.
</div>
<!-- - - - - - - - CONTAINER/MULTIWIG/AGGREGATE settings - - - - - - - -->
<DIV class="container_intro">
<H3>Aggregate or Overlay Tracks: multiWig</H3>
<P>In some instances, data from multiple tracks is so closely
related that it makes sense to view it as a single track. The
premiere example of this is the signal overlay
track (i.e. "<code>multiWig</code>"). Signal overlay tracks display the signal
data from several subtracks combined in several different ways, making it
possible to see the data of several tracks together in a condensed
view. The default overlay method for multiWigs is as colored transparencies,
in which all the graphs are drawn on top of one other in such a way
that overlapping regions are a different color. Another choice
is solid overlay, where all the graphs are still drawn overlapping each
other, but without transparency. A third choice is stacked
where the values of the subtracks are stacked on top of one another with
no overlap such that the total height of the wiggle is the sum of
all the values in the subtracks.
The value of the overlay track surpasses simply condensing the
image. Occasionally this is the most effective way to identify
hidden relationships in the underlying data. The overlay track
should not be overused, however. Attempts to overlay too many
subtracks can hide important information as regions with many layered
signals become too dark to interpret. More than eight subtracks in a
single overlay may prove less than ideal. As with composites,
it is important for the multiWig tracks to have the same data dimensions,
i.e. a signal height of 100 should be interpretable in the same
way for the whole set of tracks. While this is true for a composite
or view, it is especially important for overlay tracks. You cannot
reasonably overlay a signal from 0-1 with another signal from 0-1000.</P>
</DIV>
<DIV class="container"><span class="types container multiWig"></span>
<div class="format"><code>container multiWig</code></div>
<P>Signal overlay tracks are declared much like
simple composites. However, instead of a "composite"
setting, they declare themselves as a "container" of
"<code>type multiWig</code>". Like simple composites, all subtrack
types should be identical and the container itself should be
declared as the same type (e.g. "<code>bigWig</code>"). 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.</P>
</DIV>
<DIV class="parent_container"><span class="types container multiWig"></span>
<div class="format"><code>parent <containerTrack></code></div>
<P>Membership in a container track is declared at
the subtrack level. The subtracks should be defined with indent
beneath their container parent.</P>
</DIV>
<DIV class="aggregate"><span class="types container multiWig"></span>
<div class="format"><code>aggregate <transparentOverlay/stacked/solidOverlay/none></code></div>
<P>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 <code>transparentOverlay</code>. The setting <code>stacked</code>
will draw the graphs in stacked mode.
The setting <code>solidOverlay</code> should not be used if there
are more than a couple of tracks, and <code>none</code> 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.</P>
</DIV>
<DIV class="showSubtrackColorOnUi"><span class="types container multiWig"></span>
<div class="format"><code>showSubtrackColorOnUi on</code></div>
<P>Subtracks in an overlay have individual colors. Use this setting to show the color
associated with each on the track configuration page.</P>
</DIV>
<DIV class="container_example"><span class="types container multiWig"></span>
<div class="format"><B>Example of an Aggregate track</B></div>
<pre>
track myMultiWig
container multiWig
aggregate transparentOverlay
showSubtrackColorOnUi on
type bigWig 0 1000
viewLimits 0:10
maxHeighPixels 100:32:8
...
track myFirstOverlaySig
table myFirstWig
parent myMultiWig
color 255,128,128
wig 0 1139
...
track myFirstBigWig
parent myMultiWig
color 120,235,204
... </pre>
<P>This container is for a transparent overlay of
signal tracks with 2 subtracks shown. The tracks are
of type "<code>bigWig</code>", though the first subtrack is a <code>wig</code>.
Such mixtures are allowed. Notice that the wig has a slightly
larger range than the others. The signal dimensions are close
enough in this case, and the default viewLimit applied to all
subtracks suggests that any signal above 10 is interpreted as
strong. Note that each subtrack must define its color, and
in this example, that color will be seen in the track
configuration page as well as in the image. Also notice that the
first subtrack declares a table as distinct from its track name.
Usually the table (or remote file root) name is the same as the
track name. The track name is a unique key. But it is frequently
the case that a table or remote data file may be displayed as an
individual track or subtrack, as well as part of a signal overlay
track. Setting the table name here suggests that a track named
"myFirstWig" also exists and is displaying the same data used in
this overlay track.</P>
</DIV>
<DIV class="container_hub_example"><span class="types container multiWig"></span>
<div class="format"><B>Example of an Aggregate track</B></div>
<pre>
track myMultiWig
container multiWig
aggregate transparentOverlay
showSubtrackColorOnUi on
type bigWig 0 1000
viewLimits 0:10
maxHeighPixels 100:32:8
...
track myFirstOverlaySig
parent myMultiWig
color 255,128,128
type bigWig 0 1139
...
track myFirstBigWig
parent myMultiWig
color 120,235,204
... </pre>
<P>This container is for a transparent overlay of
signal tracks with 2 subtracks shown. The tracks are
of type "<code>bigWig</code>". Notice that the first subtrack has a slightly
larger range than the others. The signal dimensions are close
enough in this case, and the default viewLimit applied to all
subtracks suggests that any signal above 10 is interpreted as
strong. Note that each subtrack must define its color, and
in this example, that color will be seen in the track
configuration page as well as in the image.</P>
</DIV>
<!-- - - - - - - - hub.txt and genomes.txt settings - - - - - - - -->
<DIV class="hub_general_intro">
<H3>General hub configuration settings</H3>
<p>
These settings control basic, top-level information regarding your hub, such as
how it is labeled in the Genome Browser interface. Nearly every hub will make
use of these settings.</p>
</DIV>
<DIV class="genomes_file_intro">
<H3>Assembly hub "genome" settings</H3>
<p>
<a href="/goldenPath/help/assemblyHubHelp.html">Assembly hubs</a> allow users to
display custom genome assemblies in the Genome Browser.</p>
</DIV>
<DIV class="blat"><span class="types all"></span>
<div class="format"><code>blat <url> <port></code></div>
<P>Indicates the server and port to be used for the BLAT tool.
See <a href="/goldenPath/help/assemblyHubHelp.html#configuringAssemblyHubs"
>our documentation</a> for more details about setting up BLAT for your hub.
</P>
<P><B>Example:</B></P>
<pre> blat yourServer.yourInstitution.edu 17777</pre>
</DIV>
<DIV class="chromAlias"><span class="types all"></span>
<div class="format"><code>chromAlias <url/relativePath></code></div>
<P>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.</p>
<p>
See our <a
href="/goldenPath/help/assemblyHubHelp.html#chromAlias">chromAlias</a>
documentation for details on the required file format.</p>
<P><B>Example:</B></P>
<pre> chromAlias thisGenome.chromAlias.txt</pre>
</DIV>
<DIV class="chromAliasBb"><span class="types all"></span>
<div class="format"><code>chromAliasBb <url/relativePath></code></div>
<P>Like <code>chromAlias</code>, except the file is in the compressed, binary <code>bigBed</code>
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.
</p>
<p>See our <a
href="/goldenPath/help/assemblyHubHelp.html#chromAlias">chromAlias</a>
documentation for details on the required file format.</p>
<P><B>Example:</B></P>
<pre> chromAliasBb thisGenome.chromAlias.bb</pre>
</DIV>
<DIV class="chromAuthority"><span class="types all"></span>
<div class="format"><code>chromAuthority <str></code></div>
<P>Indicates which chromosome naming scheme from the <code>chromAlias</code>
file to be used as the default in the Genome Browser display. The string must
match a name defined in the <code>chromAlias</code> header.
</P>
<P><B>Example:</B></P>
<pre> chromAuthority ucsc</pre>
</DIV>
<DIV class="chromSizes"><span class="types all"></span>
<div class="format"><code>chromSizes <url/relativePath></code></div>
<P>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.
</P>
<P><B>Example:</B></P>
<pre> chromSizes thisGenome.chromSizes.txt</pre>
</DIV>
<DIV class="codonTable"><span class="types all"></span>
<div class="format"><code>codonTable default=<id> <sequenceName>=<id> ...</code></div>
<P>By default the Genome Browser translates codons to amino acids with the standard
genetic code, except for sequences named <code>chrM</code> or <code>chrMT</code>, which
use the vertebrate mitochondrial code. An assembly hub can assign a different
<a href="https://www.ncbi.nlm.nih.gov/Taxonomy/Utils/wprintgc.cgi" target="_blank">NCBI
genetic code</a> to individual sequences with the <code>codonTable</code> setting in the
genome stanza.</p>
<p>The value is a space-separated list of <code>sequenceName=id</code> pairs, where
<code>id</code> is an NCBI translation table number (for example 1 for the standard code,
2 for vertebrate mitochondrial, 13 for ascidian mitochondrial). The special name
<code>default</code> 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.</p>
<p><B>Note</B>: <code>sequenceName</code> must be the sequence's own name as stored in the
assembly's <em>.2bit</em> file (the same name used in <code>chrom.sizes</code>), for
example a RefSeq or GenBank accession such as <code>NC_017929.1</code>. This is the
internal name even when a <code>chromAlias</code> and <code>chromAuthority</code> cause a
different name (such as <code>chrM</code>) to be displayed. Because the special
<code>chrM</code>/<code>chrMT</code> mitochondrial default only applies to sequences whose
own name is literally <code>chrM</code> or <code>chrMT</code>, an assembly whose
mitochondrial sequence has an accession name needs an explicit <code>codonTable</code>
entry to translate it with a mitochondrial code.</p>
<p>See our assembly hub <a
href="/goldenPath/help/assemblyHubHelp.html#codonTable">codonTable</a> documentation for
more details.</p>
<P><B>Example:</B></P>
<pre> codonTable default=1 NC_017929.1=13</pre>
</DIV>
<DIV class="defaultPos"><span class="types all"></span>
<div class="format"><code>defaultPos <chr:start-end></code></div>
<P>Defines the initial view in the Genome Browser, usually highlighting a
popular gene or region of interest.</P>
<P><B>Example:</B></P>
<pre> defaultPos chr7:155799529-155812871</pre>
</DIV>
<DIV class="description"><span class="types all"></span>
<div class="format"><code>description <str></code></div>
<P>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.</P>
<P><B>Example:</B></P>
<pre> description July 2011 Castor bean</pre>
</DIV>
<DIV class="descriptionUrl"><span class="types all"></span>
<div class="format"><code>descriptionUrl <url/relativePath></code></div>
<P>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.
</P>
<P><B>Example:</B></P>
<pre> descriptionUrl castorBeanHubDescription.html</pre>
</DIV>
<DIV class="email"><span class="types all"></span>
<div class="format"><code>email <email address></code></div>
<P>Provides users with a contact point for questions related to the hub.</P>
<P><B>Example:</B></P>
<pre> email contactEmail@institution.edu</pre>
</DIV>
<DIV class="hubGenome"><span class="types all"></span>
<div class="format"><code>genome <str></code></div>
<P>For hubs on native assemblies, use the UCSC database name (e.g. hg38).
Genome assemblies in our <a href="https://hgdownload.gi.ucsc.edu/hubs"
target="_blank">GenArk Repository</a> can be referenced using their
GCA_NNN or GCA_NNN identifier (e.g. GCF_000891275.1). If an assembly
is not available in GenArk,
<a href="/assemblySearch.html" target="_blank">request it</a>.</P>
<p>For custom assemblies, create your own name. This will appear on title pages
in the Genome Browser.</p>
<P><B>Example:</B></P>
<pre> genome ricCom1</pre>
</DIV>
<DIV class="genomesFile"><span class="types all"></span>
<div class="format"><code>genomesFile <url/relativePath></code></div>
<P>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.</p>
<p>Not needed if using <code>useOneFile</code> (recommended).</p>
<P><B>Example:</B></P>
<pre> genomesFile genomes.txt</pre>
</DIV>
<DIV class="groupsFile"><span class="types all"></span>
<div class="format"><code>groups <url/relativePath></code></div>
<P>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.</p>
<p>
See our assembly hub <a href="/goldenPath/help/assemblyHubHelp.html#groupsTxt">groups.txt</a>
documentation for format details.
</p>
<P><B>Example:</B></P>
<pre> groups ricCom1/groups.txt</pre>
</DIV>
<DIV class="htmlPath"><span class="types all"></span>
<div class="format"><code>htmlPath <url/relativePath></code></div>
<P>Points to an HTML file with assembly information. The HTML file is
displayed on the Gateway page.</P>
<P><B>Example:</B></P>
<pre> htmlPath ricCom1/description.html</pre>
</DIV>
<DIV class="hub"><span class="types all"></span>
<div class="format"><code>hub <str></code></div>
<P>A short, unique identifier for the hub used internally by the Genome
Browser software to identify your hub. It must not contain any spaces.
</P>
<P><B>Example:</B></P>
<pre> hub myRnaSeqData</pre>
</DIV>
<DIV class="isPcr"><span class="types all"></span>
<div class="format"><code>isPcr <url> <port></code></div>
<P>Indicates the server and port to be used for the In-Silico PCR
tool. See <a href="/goldenPath/help/assemblyHubHelp.html#configuringAssemblyHubs"
>our documentation</a> for more details about setting up In-Silico
PCR for your hub.
</P>
<P><B>Example:</B></P>
<pre> isPcr yourServer.yourInstitution.edu 17779</pre>
</DIV>
<DIV class="hubLongLabel"><span class="types all"></span>
<div class="format"><code>longLabel <str></code></div>
<P>A longer, more descriptive label for the hub. Should
be under 70 characters long.
</P>
<P><B>Example:</B></P>
<pre> longLabel Comment describing this hub contents</pre>
</DIV>
<DIV class="orderKey"><span class="types all"></span>
<div class="format"><code>orderKey <int></code></div>
<P>Controls the ordering of assemblies in the pull-down menu.
Useful if you have several assemblies in your hub.
</P>
<P><B>Example:</B></P>
<pre> orderKey 4800</pre>
</DIV>
<DIV class="organism"><span class="types all"></span>
<div class="format"><code>organism <str></code></div>
<P>Common name of the organism, displayed alongside the description on
title pages. It also appears in the assembly pull-down menu.
</P>
<P><B>Example:</B></P>
<pre> organism Orangutan</pre>
</DIV>
<DIV class="scientificName"><span class="types all"></span>
<div class="format"><code>scientificName <str></code></div>
<P>Scientific name of organism, displayed alongside the description on
title pages. It also appears in the assembly pull-down menu.
</P>
<P><B>Example:</B></P>
<pre> scientificName Ricinus communis</pre>
</DIV>
<DIV class="hubShortLabel"><span class="types all"></span>
<div class="format"><code>shortLabel <str></code></div>
<P>A short description of the hub. Used as track group label
below the main Genome Browser image. Should be under 20 characters.
</P>
<P><B>Example:</B></P>
<pre> shortLabel ENCODE3 RNA-seq Data</pre>
</DIV>
<DIV class="trackDbFile"><span class="types all"></span>
<div class="format"><code>trackDb <url/relativePath></code></div>
<P>Relative path or URL to the file that defines the tracks for the assembly
specified by the <code>genome</code> setting.
</p>
<p>Not necessary if using the <code>useOneFile</code> setting (recommended).
</P>
<P><B>Example:</B></P>
<pre> trackDb ricCom1/trackDb.txt</pre>
</DIV>
<DIV class="transBlat"><span class="types all"></span>
<div class="format"><code>transBlat <url> <port></code></div>
<P>Indicates the server and port to be used for the "translated DNA/RNA" options
in the BLAT interface.
See <a href="/goldenPath/help/assemblyHubHelp.html#configuringAssemblyHubs"
>our documentation</a> for more details about setting up BLAT for your hub.
</P>
<P><B>Example:</B></P>
<pre> transBlat yourServer.yourInstitution.edu 17778</pre>
</DIV>
<DIV class="twoBitPath"><span class="types all"></span>
<div class="format"><code>twoBitPath <url/relativePath></code></div>
<P>Relative path or URL to the .2bit sequence file for the assembly. This
file is typically generated from FASTA files using the <code>faToTwoBit</code> command-line
program, available from our <a
href="https://hgdownload.gi.ucsc.edu/downloads.html#utilities_downloads">download
server</a>.
</P>
<P><B>Example:</B></P>
<pre> twoBitPath ricCom1/ricCom1.2bit</pre>
</DIV>
<DIV class="useOneFile"><span class="types all"></span>
<div class="format"><code>useOneFile <on></code></div>
<P>If the hub only has tracks on a single genome, <code>useOneFile</code>
allows all hub and track configuration settings to be in a single file.
See <a href="/goldenPath/help/hgTracksHelp.html#UseOneFile"
>our documentation</a> for more details.
</P>
<P><B>Example:</B></P>
<pre> useOneFile on</pre>
</DIV>
<DIV class="hub_txt_example"><span class="types all"></span>
<div class="format"><B>Example of an opening hub stanza</B></div>
<pre>
hub hubName
shortLabel genome
longLabel Comment describing this hub contents
genomesFile genomes.txt
email contactEmail@institution.edu
descriptionUrl aboutHub.html
</pre>
</DIV>
<DIV class="genome_example"><span class="types all"></span>
<div class="format"><B>Example of a genome stanza</B></div>
<pre>
genome ricCom1
trackDb ricCom1/trackDb.txt
groups ricCom1/groups.txt
description July 2011 Castor bean
twoBitPath ricCom1/ricCom1.2bit
organism Castor bean
defaultPos E09R7372:1000000-2000000
orderKey 4800
scientificName Ricinus communis
htmlPath ricCom1/description.html
transBlat yourLab.yourInstitution.edu 17777
blat yourLab.yourInstitution.edu 17777
isPcr yourLab.yourInstitution.edu 17779
</pre>
<P>This is the configuration needed for an assembly hub displaying
a custom genome assembly. To display tracks on a UCSC-hosted assembly,
you will only need the <code>genome</code> setting if you are using
<code>useOneFile</code>.</p>
</DIV>
<!-- - - - - - - - CUSTOM settings - - - - - - - -->
<DIV class="customTracks_intro">
<H3>Custom Tracks</H3>
<P><I>NOT FOR HUBS.</I></P>
<P>Custom tracks are
tracks that get loaded into the Browser through the hgCustom CGI.
Unlike locally hosted tracks, or even Data Hub tracks, they do not
have a trackDb.ra stanza to define their format and behavior in the
Browser. Nevertheless, they will support most of the settings as a
locally hosted track of the same type. There are a few additional
settings that are needed to fully support custom tracks.</P>
</DIV>
<DIV class="genome"><span class="types customTracks"></span>
<div class="format"><code>genome</code></div>
<P>Filled with genome/assembly db name.</P>
</DIV>
<DIV class="offset"><span class="types customTracks"></span>
<div class="format"><code>offset</code></div>
<P>Used only once, to apply an offset to bed
type data of a custom track.</P>
</DIV>
<DIV class="browserLines"><span class="types customTracks"></span>
<div class="format"><code>browserLines</code></div>
<P>Internal only – user does not set.
Filled with all trackDb.ra style lines from
hgCustom input.</P>
</DIV>
<DIV class="dataUrl"><span class="types customTracks"></span>
<div class="format"><code>dataUrl</code></div>
<P>Internal only – user does not set.
Filled if custom tracks is loaded via URL.</P>
</DIV>
<DIV class="dbTrackType"><span class="types customTracks"></span>
<div class="format"><code>dbTrackType</code></div>
<P>Internal only – user does not set.
<P>Not sure how it is distinguished from
tdbType.</P>
</DIV>
<DIV class="fieldCount"><span class="types customTracks"></span>
<div class="format"><code>fieldCount</code></div>
<P>Internal only – user does not set.
Filled with number of bed columns as
determined in hgCustom CGI.</P>
</DIV>
<DIV class="firstItemPos"><span class="types customTracks"></span>
<div class="format"><code>firstItemPos</code></div>
<P>Internal only – user does not set.
Filled with first bed item in bedList in
hgCustom CGI.</P>
</DIV>
<DIV class="htmlFile"><span class="types customTracks"></span>
<div class="format"><code>htmlFile</code></div>
<P>Internal only – user does not set.
Filled with name if trash file that contains
HTML description for custom track.</P>
</DIV>
<DIV class="htmlUrl"><span class="types customTracks"></span>
<div class="format"><code>htmlUrl</code></div>
<P>Internal only – user does not set.
Filled with user entered URL for track
</DIV>
<DIV class="initialPos"><span class="types customTracks"></span>
<div class="format"><code>initialPos</code></div>
<P>Internal only – user does not set.
Filled with position from hgCustom input.</P>
</DIV>
<DIV class="inputType"><span class="types customTracks"></span>
<div class="format"><code>inputType</code></div>
<P>Internal only – user does not set.
Filled with custom factory name as
determined in hgCustom CGI.</P>
</DIV>
<DIV class="itemCount"><span class="types customTracks"></span>
<div class="format"><code>itemCount</code></div>
<P>Internal only – user does not set.
Filled with bed item slCount in hgCustom
CGI.</P>
</DIV>
<DIV class="mafFile"><span class="types customTracks"></span>
<div class="format"><code>mafFile</code></div>
<P>Internal only – user does not set.
Filled with name of trash file that contains
maf data as loaded in hgCustom CGI.</P>
</DIV>
<DIV class="maxChromName"><span class="types customTracks"></span>
<div class="format"><code>maxChromName</code></div>
<P>Internal only – user does not set.
Obsolete: Filled with minimum index size for
db that won't "smoosh" together chromNames.</P>
</DIV>
<DIV class="origTrackLine"><span class="types customTracks"></span>
<div class="format"><code>origTrackLine</code></div>
<P>Internal only – user does not set.
Filled with "track" line as entered by user
in hgCustom CGI.</P>
</DIV>
<DIV class="tdbType"><span class="types customTracks"></span>
<div class="format"><code>tdbType</code></div>
<P>Internal only – user does not set.
<P>Holds the type that should go into
tdb->type.</P>
</DIV>
<DIV class="wibFile"><span class="types customTracks"></span>
<div class="format"><code>wibFile</code></div>
<P>Internal only – user does not set.
Filled with name of trash file that contains
wib binary data as loaded in hgCustom CGI.</P>
</DIV>
<DIV class="wigFile"><span class="types customTracks"></span>
<div class="format"><code>wigFile</code></div>
<P>Internal only – user does not set.
Filled with name of trash file that contains
wig data as loaded in hgCustom CGI.</P>
</DIV>