Hello,
Export is a relatively trivial operation but import is much, much harder.
For one thing, we don't know whether the information has been mucked
around with in a deleterious fashion. For another, not all the
information that is needed to recreate/find the relevant objects is
necessarily in the export. And for another, some of the information in
the output could be derived from other information, and the original
information might not be (uniquely) deducible from what is output.
I suspect we could write a macro for specific imports with specific
assumptions on what is in the file. For example, for the peak lists, if
the headings for the various columns were not changed then even if not
everything was exported I think we could probably do something, so import
into an existing peakList (modifying peaks with matching serials) or
creating a new peakList. Except that the "Assign" fields would probably
not be very useful (at a guess) because the annotation might be modified
but not the actual assignment (unless a slightly clever algorithm was used
but this is potentially dangerous). And the first column (the # or
serial) would have to be a column that is definitely exported and not
mucked around with if you wanted to re-import into an existing peakList.
And possibly other caveats I haven't thought about off the top of my head.
Wayne
On Fri, 26 Feb 2010, Julien Littérature wrote:
> Hi,
>
> I really like the "export" function in analysis that allows to export a table by
> right-clicking on this table and then output a tab- or comma-separated file.
> This is then easy to read in excel/openoffice.
>
> I would like to know if it is possible to re-"import" those comma-separated
> files in analysis?
>
> For example, I would like to export a peak list, make modifications in the
> comma-separated file and then re-import this file as a new peak list.
>
> I already tried to output peak lists using the format converter, using several
> different export formats (sparky, xeasy, nmrview), but they don't retain all
> informations (like peak #, merit, details). Hence, the sparky format doesn't
> seem to accept ambiguous peak assignments.
>
> Thanks,
>
> Julien
>
|