-
Notifications
You must be signed in to change notification settings - Fork 26
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
Issues parsing nmredata file associated with bruker zip file #2647
Comments
Seems there is a confusion with respect of the structure of the nmrRecord. Currently, nmrium is looking for a file with extension As I can see in the nmredata wiki:
@lpatiny, to support the mentioned folder structure above, I suggest to looks for |
I will read again the original publication. What is strange at first is that the file |
The publication is actually not publicly available (you need to pay to get it). So we should rather base the discussions on http://nmredata.org/. What I see in the provided zip file is that there is no '.sdf' file @CS76 Can you fix your file ? Also did you test it with other softwares that read NMReData ? I would expect that the '.sdf' file also provide an internal reference to the spectrum like:
Because the files are in the zip file but you are currently providing a link to the website |
@lpatiny this file is an export from NMRShiftDB Regarding .sdf extension even though Pseudopelletierin_CDCl3_298.0.nmredata doesn't have a .sdf in its extension it is a valid SDF file with all the NMREDATA_ tags. Should NMRium be looking at the contents of the file if a file .nmredata extension is available? Regarding the spectra location, since the file is an export from nmrshift db the SDF probably the location is referencing the remote server and this can/will be fixed. |
If it is in the specification of the format yes for sure. Can you point me where it is written in the specification that the extension can either be .sdf or .nmredata ? For the location please upload the new file when it is fixed. |
On the official website we have some examples: http://nmredata.org/wiki/Examples and it seems the file could be in many locations. However this does not appear obvious reading 'Link to the spectra' in the page: http://nmredata.org/wiki/NMReDATA_tag_format#.3CNMREDATA_1D_1H.3E. It is written @djeanner Could you comment on this ? Is many 'Spectrum_Location' allowed ? @jobo322 Could you check that we can correctly read the official example: I think loading the files should be done like today but we need to analyse the .sdf files in order to create the links and assignments. We may need some refactoring of https://github.com/cheminfo/nmredata/ and maybe some utilities to link assignment to spectra. |
I am not implying that this is part of the specifications, but earlier, NMRium failed to load the spectra when the zip folder has a file with .nmredata extension without .sdf. My suggestion is to make sure that we read the contents of the file if the extension implies it's a nmredata file. But thanks to @hamed-musallam with the recent fix, zip file loading works now.
As I mentioned, this record is from NMRShiftDB and in the following document It does specify the link to a web-accessible downloadable zip file. If the relative paths are required for linking assignments to spectra we can update those. |
yes, it is loading with a small fix on nmredata package, seems the parseSDF package returns the nmredata version as a number and it was not expected. also is it possible to have more than one Spectrum_Location tag, I will check how our package response in this situation. |
@CS76 in order to link the information inside of the .nmredata to the local spectra in the folder, the In the case that we support a An example of the actual format of nmredata that nmrium supports is: |
@CS76 could you check the functionality in the preview in |
@CS76 Can you provide a fixed NMReData file in which Spectrum_Location points to a relative file or folder included in the zip. |
Folder structure:
Example zip file for testing: Pseudopelletierin_CDCl3.zip
The text was updated successfully, but these errors were encountered: