bigDataUrl <url/relativePath>Required: For Hubs
The location of a remote data file containing the bulk of the data for the track. This setting is required for all data tracks in a track hub.
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.
Example:
bigDataUrl http://vizhub.wustl.edu/VizHub/hg19/biBrainH3K4me1.bbor
bigDataUrl biBrainH3K4me1.bb
bigDataIndex <url/relativePath>The location of a remote data file containing the index. This setting @@ -660,31 +660,31 @@ 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, ...
Example:
downloadUrl GFF https://mywebsite.com/ucscTrack.gff.gzor
downloadUrl.1 "GFF Format" https://mywebsite.com/ucscTrack.gff.gz
downloadUrl.2 "BED Format" https://mywebsite.com/ucscTrack.bed.gz
otherSpecies <otherSpecies>The name of the other assembly in the pairwise alignment for this track.
Example:
otherSpecies tweeter
The other species (other than the reference) in the alignment is the tweeter assembly in the same HAL file.
otherDb <otherDb>Track types that show pairwise alignments often need to declare the other species/assembly included in the alignment. Types that use this setting include bed, chain, netAlign, psl and snake.
Example:
otherDb mm10
This example sets the second assembly in the alignment to the mouse mm10 assembly.
@@ -2196,43 +2196,43 @@ exceeded, the track switches to coverage mode. Default: 1000. Fortype 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.
Example:
maxItems 25
maxWindowCoverage <integer>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.
Example:
maxWindowCoverage 10000000
Browser images that show more than 10,000,000 bases will result in the track data being displayed as a density coverage graph.
maxWindowToDraw <integer>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,
@@ -2908,31 +2908,31 @@
maxHeightPixels <max:default:min>The amount of vertical viewing space for your signal track should be declared, though it is configurable by the user. Typically it is set to no more than 100 pixels and no less than 8, with a default of 16 or 32 pixels.
Example:
maxHeightPixels 100:16:8
The browser will display the track as 16 pixels high, but the user can scale it up to 100 pixels.
maxWindowToQuery <integer>For bigWigs only
When signal data is clicked in the Browser image, the details of the signal in the current viewing window are displayed. For bigWigs that reference remote data, the query can be a very expensive operation if the current window is large. To avoid overburdening the Browser, the size of the window to query should be limited. The value of this setting is the maximum window size in bases that should be queried to give the detailed signal numbers.
negateValues <on>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