Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

trim spaces in text labels of data nodes #47

Open
egonw opened this issue Dec 15, 2015 · 5 comments
Open

trim spaces in text labels of data nodes #47

egonw opened this issue Dec 15, 2015 · 5 comments

Comments

@egonw
Copy link
Member

egonw commented Dec 15, 2015

In the current GPML created some labels have redundant spaces at the end of labels, e.g. in WP3579:

<DataNode TextLabel="PC " GraphId="cdb40" Type="Metabolite" GroupRef="bbf32">
  <Attribute Key="cellular_location" Value="endoplasmic reticulum membrane" />
  <Attribute Key="complex_id" Value="R-ALL-5684863" />
  <Attribute Key="copies_num" Value="1" />
  <Graphics CenterX="240.0" CenterY="1851.0" Width="100.0" Height="20.0" ZOrder="32768" FontSize="10" Valign="Middle" Color="0000ff" />
  <Xref Database="ChEBI" ID="CHEBI:16110" />
</DataNode>
@DeniseSl22
Copy link
Contributor

I'll check if this is still occurring in newer versions; but this could be due to curators in Reactome accidentally adding a space. And I'll try to get the trim() integrated in the pathways.

@egonw
Copy link
Member Author

egonw commented Oct 28, 2018

Yes, still the case in the current output:

  <DataNode TextLabel="Dovitinib " GraphId="ba4b1" GroupRef="d4f5d">
    <Attribute Key="cellular_location" Value="cytosol" />
    <Attribute Key="complex_id" Value="R-ALL-2045079" />
    <Attribute Key="copies_num" Value="1" />
    <Graphics CenterX="0.0" CenterY="0.0" Width="0.0" Height="0.0" ZOrder="32768" FontSize="10" Valign="Middle" />
    <Xref Database="" ID="" />
  </DataNode>

@DeniseSl22
Copy link
Contributor

Okay, I'll add this to the converter code asap, but will be fixed then in version 67 (or is it a necessary fix for older versions?)...

@egonw
Copy link
Member Author

egonw commented Oct 29, 2018

No, for version 67 sounds fine. Is that the latest version in this round, or the next? You could always opt to redo the last one you have now...

@DeniseSl22
Copy link
Contributor

Okay, good. 67 would be the next version, but I can do the testing on version 66. But I want consistency for the previous version uploads, since it is otherwise to difficult for me to pinpoint where things are breaking down 9if they do).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants