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