#gffTags handling in .bed files in igv.js arguably ought to comport with that of IGV desktop #1550
Comments
|
This issue seems to not have been actioned. I my hands the #gffTags seem to have no effect whatsoever in the igv.js It is a case that it is simply not supported? |
|
@duartemolha yes that's correct. Unfortunately I'm not made of time, a PR for this would be welcome. |
|
Hi Jim. Please don't take it bad . I was not trying to demand it... Just
wanted the understand the current situation or if I was doing something
wrong in my usage.
Unfortunately I ask not very good with java or JavaScript.
…On Mon, 20 Jan 2025, 16:19 Jim Robinson, ***@***.***> wrote:
@duartemolha <https://github.com/duartemolha> yes that's correct.
Unfortunately I'm not made of time, a PR for this would be welcome.
—
Reply to this email directly, view it on GitHub
<#1550 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFQIVJFB6UQVTJ6R67CQXL2LUOXNAVCNFSM6AAAAABVQCGMPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBSHAZDEMZSG4>
.
You are receiving this because you were mentioned.Message ID: <igvteam/igv
.***@***.***>
|
|
@duartemolha Oh I didn't, just confirming its not done. Unfortunately there are lots of small issues in competition with larger ones, in this project as well as IGV desktop. This would be a good project for a PR. |
|
Honestly I would not even know where to start. Just currious... is there a document explaning the organisation of the code that could help someone willing to help to try to help? |
|
Sure, I'm willing to help. This would be done in js/feature/decode/ucsc.js, specifically the function "decodeBed". Surprisingly there is a variable in that function called "gffTags", but its not used. There's also some code that tries to detect the presence of gff style syntax and parse it as such if found, irrespective of a "gffTag" value. So some start has been made, perhaps it never worked or there has been some regression. |
|
@duartemolha Actually I think I mispoke, I don't recall implementing this but it seems to be at least partially working for the following There is a bug in that the name string is displayed, but the attributes are parsed and appear in popup text 
Could you describe in more detail the issue you are encountering? Is it just that column 4 is displayed as the feature name, or is there more to it? |
…ccordingly, consistent with IGV desktop. See #1550
|
The problem is that the features do not only show the name they are
supposed to display... They show the entire string. In regular IGV if you
have a name tag that is the one that gets displayed
…---------- Forwarded message ---------
From: Jim Robinson ***@***.***>
Date: Thu, 23 Jan 2025, 04:13
Subject: Re: [igvteam/igv.js] #gffTags handling in .bed files in igv.js
arguably ought to comport with that of IGV desktop (Issue #1550)
To: igvteam/igv.js ***@***.***>
Cc: Duarte ***@***.***>, Mention ***@***.***>
@duartemolha <https://github.com/duartemolha> Actually I think I mispoke, I
don't recall implementing this but it seems to be at least partially
working for the following
#gffTags
track name="chr1" description="chr1 Annotations" itemRgb="On"
chr1 1088 1128 Key1=INS230;Key2=Foo 0 + 1088 1088 65,105,225
chr1 133 2809 Key2=Bar;Key1=terminator 0 + 133 133 65,105,225
chr1 1301 1746 Key1=M13 origin;Key2=Baz 0 + 1301 1301 65,105,225
chr1 1301 1746 Key1=M13 origin;Key2=Baz 0 + 1301 1301 65,105,225
There is a bug in that the name string is displayed, but the attributes are
parsed and appear in popup text
Screenshot.2025-01-22.at.8.11.22.PM.png (view on web)
<https://github.com/user-attachments/assets/5c5a0c5d-026d-4e41-8c1f-61a4b258881f>
Could you describe in more detail the issue you are encountering? Is it
just that column 4 is displayed as the feature name, or is there more to it?
—
Reply to this email directly, view it on GitHub
<#1550 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFQIVO32H4SNX3NGPW4AYD2MBT6TAVCNFSM6AAAAABVQCGMPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBYHAYTKNRVGA>
.
You are receiving this because you were mentioned.Message ID: <igvteam/igv.
***@***.***>
|
|
OK, that will be fixed in the next release. |
|
Awesome, thank you so much!
…On Sat, 25 Jan 2025, 20:05 Jim Robinson, ***@***.***> wrote:
OK, that will be fixed in the next release.
—
Reply to this email directly, view it on GitHub
<#1550 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFQIVKYKYQ3W6JXEHNGSMT2MPVATAVCNFSM6AAAAABVQCGMPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJUGA4DGOJQHA>
.
You are receiving this because you were mentioned.Message ID: <igvteam/igv
.***@***.***>
|
…ccordingly, consistent with IGV desktop. See #1550
In IGV desktop it is documented that "GFF3-style attributes (in) the Name field (column 4) of a BED file ... are displayed in the popup text. " and "The GFF Name property will become the display name of the feature" when using the
#gffTagsdirective.Consistent with the this, if there is no Name attribute, the display name of the feature is blank.
In my hands, in igv.js with or without a
#gffTags, the popup text is taken from column 4.This seems reasonable to me, except, there appears to be no control over the display name of the feature.
It would be good if IGV and igv.js agreed in their handling of gffTags, so that the same .bed files can be used to similar effect in both platforms.
I tried as a workaround loading the track with
nameField: nullandnameField: 'IGNORE'andnameField: 0but none had the desired effect of suppressing a display name.FWIW: I also find that the overall length of the GFF3 encoded attributes is limited in igv.js as compared to IGV desktop.
The text was updated successfully, but these errors were encountered: