You can't just liftover from one build to another using only coordinates correct?
1
3
Entering edit mode
6 months ago
curious ▴ 570

Lets say I have (dumb example)

CHROM    POS    REF    ALT
1    1    A    T

Say this site is hg19 and Ref allele is referring the forward strand and maps to position 100 on hg38.

You can just blindly update the position like this correct?

CHROM    POS    REF    ALT
1    100    A    T

I am thinking you cant do this because

  1. The strand might be different (do strands flip between builds?). If so you would have to report the complement of these nucleotides.
  2. The nucleotide at that position might have actually been changed (I would think less likely than #1.

Does this seem right?

liftover • 339 views
ADD COMMENT
0
Entering edit mode

Take a look at crossmap (LINK).

ADD REPLY
0
Entering edit mode
6 weeks ago
david.rinker ▴ 10

You are correct to be cautious. Using a tool like LiftOver will only address shifts in genomic coordinates, and you absolutely cannot assume that variants will always be identical

For example, for 1000 Genomes data there are many "strand flips" noted in the hg38 vcf file. In these cases the "REF" and "ALT" noted in hg19 become their respective complements in hg38. This is potential booby trap for anyone using 1000 Genomes hg38 data, and is not helped by the fact that a) the hg38 documentation doesn't mention these strand flips and b) the 1000 Genomes vcf files are inconsistent and contain some "unflipped" information at flipped sites (e.g. the ancestral allele state at flipped positions is not itself flipped)

I have not found a robust way to address this issue--I can imagine how to code some hacky workarounds but they will not be universally applicable. To do this "right", you really need to go back create a new vcf file from the new genome annotation.

ADD COMMENT

Login before adding your answer.

Traffic: 2307 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6