68b9911e4c156cd1346fde5c957434b1a8780d1c max Wed Sep 9 08:49:07 2026 -0700 Show the transcript's own codon number where it differs from the genomic one The gene tracks count codons along the genome. A RefSeq transcript is a sequence in its own right, so where it has an insertion or a deletion relative to the assembly, every codon 3' of that point gets a different number here than the sequence provider gives it, one codon per three bases. DNM1 on canFam3 is the reported case: the transcript carries 21 bases canFam3 does not, so our p.249 is NCBI's p.256. Neither number is wrong, but HGVS c./p. is defined on the transcript, so the number people quote is the one we were not showing. The genomic number and amino acid are unchanged. Codons whose two numbers disagree now draw in the existing CDS_QUERY_INSERTION orange with a "!" after the codon number, and their mouseover adds the transcript number plus a link to a new FAQ entry. Both directions of indel are covered, and so is the case where the alignment does not reach the start of the CDS (801 transcripts on hg38), which needs the transcript's own CDS annotation as the anchor rather than the alignment. Numbers come from the transcript alignment, ncbiRefSeqPsl or refSeqAli, which is the same source hgvsMapToGenome already uses, so the browser now agrees with its own position search. Two queries per table per window, on the bin index, and only at zoomedToCdsColorLevel, where the mouseover carrying the numbers is drawn: on and off are within noise at every zoom. Gated by showTxCodonNumbers in hg.conf, default off, catalogued as a release gate. With it off nothing is looked up and the rendering and mouseover are byte-identical to before. refs #38298 diff --git src/hg/htdocs/FAQ/FAQgenes.html src/hg/htdocs/FAQ/FAQgenes.html index 3f24f5624b0..1865660b1a4 100755 --- src/hg/htdocs/FAQ/FAQgenes.html +++ src/hg/htdocs/FAQ/FAQgenes.html @@ -13,30 +13,32 @@
@@ -425,30 +427,87 @@ indicating unalignable transcript sequence.
Data format: A small difference is the data format, which matters if you integrate our files into pipelines: The refGene table qName field stores the RefSeq accession but without the version number. The ncbiRefSeq tables show the full accession, with the version number. To add the version number to the refGene table, use a MySQL command like this:
SELECT matches,misMatches,repMatches,nCount,qNumInsert,qBaseInsert,tNumInsert,tBaseInsert,strand,concat(qName, '.', gbSeq.version),qSize,qStart,qEnd,tName,tSize,tStart,tEnd,blockCount,blockSizes,qStarts,tStarts from refSeqAli, hgFixed.gbSeq WHERE refSeqAli.qname=gbSeq.acc
To remove the transcripts on haplotypes, add this condition at the end:
and tName NOT LIKE '%_hap%' AND tName not like '%_alt%' AND tNAME NOT LIKE '%_fix%'
A word of caution on the NCBI RefSeq track on hg19: NCBI is not fully supporting hg19 anymore. As a result, some genes are not located on the main chromosomes anymore. An example is NM_001129826/CSAG3. For hg19, you may prefer UCSC RefSeq for now.
+ ++Because a RefSeq transcript is a sequence in its own right, not a slice of the genome, the two +can differ in length. Where the transcript carries bases the assembly does not, or the assembly +carries bases the transcript does not, there are two defensible ways to number the codons of +that transcript, and they disagree from the indel onwards: +
++Each codon after the difference is shifted by one for every three bases involved. A 21-base +insertion in the transcript, for instance, puts the two counts seven codons apart for the whole +rest of the coding sequence. Neither number is wrong; they answer different questions. But if +you are writing or reading an HGVS description, the transcript count is the one that is +meant, because HGVS c. and p. coordinates are defined on the reference +transcript. +
++This affects RefSeq only. GENCODE, Ensembl and UCSC Genes transcripts are derived from the +assembly, so their coordinates cannot disagree with it and this problem cannot arise. RefSeq +transcripts are aligned to the assembly instead, so it can, and it affects both the +"NCBI RefSeq" and the "UCSC RefSeq" tracks — often by different amounts, +because the two use different alignments (see +the previous question). +
++It is uncommon in human and much more common in other assemblies, and the less complete the +assembly, the more often it happens. In human it clusters in long repetitive coding genes: +MUC2 carries about 2,900 coding bases that GRCh38 lacks, and FCGBP about +3,500. Shirota et al. catalogued these discrepancies systematically +(Database 2016, baw124, +PMID +27589963), and the HGVS +nomenclature pages discuss what it means for choosing a +reference +sequence. +
++The orange marking above lets you tell at a glance that a number you are about to quote is not +the transcript's own. The +underlying insertion or deletion itself is shown in the "RefSeq Alignments" and +"RefSeq Diffs" subtracks of the RefSeq container. Searching the browser for an HGVS +term such as NM_002457.5:c.11671A>G uses the transcript numbering and maps it +through the alignment, so it lands on the right base either way. +
+The mitochondrial sequence included in assembly sequence files is a special case and most of what has been explained on this page does not apply to the mitochondrial gene annotations. For most assemblies in the Genome Browser, the sequence name of the mitochondrial genome is "chrM".
Both GENCODE and RefSeq databases import their mitochondrial gene annotation directly from the rCRS RefSeq record NC_012920.1. RefSeq does not assign NM_ transcript accessions for mitochondrial genes, only NP_ protein accessions, as there is no splicing. The mitochondrial annotation for both databases was provided by