cansas multid: Difference between revisions
From canSAS
(not just XML anymore) |
m (added some web links) |
||
| (One intermediate revision by the same user not shown) | |||
| 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 | = standard for reduced multi-dimensional small-angle scattering data with multi-dimensional = | ||
XML? HDF? | 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 = | |||
[http://en.wikipedia.org/wiki/XML XML]? | |||
[http://hdf.ncsa.uiuc.edu/ HDF]? | |||
[http://www.nexusformat.org NeXus]? | |||
Something else? | |||
== Key Points so far == | == Key Points so far == | ||
* with the 1D format agreed, we should look at 2D data | * 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 should also consider how different we are from [http://www.nexusformat.org NeXus] and then why | ||
* We must address data beyond simple 2D detector patterns (multi-dimensional data) | * We must address data beyond simple 2D detector patterns (multi-dimensional data) | ||
** kinetic/time-resolved stuff (frames, periods, whatever you call them), | ** 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) | ** 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! | * quite happy to abandon human-readability ... even prepared to consider binary storage! | ||
* We have benefited | * We have benefited from the [http://www.nexusformat.org/Instruments NeXus instrument dictionary]. | ||
* The time is now ripe to show the use of HDF for storing multi-dimensional data, only using pure HDF5. | * The time is now ripe to show the use of [http://hdf.ncsa.uiuc.edu/ HDF] for storing multi-dimensional data, only using pure HDF5. | ||
* Regarding the cansas1d/1.0 XML format: | * Regarding the [[cansas1d_documentation | cansas1d/1.0 XML format]]: | ||
** table structure used in the 1D format is quite 'tag-heavy' and just will not extend easily. | ** 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. | ** 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 | * For multi-dimensional data, rather than create anew, chose to model the data structures based on the structures in popular use (such as a popular commercial application). | ||
Latest revision as of 16:43, 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? NeXus? 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 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, rather than create anew, chose to model the data structures based on the structures in popular use (such as a popular commercial application).
