LOVD endpoint sometimes does not lift over while VV does

[ifokkema]

I think I need to put this here, as it seems to be an issue with the LOVD endpoint (so, VariantFormatter) and not with the VV endpoint. If you'd rather just have me always dump everything in the VV repo, let me know, so I don't have to think about that anymore 😆

While lifting over a lot of hg38 variants to hg19, some ended up not having a hg19 equivalent. However, when I sent the same genomic variant to the VV website, I did get an hg19 mapping. So I think it's an issue with VariantFormatter.

Links:
NC_000006.12:g.32038297C>T gets no hg19 mapping from the LOVD endpoint but does get one when submitted through VV.

All variants that I found that have this problem:

• NC_000006.12:g.32038297C>T
• NC_000012.12:g.80460707A>G
• NC_000012.12:g.80460829T>A
• NC_000022.11:g.19723410C>G
• NC_000023.11:g.77456433C>T
• NC_000023.11:g.77456433C>T

[ifokkema]

Hi @Peter-J-Freeman @John-F-Wagstaff
Just wondering if you saw this; it could be a quick fix, maybe?

[John-F-Wagstaff]

@Peter-J-Freeman may correct me, but I think that we where trying to keep all the bug reports in the main VV repo, it makes it easier to track and there is enough cross-talk that trying to keep things separate is often more confusing than helpful.

Pete do you want me to have a look at this or does it look like something you want to look at, hitting code that you would be more experienced in, or etc?

[Peter-J-Freeman]

@John-F-Wagstaff I will take a look and will open an issue in VV