This is a test version of Biostars. For the public version, visit https://www.biostars.org.
Lifting over with rtracklayer vs UCSC

When I lift this region: chr1 145686997 145808272 from hg38 to hg19 on UCSC browser I get: chr1 145626811 145748066. However if I do the same with rtracklayer (R package) I get a bunch of fragment overlaps, and if I take min of start and max of end it corresponds to: chr1 145626812 145748067

Why is it slightly different? Also, is there a simple way to obtain a 1-to-1 mapping as in UCSC instead of the several fragment overlaps using this tool? I'm not sure if min and max is the clean way.

hg38 rtracklayer ucsc hg19 liftover

1 answer

The 1 bp isn't liftOver disagreeing with itself, it's that the same numbers went into two different coordinate conventions. UCSC's tool reads input as BED (0-based, half-open); a GRanges is 1-based inclusive. Convert UCSC's output out of BED and its start becomes 145626812, which is exactly what rtracklayer gave you - what's left at the other end is the half-open end plus the fact that the interval you handed rtracklayer began one base earlier than the one UCSC lifted.

On the fragments, rtracklayer is showing you the truth and UCSC is hiding it. The chain really does break that region into blocks; the web tool collapses to one interval when enough of the region maps (minMatch 0.95 by default). Taking min start and max end silently spans whatever sits between the blocks, so it's only safe if they're contiguous and in order. Run reduce() on what comes back - if it collapses to a single range you're fine and it'll agree with UCSC, and if it doesn't, the region doesn't lift as a unit and UCSC's tidy answer is the misleading one.

Log in to answer this question.