Web VEP: fix incorrect variant end

[nuno-agostinho]

User-requested bug fix: This PR fixes the incorrect END location for short variants in web VEP by storing this information into the INFO/END field by default, as already done for SVs.

Motivation

Web VEP is returning incorrect END location for multiple variants when using rsIDs. Given that web VEP output is in VCF format, no END location is available by default. To prepare the variant location, web VEP first checks if it's stored in INFO/END field, otherwise it calculates based on the length of the reference allele: https://github.com/Ensembl/public-plugins/blob/main/tools/modules/EnsEMBL/Web/TmpFile/VcfTabix.pm#L254-L264

VEP stores the correct END position in the VariantFeature object. As such, we simply need to save this into the INFO/END field of the VCF output, like in SVs. As this is done for SVs by default, this could also be the default for short variants.

Testing

Compare results for the following variants between:

• VEP CLI with default output: correct location
• Web VEP in current website: calculated END location that is incorrect when compared with VEP CLI
• Web VEP in my sandbox: should have the same (correct) location as VEP CLI

rs746071566
rs3064744
rs72549309
rs267608279
rs72549346
rs72549356
rs72549352
rs72549354
rs72549353
rs5030656

[nakib103]

Hi @nuno-agostinho ,

Thanks for the changes. I can see it has updated the END value of the variant to be same as what we get in the CLI. I tested with two variants, and from CLI I get -
rs72549353: 22:42128251-42128254
rs5030656: 22:42128176-42128178

In the sandbox they gave the same END value - http://wp-np2-11.ebi.ac.uk:7070/Homo_sapiens/Tools/VEP/Results?tl=smKQK4ocAyXPdUac-1

But you will notice that the start value does not match. Is that something you think we should consider? Notice that in the CLI we minimise the allele and gets the position.

[nakib103]

The first variant got position -
22:42128250-42128254 - which kind of makes sense if we think as VCF representation

The second variant got -
22:42128174-42128178 - which is not a VCF representation, but can be considered correct if we think the allele is minimised.

[nuno-agostinho]

Hey @nakib, do you think we should output a START field, similar to END?

START could be created based on $vf->{original_start} (42128174 for rs5030656 and 42128249 for 42128249). This makes me question if we should also use $vf->{original_end} for the END location, what do you think?

[nakib]

Hey @nakib, do you think we should output a START field, similar to END?

START could be created based on $vf->{original_start} (42128174 for rs5030656 and 42128249 for 42128249). This makes me question if we should also use $vf->{original_end} for the END location, what do you think?

Hey there, @nuno-agostinho! Nakib here, albeit a different one. :)

[nakib103]

Hi @nuno-agostinho,

Yes it makes sense to use $vf->{original_start}. We have UPLOADED_ALLELE and REF_ALLELE in the web VEP output. Than it would at least be matched with the UPLOADED_ALLELE. Furthermore this is also what is reported by the Variant Table page for location.

Currently it is not matching either of the allele from those two column values.