abecasis
commented
6 years ago Hi Ryan,
I agree, with the proviso that for LocusZoom we really need regions, rather than independent hits.
I think both Matthew (ENCORE) and Peter (PheWeb) have code to generate lists of regions or top hits that you could repurpose.
G
Sent from my iPhone
On Apr 4, 2018, at 3:13 AM, Ryan Welch notifications@github.com wrote:
We currently have a GWAS loci table on the right side of the interactive locuszoom.js site:
It has two problems/errors:
It retrieves loci from the EBI GWAS catalog, but coordinates retrieved are GRCh38, while most plots are GRCh37. To my knowledge, the EBI API does not have any option to retrieve 37 coordinates, we would need to do this ourselves. It cannot match the trait from the catalog with the trait of the dataset being displayed, so the loci shown in the table aren't really correct. This is really the largest problem. I think both problems would require enough time to fix that it's not worth the trouble to do it currently.
Probably the best way to do this would be to detect the top "independent" hits directly from the association results, and provide a table of those. And put a little warning that since we determined the "independent" hits ourselves, they might not exactly match the loci reported in the paper, but should be close enough as to guide people to the right regions. This would require some kind of API endpoint, since the work needs to be done server side to do this.
Until then, I would suggest removing or commenting out the table since it's currently wrong, and misleading users.
Other comments/solutions welcome.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
welchr
We currently have a GWAS loci table on the right side of the interactive locuszoom.js site:
It has two problems/errors:
I think both problems would require enough time to fix that it's not worth the trouble to do it currently.
Probably the best way to do this would be to detect the top "independent" hits directly from the association results, and provide a table of those. And put a little warning that since we determined the "independent" hits ourselves, they might not exactly match the loci reported in the paper, but should be close enough as to guide people to the right regions. This would require some kind of API endpoint, since the work needs to be done server side to do this.
Until then, I would suggest removing or commenting out the table since it's currently wrong, and misleading users.
Other comments/solutions welcome.