[ensembl-dev] can VEP produce co-located variants match taking account the protein change?

[David Tamborero]

understood, thanks for your answer!

(and yes, the vep mapping of the annotation knowledgebases 'in advance' is
what i have in place now)

thanks again for taking the time to check it out
best
d

El mar., 26 mar. 2019 a las 12:51, Andrew Parton (<aparton at ebi.ac.uk>)
escribió:

> Hi David,
>
> Hope you’re well. We’ve had a chat about this issue yesterday,
> unfortunately this is not something that we currently support, or could
> provide a quick fix for. However, we will be providing improvements to our
> protein annotations within the coming months, and we will keep this
> suggestion in mind if we feel this is something we could implement in the
> future.
>
> The easiest solution, as we see it, would be to run VEP on both files and
> compare the HGVSp outputs at the end.
>
> Kind Regards,
> Andrew
>
> On 15 Mar 2019, at 18:13, David Tamborero <david.tamborero at gmail.com>
> wrote:
>
> Thanks! Have a great weekend
>
> El vie., 15 mar. 2019 18:31, Andrew Parton <aparton at ebi.ac.uk> escribió:
>
>> Hi David,
>>
>> Thanks for the suggestion, we’ve had similar queries to this before. I’ll
>> discuss it with the team on Monday and get back to you.
>>
>> Kind Regards,
>> Andrew
>>
>> > On 15 Mar 2019, at 14:01, David Tamborero <david.tamborero at gmail.com>
>> wrote:
>> >
>> > I received a weird @vep email, and now i m unsure of whether this was
>> published (cannot see it in the archive), so I send it again. Apologies if
>> this is not the case.
>> >
>> > =
>> >
>> > Hello there,
>> >
>> > I m writing with further VEP whishes! The context is that I m matching
>> the  variants given to VEP with the content of a given database(s) that
>> report variant effects (e.g. biomarkers of drug response). I m currently
>> passing these knowledgebases to VEP as a vcf (with the corresponding .tbi)
>> with the --custom flag, which works lovely.
>> >
>> > The thing is that I m also interested to have a match when the
>> nucleotide change of the input variant is not the same than the one from
>> the database *but* it leads to the same aminoacid change; something like:
>> >
>> > database:  chr1:xxxxxA>C   (geneX p.V28E)
>> >
>> > input:  chr1xxxxxxA>C   (geneX p.V28E)  produces a 'perfect match'
>> > input: chr1yyyyyyyG>T    (geneX p.V28E) produces an 'aminoacid match'
>> >
>> > My plan is to keep using your --custom flag to retrieve the 'perfect'
>> match and then to have my own script to retrieve the 'aminoacid match'.
>> However, as you know, this is kind of a hassle (need to map the variants of
>> the original databases with VEP to ensure that the protein statements are
>> fully compatible, and I need to do it each time there is an update etc etc).
>> >
>> > In other words, it would be more neat and easy if this 'aminoacid
>> match' is provided by VEP given the --custom vcf file(s). By any chance, do
>> you have some option (that I did not see) that magically does it, or any
>> option that you can implement this in some incoming release?
>> >
>> > (as for other requests, I think that this is a feature that would be
>> useful for other users)
>> >
>> > Thanks a lot in advance!
>> > br
>> > _______________________________________________
>> > Dev mailing list    Dev at ensembl.org
>> > Posting guidelines and subscribe/unsubscribe info:
>> http://lists.ensembl.org/mailman/listinfo/dev
>> > Ensembl Blog: http://www.ensembl.info/
>>
>> _______________________________________________
>> Dev mailing list    Dev at ensembl.org
>> Posting guidelines and subscribe/unsubscribe info:
>> http://lists.ensembl.org/mailman/listinfo/dev
>> Ensembl Blog: http://www.ensembl.info/
>>
> _______________________________________________
> Dev mailing list    Dev at ensembl.org
> Posting guidelines and subscribe/unsubscribe info:
> http://lists.ensembl.org/mailman/listinfo/dev
> Ensembl Blog: http://www.ensembl.info/
>
>
> _______________________________________________
> Dev mailing list    Dev at ensembl.org
> Posting guidelines and subscribe/unsubscribe info:
> http://lists.ensembl.org/mailman/listinfo/dev
> Ensembl Blog: http://www.ensembl.info/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ensembl.org/pipermail/dev_ensembl.org/attachments/20190326/32b10f4a/attachment.html>