Apply features from a file

Put the annotations from a GTF onto an open sequence — once something has said the two are in the same coordinate space.

What it doesCopy Anchor Link

A GTF is a list of features — exons, CDS, transcripts — with their positions, and no sequence of its own. A collaborator sends one; a gene-prediction run emits one; a browser exports one. It describes a molecule without containing it, so on its own there is nothing to open.

This takes such a file and writes its features onto a sequence you already have. You choose the file, and the sequence within it when it names more than one, and the tool reports exactly what would be written before anything is.

The question it refuses to answer for you is whether the two belong together. A feature at positions 149–199 means something only once something has said which molecule those positions are on. That is the whole of the care here, and the section below is how it is decided.

When you'd use thisCopy Anchor Link

• A prediction came back as a GTF. You ran a gene finder, or a collaborator did, and the result is a coordinate list you want to see drawn on the construct itself.
• Annotations and sequence arrived separately. The FASTA has the bases, the GTF has what is in them, and nothing has joined the two.
• You are checking a prediction against what you already annotated. Features the record already carries at the same span, strand and type are reported as duplicates rather than written twice, so what is added is only what is new.

What this computesCopy Anchor Link

The assembly verdict — four outcomes, and they are not the same claim.

A reference assembly is the genome build a set of coordinates is written against: hg19 and hg38 number the human genome differently, so the same interval is a different place in each. A GTF can name its build in a track … db= line or a GFF3 ##genome-build pragma; most files name none, because the format does not require it.

• The assemblies agree. The file names a build, the record names the same build, and the features are written with no further question asked.
• The assemblies differ. The file says one genome, the record says another. This is refused and cannot be confirmed past: lifting an interval from one build to another moves it, often by thousands of bases, and the conversion is a real operation — not a permission.
• The file names a build and the record does not. Nothing can confirm the correspondence.
• Neither names one. The commonest case, and the honest description of most annotation files.

The last two are refused by default and can be resolved only by you, at the point of use, by stating that you are applying the intervals as coordinates — positions in this record's own numbering, with no genome correspondence checked. That statement is recorded in the entry the history keeps, so a record annotated on that basis says so afterwards rather than reading like one whose builds matched.

What is written, and what is not.

• Positions are taken as they are. GTF counts from 1 and includes both ends; the reader converts once, and nothing here adjusts them again.
• A feature that does not fit is reported, never shortened. If a span runs past the end of the record it is listed with the end it actually has. A feature clipped to fit would be a different feature, silently.
• Strand is carried. A feature on the minus strand stays on the minus strand.
• Features the record already carries are skipped, matched on span, strand and type together — so the same interval annotated as a CDS and as an exon counts as two things, because it is.
• Everything is one step. The whole batch is a single entry in the history, so one undo reverses one apply.

ProvenanceCopy Anchor Link

The reader is graded against gffutils, the reference GFF/GTF library, over 110 files.