cansas multid: Difference between revisions
From canSAS
(not just XML anymore) |
No edit summary |
||
Line 1: | Line 1: | ||
''Note: please keep discussion content on the [[Talk:cansas_multid | discussion]] page. Your contributions may get moved there anyway.'' | ''Note: please keep discussion content on the [[Talk:cansas_multid | discussion]] page. Your contributions may get moved there anyway.'' | ||
= standard for reduced small-angle scattering data with multi-dimensional data = | = standard for reduced multi-dimensional small-angle scattering data with multi-dimensional = | ||
At this time (May 2008), [[Talk:cansas_multid | discussion]] of the standard is just starting. | |||
These pages are being used to gather the considerations for a | |||
proposed standard for saving and communicating reduced multi-dimensional | |||
small-angle scattering data. The standard will also | |||
describe how to save and communicate the results of processing or | |||
analysis steps, as does the recently established [[cansas1d_documentation | standard]] | |||
for saving and communicating one dimensional SAS data using XML. | |||
= Considerations = | |||
XML? HDF? Something else? | XML? HDF? Something else? |
Revision as of 16:24, 9 May 2008
Note: please keep discussion content on the discussion page. Your contributions may get moved there anyway.
standard for reduced multi-dimensional small-angle scattering data with multi-dimensional
At this time (May 2008), discussion of the standard is just starting. These pages are being used to gather the considerations for a proposed standard for saving and communicating reduced multi-dimensional small-angle scattering data. The standard will also describe how to save and communicate the results of processing or analysis steps, as does the recently established standard for saving and communicating one dimensional SAS data using XML.
Considerations
XML? HDF? Something else?
Key Points so far
- with the 1D format agreed, we should look at 2D data
- we should also consider how different we are from NeXus and then why
- We must address data beyond simple 2D detector patterns (multi-dimensional data)
- kinetic/time-resolved stuff (frames, periods, whatever you call them),
- other experiments where data is being collected as a function of some variable (temperature, pH, or whatever)
- quite happy to abandon human-readability ... even prepared to consider binary storage!
- We have benefited a little from [the NeXus] instrument dictionary.
- The time is now ripe to show the use of HDF for storing multi-dimensional data, only using pure HDF5.
- Regarding the cansas1d/1.0 XML format:
- table structure used in the 1D format is quite 'tag-heavy' and just will not extend easily.
- takes a little bit more work to extract the I(Q) data into vectors for use in processing or analysis software.
- For multi-dimensional data in XML, rather than create anew, I chose to model the data structures from a popular commercial application.