draeger-lab / EscherConverter

A standalone program that reads files created with the graphical network editor Escher and converts them to files in community standard formats.
https://draeger-lab.github.io/EscherConverter/
MIT License
15 stars 10 forks source link

Connections gone after conversion #34

Closed anusurendra closed 5 years ago

anusurendra commented 5 years ago

I used KeggTranslator to convert a KGML file to SBML. Then am using the EscherConverter to convert it to JSON map file to put into Escher. However, when I load the converted map to Escher, the arrows and connectors (ie the reaction direction) are gone:

escher_img

draeger commented 5 years ago

Could you please provide the KGML file and the SBML file you generated from it?

anusurendra commented 5 years ago

@draeger , Attached are the KGML and SBML files: hsa00630.sbml.zip hsa00630.xml.zip

Thanks again for your help

draeger commented 5 years ago

Which command-line options did you use in EscherConverter for the conversion? Could you directly provide the JSON file also, please?

anusurendra commented 5 years ago

@draeger,

The command I am using is java -jar EscherConverter-1.2.0.jar --input=/home/surendraa/Downloads/hsa00630.sbml --output=/home/surendraa/Downloads/hsa00630.json --format=Escher --log-level=ALL --gui=FALSE --canvas-default-height=1E9 --canvas-default-width=1E9 --label-height=1E9 --label-width=1e9

Attached is the converted json file:

hsa00630.json.zip

draeger commented 5 years ago

I noticed why no arrows are added. The responsible class is SBML2Escher, where the method createSegments has an if clause whose body only gets executed if a listOfCurveSegments is defined. However, the SBML layout specification defines an alternative way of specifying how to connect speciesGlyphs and reactionGlyphs via the boundingBox of the speciesReferenceGlyph. KEGGtranslator does not create any curve objects so that this condition is never satisfied. However, your example SBML file also doesn't contain any bounding boxes for speciesReferenceGlyphs either. It seems that KEGGtranslator did not create those. At this time, I don't know why they are missing, but it is clear that EscherConverter does require Curve objects here. It would need changing the implementation to get this fixed.

anusurendra commented 5 years ago

@draeger , The SBML file was created by the KEGGtranslator, using the default preferences, to convert the KGML file to SBML. I pulled down the KGML file using wget http://rest.kegg.jp/get/hsa05130/kgml 2>&1 hsa00630.xml. I tried to use KEGGtranslator to directly pull down the KGML file but I kept getting a unable to connect to Kegg error. That is why I used wget. Should I have converted it to SBML_L3V1, instead of SBML? Thanks again for your help

anusurendra commented 5 years ago

@draeger ,

Attached is a picture of the conversion using KeggTranslator: image

Here are the preferences used: image

image

draeger commented 5 years ago

It is recommended to check the boxes Remove orphans (to remove nodes that are no longer connected to any process after augmenting KEGG's information) and Remove white gene nodes because the purpose of creating a model from KEGG is to be specific to a target organism or tissue. White nodes are those that refer to a non-existing generic organism. But both shouldn't impact how the SBML is created.

draeger commented 5 years ago

In response of the question

Should I have converted it to SBML_L3V1, instead of SBML?

Yes, because it is more specific, but it seems this is the default already.

anusurendra commented 5 years ago

@draeger , I have made the changes that you recommended and converted it to SBML_L3V1. However I still get the same error: image

image

image

draeger commented 5 years ago

It is not surprising because the SBML is still generated in the same way. You just receive a slightly different structure. The problem you are encountering seems to be a combination of an error in KEGGtranslator that does not write out boundingBoxes for speciesReferenceGlyphs and EscherConverter that expects even curve objects to be defined in the SBML files and cannot deal with the information from speciesReferenceGlyphs alone. However, it is not that difficult to guess from the position of nodes and the position of reaction centers where the arrows should be.

draeger commented 5 years ago

So, the easiest fix would be to change the interpretation of SBML in EscherConverter in method createSegments. There should be an else clause that tries to infer curve segments from speciesReferenceGlyphs. I will look into that, but it will take a bit time.

anusurendra commented 5 years ago

@draeger , Do I make this change in the source code and then recreate the jar file?

Thanks again.

draeger commented 5 years ago

It requires me to create a new release. If you can fix it yourself, I'd be happy to review your patch. That's probably faster. Otherwise, I'll do it.

anusurendra commented 5 years ago

@draeger ,

I am looking for that method and do not find it. Is it within escherconverter.py?

draeger commented 5 years ago

Here: https://github.com/draeger-lab/EscherConverter/blob/0240fde235b85188a6b071f4b5d534bd8c8105ef/src/main/java/edu/ucsd/sbrg/escher/converter/SBML2Escher.java#L515

anusurendra commented 5 years ago

@draeger ,

Thanks again. I will try to make a patch. How long would the wait for a new version of the EscherConverter be?

draeger commented 5 years ago

@anusurendra, if you are interested, we could add improvement of EscherConverter as a new Google Summer of Code project to https://github.com/nrnb/GoogleSummerOfCode/issues/. You would be welcome to apply for working on this funded by Google if this is appropriate. I'd be happy to guide you writing the proposal and as a mentor during the project.

anusurendra commented 5 years ago

Andreas,

Apologies for the delayed response. This improvement of EscherConverter as a new Google Summer of Code project is a wonderful suggestion. I would be very interested in this. Is this option still viable?

Anu Surendra

On Wed, Mar 6, 2019 at 3:07 AM Andreas Dräger notifications@github.com wrote:

@anusurendra https://github.com/anusurendra, if you are interested, we could add improvement of EscherConverter as a new Google Summer of Code project to https://github.com/nrnb/GoogleSummerOfCode/issues/. You would be welcome to apply for working on this funded by Google if this is appropriate. I'd be happy to guide you writing the proposal and as a mentor during the project.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/draeger-lab/EscherConverter/issues/34#issuecomment-470008874, or mute the thread https://github.com/notifications/unsubscribe-auth/AFbCLGbCwx52QUoajrVHazJggqC6AAr0ks5vT3clgaJpZM4Z_m0Q .

draeger commented 5 years ago

@anusurendra, Unfortunately, EscherConverter isn't part of Google Summer of Code this year. The deadline has already passed. We will need to move forward in different ways. I will try to put resources into fixing the problem. Thanks for the reminder.

anusurendra commented 5 years ago

Andreas,

Thanks for letting me know. Please keep me posted on any opportunities where I can help and be part.

Anu Surendra

MariaHei commented 5 years ago

I'm currently trying to fix this.

draeger commented 5 years ago

This issue has been fixed with #37.