Ready for Figure generation

[josiahseaman]

Even more immediate than JBrowse issues 2-8 is the need to get Figures for our paper. Since the browser context won't be in the paper, we need to focus on just the rendering window. We can manually input things like start and stop #4 by editing the code.

• Adjacent connectors drawn (this will show whether the path is present)
• Vertical Compression: Never show rows that are not present in the current view window
• Vertical Compression: Stack all the participants to the top of each component to show the proportion that participates in a Link (on by default)

[subwaystation]

@josiahseaman Could you please explain the first point? I understand it as a duplicate of #2?
Thanks!

[subwaystation]

Ah it just came to my mind, what you meant with adjacent connectors.
So we will need the connectors and still an indication, where the paths starts, right?
Because the connectors only follow a path, but don't indicate the starting or ending bin of a path.

[josiahseaman]

100% height of a component = 100% of the individuals which participate in the component. That way LinkColumn height to be proportional. eg. 20% or 5% of population has this SV.

[subwaystation]

I think we also need:
100% height of a component = 100% of paths in the whole pangenome?
So people can have an idea of the SV regarding all paths crossing the component and all paths in the pangenome.

[josiahseaman]

Adjacent connections will show that a path is present in the component, even when it doesn't have any SVs. Without vertical compression, that does give you an indication of where a path starts or stops (kinda). But with vertical compression on (no SV phase) that per-row information is not visible. We could include a special connector symbol for beginning and end, but I think #2 is a low priority.

[subwaystation]

I am seeing really weird stuff happening when visualizing ./data/sebastian.Athaliana.all.50000.w100000.schematic.json when checking out 71217e3.

There is a rectangle directly under download. A link arrow is drawn, but no link column, etc.
Maybe

Schematize/src/App.js

Line 65 in 71217e3

visibleHeight(){

is a problem?

[subwaystation]

When taking a look at ./data/sebastian.Athaliana.all.50000.w100000.schematic.1D.json I get some weird output, too.

[subwaystation]

Ok, I fixed this via d0261fb. I suspect, that we might run into other issues related to .....departures.length - 1 vs. departures.length in our code.

Still need to adjust the width of the adjacent connectors.

[subwaystation]

@josiahseaman As you can see here, the width of the adjacent connectors is too wide. Removing *2 in

Schematize/src/ComponentRect.js

Line 93 in 0df3163

width={this.props.binsPerPixel * 2}

takes care of that.
But then the x-coords of most! components and links does not fit anymore. We need to move a component to the left, if we have drawn any connectors. If not, we should not move them.
See e.g. between the 4th and 5th component in the picture above. The space there is one binsPerPixel smaller compared to when a connector was drawn between two components.

[josiahseaman]

Adjacent connectors have been added as the last LinkColumn in departures. That's why I added departures.length - 1. The same could probably be done for arrivals as well. Since this is to reflect a change in the data, any old data not updated to the current format (generated by component_segmentation after 35807d427a07816e6efdec98bac330701899eaad) will render wrong.

Adjacent connectors should be our column padding size, not binsPerPixel. Sorry, I didn't know where that came from. So that we don't run into this in the future, I think I'll introduce a JSON version number which the program checks and raises an error if the data was produced in a different version than what it's expecting. That'll keep us from getting our data files crossed.

@ekg may want to do the same thing if there's any plans to update the ODGI bin output.

[ekg]

It's not the case that all bins will be connected to adjacent ones. A graph can have unaligned components, and these won't link to anything else.

…

On Mon, Feb 3, 2020 at 5:10 PM Josiah Seaman ***@***.***> wrote: Adjacent connectors have been added as the last LinkColumn in departures. That's why I added departures.length - 1. The same could probably be done for arrivals as well. Since this is to reflect a change in the data, any old data not updated to the current format (generated by component_segmentation after 35807d427a07816e6efdec98bac330701899eaad) will render wrong. Adjacent connectors should be our column padding size, not binsPerPixel. Sorry, I didn't know where that came from. So that we don't run into this in the future, I think I'll introduce a JSON version number which the program checks and raises an error if the data was produced in a different version than what it's expecting. That'll keep us from getting our data files crossed. @ekg <https://github.com/ekg> may want to do the same thing if there's any plans to update the ODGI bin output. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9?email_source=notifications&email_token=AABDQEIMNSD2YEEGNWZIWU3RBA6WTA5CNFSM4KMYJJDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKUNGJQ#issuecomment-581489446>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABDQEODTPIYWOZEUJ6GSGDRBA6WTANCNFSM4KMYJJDA> .

[josiahseaman]

That's a very interesting point! Wouldn't their co-occurrence in a Path cause them to be linked? If they weren't connected to anything, wouldn't the sort move them to the end or beginning?

[subwaystation]

Adjacent connectors have been added as the last LinkColumn in departures. That's why I added departures.length - 1. The same could probably be done for arrivals as well. Since this is to reflect a change in the data, any old data not updated to the current format (generated by component_segmentation after 35807d427a07816e6efdec98bac330701899eaad) will render wrong.

Adjacent connectors should be our column padding size, not binsPerPixel. Sorry, I didn't know where that came from. So that we don't run into this in the future, I think I'll introduce a JSON version number which the program checks and raises an error if the data was produced in a different version than what it's expecting. That'll keep us from getting our data files crossed.

@ekg may want to do the same thing if there's any plans to update the ODGI bin output.

So I raised a false flag by testing with malformed data....... sorry!

[josiahseaman]

Thanks for spotting that. I'm sorry I didn't communicate the data format change more clearly. I've learned my Lesson. I think I'll work on the Histogram feature next, but this would be much more effective with a Toggle Input for the user to turn on and off vertical compression. @subwaystation would you like to try your hand at getting a toggle connected to store.useVerticalCompression?

[josiahseaman]

All 3 features that I wanted for this issue are now in master. Mobx state updates could certainly be cleaner, but it meets our MVP needs. Matrix will be a separate issue.