92af4b0363b70062f69a5730648b20bd8e52a317 braney Mon Aug 31 13:34:03 2026 -0700 Drop bed from searchIndex and searchTrix, and deprecate pslSequence instead of deleting it This is the reverse of the earlier passes. Instead of asking what a type list is missing, it asks which declared type nothing supports. searchIndex and searchTrix both declared bed. Neither works on a SQL bed table. The trackDb read for searchIndex is at bigBedFind.c:270 and it then needs a bbi file, from bigDataUrl or from the table's fileName, which a plain bed table does not have. searchTrix has two readers: bigBedFind.c:312 reads it from trackDb on the bigBed path, while hgFind.c:2393 reads it from hgFindSpec, which is how a SQL track gets trix search. Native usage agrees, with zero bed tracks for either setting. searchIndex also gains bigPsl, bigGenePred and bigBarChart, and searchTrix gains bigGenePred, all of which have real usage. pslSequence was deleted outright in 0e4e0c0af65. It is obsolete, but deleting the row was the wrong way to say so. 118 psl and 6 bigPsl native tracks set it, and so do three public-hub bigPsl tracks. hubCheck takes its vocabulary from this page, so with no row those hub authors would be told the setting "is not recognized. Check for typos", with a spelling suggestion, which is the wrong advice for a setting they took from our own documentation. The row is back at level-deprecated, which makes hubCheck say "is deprecated" instead, the way it already does for canPack, useScore, metadata and noInherit. Verified by running hubCheck against both spellings of the page. The library blurb is restored too, rewritten to say the setting is obsolete and to map its three values onto baseColorDefault, which replaced it in 8d32ba75938 in 2006. chainMinScore is deliberately left alone. It was proposed for deletion on the grounds that nothing reads it. Nothing does, but our own automation writes it: asmHubChainNetTrackDb.pl:101 and chainNetCompositeTrackDb.pl:186 emit "chainMinScore 5000" into the chainNet composite stanza, and findScores.pl converts -minScore into it. 40,920 native bed stanzas and 16 chain tracks carry it today. It records the minScore the chains were built with. Removing its documentation would leave those stanzas with an undocumented setting. changes.html gains a row for the type lists corrected across all three of these commits, and its existing pslSequence row is rewritten: it said the setting was removed, which is no longer what happened. Since the earlier commit has not shipped to the RR, no reader ever saw the "Removed" wording. trackDbSettings.yaml and .json are regenerated, and now hold 263 settings. refs #37908 diff --git src/hg/htdocs/goldenPath/help/trackDb/trackDbSettings.yaml src/hg/htdocs/goldenPath/help/trackDb/trackDbSettings.yaml index 28ce9e1236d..8e7f1b36c9a 100644 --- src/hg/htdocs/goldenPath/help/trackDb/trackDbSettings.yaml +++ src/hg/htdocs/goldenPath/help/trackDb/trackDbSettings.yaml @@ -1,5188 +1,5209 @@ # 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 , 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 - 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, 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 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.' 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:' 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. 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. 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: 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: 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.' 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 . 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. 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:' 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. 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: 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:' 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: Refer to the SAM format details for a discussion of these values.' description: 'When bamColorMode is set to "gray", you can highlight one of the following: 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. 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. 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.' 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. 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 . 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 only if the track has an explicit color setting or itemRgb off . 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.' 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 . format: colorByStrand <red,green,blue> <red,green,blue> examples: - colorByStrand 255,0,0 0,0,255 - 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: 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. The currently available plot type is histogram , which draws an SVG bar chart from data encoded as space-separated key=value pairs (logfmt format). The histogram plot type accepts the following JSON config keys: title (chart heading) and xLabel (x-axis label).' 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)"}' - 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. 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. 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. 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. 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. 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: 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.' 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: - - bed - 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: - - bed - 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' 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' 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"' 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 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.' 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>' 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.' 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.' 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.' 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.' 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 description: Sets the default color for all of the various highlights defined in this stanza 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.' 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. 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. 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: 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. 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: 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. 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. 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 ".' 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.' 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. 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. + 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. 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. 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. 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.' 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. 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.' format: hapClusterMethod <centerWeighted|fileOrder|treeFile url > examples: [] - 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.' 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: 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: 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: 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: 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. 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