The new "Snapshots" system in Spectral Workbench brings the ability to maintain different version...
Public Lab is an open community which collaboratively develops accessible, open source, Do-It-Yourself technologies for investigating local environmental health and justice issues.
4 CURRENT | larsonreever |
January 31, 2017 16:36
| almost 8 years ago
The new "Snapshots" system in Spectral Workbench brings the ability to maintain different versions of a spectrum for different uses. This feature has been largely implemented in Github and will be coming online in January 2016. What are Snapshots?Snapshots freeze a specific state of your spectrum so that the data as it exists at that moment can be used in other contexts, for example by other users. It's like version control for your data -- if you use a spectrum by reference, such as to calibrate, or in a comparison, you can expect that you'll see the snapshot of that spectrum just as it was when you made that reference (see References vs. Snapshots below). No later changes to the spectrum will affect referring work. Snapshots are listed with a small "thumbtack" icon next to the operation that generated them (see below). They look like this, and you can hover over them for more info: When are they created?Most Operations applied to spectra cause snapshots to be created automatically, so that a "frozen" version of the spectrum is permanently available for that operation's use. These include the Who can create them?Since only the owner of a spectrum (or an admin) can add operations, the same is therefore true of their corresponding snapshots. References vs. SnapshotsWe refer to snapshots in two contexts, which should not be confused. Basic snapshots are those generated by an operation. References are the snapshots which operations refer to, and appear in the operation name after a hash mark - subtract:24#151 Here, the Locking and forkingYou'll see a "padlock" symbol next to some snapshots, preventing you from deleting them. Basic locking is just ensuring that if you delete snapshots, you do it in reverse chronological order. These lock icons will appear dark grey. The other kind of locking displays a blue padlock icon. As mentioned just above, referencing a snapshot will lock it -- and any registered user can reference a snapshot. The idea is that once someone -- you or anyone else -- begins to rely on a given spectrum, that version of the spectrum (as captured in the snapshot) should be permanent and uneditable. You can rest easy that nobody can change a snapshot that you've relied upon in your own work. If you or someone else has caused one of your snapshots to be locked, but you really must do something different with that spectrum, you can fork the spectrum. This makes a copy of the spectrum, all its tags, and all its operations, none of which will then have a lock. You can then delete the operations and do what you like with the spectrum. Why are they necessary?Snapshots ensure that if you rely on a spectrum for any of the operations above, any subsequent changes to that spectrum do not (by default) affect your reference to that spectrum. Your reference is to the snapshot, not the spectrum, and nobody can modify that data unless all references to that snapshot are deleted. So if you use one spectrum over and over, for example as a calibration reference, or as a baseline to subtract with, you'll always be accessing the same data. If you change the referred-to spectrum later, you'll be able to manually update the reference to a more up-to-date snapshot. But this won't happen automatically. Changing reference snapshotsYou can update the reference in an operation only if that operation's snapshot is not itself referenced (if it is, you'll see a blue lock icon and won't be able to delete it). That way, you can re-assign the referenced snapshot, but not if it'll affect any referencing operations. In terms of permissions, this works similarly to deleting snapshots. The menu looks like this: ContributingThe framework is designed to be flexible and extensible, as we add more abilities to Spectral Workbench. Please contact the developers list with ideas and suggestions for new features and future versions, and check out Spectral Workbench on Github at https://github.com/publiclab/spectral-workbench. Also check out our Contributing to Public Lab Software page. |
Revert | |
3 | larsonreever |
January 30, 2017 14:57
| almost 8 years ago
The new "Snapshots" system in Spectral Workbench brings the ability to maintain different versions of a spectrum for different uses. This feature has been largely implemented in Github and will be coming online in January 2016. What are Snapshots?Snapshots freeze a specific state of your spectrum so that the data as it exists at that moment can be used in other contexts, for example by other users. It's like version control for your data -- if you use a spectrum by reference, such as to calibrate, or in a comparison, you can expect that you'll see the snapshot of that spectrum just as it was when you made that reference (see References vs. Snapshots below). No later changes to the spectrum will affect referring work. Snapshots are listed with a small "thumbtack" icon next to the operation that generated them (see below). They look like this, and you can hover over them for more info: When are they created?Most Operations applied to spectra cause snapshots to be created automatically, so that a "frozen" version of the spectrum is permanently available for that operation's use. These include the Who can create them?Since only the owner of a spectrum (or an admin) can add operations, the same is therefore true of their corresponding snapshots. References vs. SnapshotsWe refer to snapshots in two contexts, which should not be confused. Basic snapshots are those generated by an operation. References are the snapshots which operations refer to, and appear in the operation name after a hash mark - subtract:24#151 Here, the Locking and forkingYou'll see a "padlock" symbol next to some snapshots, preventing you from deleting them. Basic locking is just ensuring that if you delete snapshots, you do it in reverse chronological order. These lock icons will appear dark grey. The other kind of locking displays a blue padlock icon. As mentioned just above, referencing a snapshot will lock it -- and any registered user can reference a snapshot. The idea is that once someone -- you or anyone else -- begins to rely on a given spectrum, that version of the spectrum (as captured in the snapshot) should be permanent and uneditable. You can rest easy that nobody can change a snapshot that you've relied upon in your own work. If you or someone else has caused one of your snapshots to be locked, but you really must do something different with that spectrum, you can fork the spectrum. This makes a copy of the spectrum, all its tags, and all its operations, none of which will then have a lock. You can then delete the operations and do what you like with the spectrum. Why are they necessary?Snapshots ensure that if you rely on a spectrum for any of the operations above, any subsequent changes to that spectrum do not (by default) affect your reference to that spectrum. Your reference is to the snapshot, not the spectrum, and nobody can modify that data unless all references to that snapshot are deleted. So if you use one spectrum over and over, for example as a calibration reference, or as a baseline to subtract with, you'll always be accessing the same data. If you change the referred-to spectrum later, you'll be able to manually update the reference to a more up-to-date snapshot. But this won't happen automatically. Changing reference snapshotsYou can update the reference in an operation only if that operation's snapshot is not itself referenced (if it is, you'll see a blue lock icon and won't be able to delete it). That way, you can re-assign the referenced snapshot, but not if it'll affect any referencing operations. In terms of permissions, this works similarly to deleting snapshots. The menu looks like this: |
Revert | |
2 | warren |
January 11, 2016 22:28
| almost 9 years ago
The new "Snapshots" system in Spectral Workbench brings the ability to maintain different versions of a spectrum for different uses. This feature has been largely implemented in Github and will be coming online in January 2016. What are Snapshots?Snapshots freeze a specific state of your spectrum so that the data as it exists at that moment can be used in other contexts, for example by other users. It's like version control for your data -- if you use a spectrum by reference, such as to calibrate, or in a comparison, you can expect that you'll see the snapshot of that spectrum just as it was when you made that reference (see References vs. Snapshots below). No later changes to the spectrum will affect referring work. Snapshots are listed with a small "thumbtack" icon next to the operation that generated them (see below). They look like this, and you can hover over them for more info: When are they created?Most Operations applied to spectra cause snapshots to be created automatically, so that a "frozen" version of the spectrum is permanently available for that operation's use. These include the Who can create them?Since only the owner of a spectrum (or an admin) can add operations, the same is therefore true of their corresponding snapshots. References vs. SnapshotsWe refer to snapshots in two contexts, which should not be confused. Basic snapshots are those generated by an operation. References are the snapshots which operations refer to, and appear in the operation name after a hash mark - subtract:24#151 Here, the Locking and forkingYou'll see a "padlock" symbol next to some snapshots, preventing you from deleting them. Basic locking is just ensuring that if you delete snapshots, you do it in reverse chronological order. These lock icons will appear dark grey. The other kind of locking displays a blue padlock icon. As mentioned just above, referencing a snapshot will lock it -- and any registered user can reference a snapshot. The idea is that once someone -- you or anyone else -- begins to rely on a given spectrum, that version of the spectrum (as captured in the snapshot) should be permanent and uneditable. You can rest easy that nobody can change a snapshot that you've relied upon in your own work. If you or someone else has caused one of your snapshots to be locked, but you really must do something different with that spectrum, you can fork the spectrum. This makes a copy of the spectrum, all its tags, and all its operations, none of which will then have a lock. You can then delete the operations and do what you like with the spectrum. Why are they necessary?Snapshots ensure that if you rely on a spectrum for any of the operations above, any subsequent changes to that spectrum do not (by default) affect your reference to that spectrum. Your reference is to the snapshot, not the spectrum, and nobody can modify that data unless all references to that snapshot are deleted. So if you use one spectrum over and over, for example as a calibration reference, or as a baseline to subtract with, you'll always be accessing the same data. If you change the referred-to spectrum later, you'll be able to manually update the reference to a more up-to-date snapshot. But this won't happen automatically. Changing reference snapshotsYou can update the reference in an operation only if that operation's snapshot is not itself referenced (if it is, you'll see a blue lock icon and won't be able to delete it). That way, you can re-assign the referenced snapshot, but not if it'll affect any referencing operations. In terms of permissions, this works similarly to deleting snapshots. The menu looks like this: |
Revert | |
1 | warren |
January 07, 2016 20:01
| almost 9 years ago
The new "Snapshots" system in Spectral Workbench brings the ability to maintain different versions of a spectrum for different uses. This feature has been largely implemented in Github and will be coming online in January 2016. What are Snapshots?Snapshots freeze a specific state of your spectrum so that the data as it exists at that moment can be used in other contexts, for example by other users. It's like version control for your data -- if you use a spectrum by reference, such as to calibrate, or in a comparison, you can expect that you'll see the snapshot of that spectrum just as it was when you made that reference (see References vs. Snapshots below). No later changes to the spectrum will affect referring work. When are they created?Most Operations applied to spectra cause snapshots to be created automatically, so that a "frozen" version of the spectrum is permanently available for that operation's use. These include the References vs. SnapshotsWe refer to snapshots in two contexts, which should not be confused. Basic snapshots are those generated by an operation. References are the snapshots which operations refer to, and appear in the operation name after a hash mark - subtract:24#151 Here, the Locking and forkingYou'll see a "padlock" symbol next to some snapshots, preventing you from deleting them. Basic locking is just ensuring that if you delete snapshots, you do it in reverse chronological order. These lock icons will appear dark grey. The other kind of locking displays a blue padlock icon. As mentioned just above, referencing a snapshot will lock it -- and any registered user can reference a snapshot. The idea is that once someone -- you or anyone else -- begins to rely on a given spectrum, that version of the spectrum (as captured in the snapshot) should be permanent and uneditable. You can rest easy that nobody can change a snapshot that you've relied upon in your own work. If you or someone else has caused one of your snapshots to be locked, but you really must do something different with that spectrum, you can fork the spectrum. This makes a copy of the spectrum, all its tags, and all its operations, none of which will then have a lock. You can then delete the operations and do what you like with the spectrum. Why are they necessary?Snapshots ensure that if you rely on a spectrum for any of the operations above, any subsequent changes to that spectrum do not (by default) affect your reference to that spectrum. Your reference is to the snapshot, not the spectrum, and nobody can modify that data unless all references to that snapshot are deleted. So if you use one spectrum over and over, for example as a calibration reference, or as a baseline to subtract with, you'll always be accessing the same data. If you change the referred-to spectrum later, you'll be able to manually update the reference to a more up-to-date snapshot. But this won't happen automatically. Changing reference snapshotsYou can update the reference in an operation only if that operation's snapshot is not itself referenced (if it is, you'll see a blue lock icon and won't be able to delete it). That way, you can re-assign the referenced snapshot, but not if it'll affect any referencing operations. In terms of permissions, this works similarly to deleting snapshots. The menu looks like this: |
Revert | |
0 | warren |
December 03, 2015 21:11
| almost 9 years ago
The new "Snapshots" system in Spectral Workbench brings the ability to maintain different versions of a spectrum for different uses. This feature is being planned in Github and will be coming online by January 2016. What are Snapshots?Snapshots freeze a specific state of your spectrum so that the data at that moment can be used in other contexts. It's like version control for your data -- if you use a spectrum by reference, such as to calibrate or in a comparison, you can expect that you'll see the snapshot of that spectrum just as it was when you made that reference. No later changes to the spectrum will affect referring work. When are they created?Certain operations cause snapshots to be created automatically, so that a "frozen" version of the spectrum is permanently available for that operation's use. These include:
We hope to make the flip operation also trigger snapshotting; progress can be seen here. Why are they necessary?Snapshots ensure that if you rely on a spectrum for any of the operations above, any subsequent changes to that spectrum do not (by default) affect your reference to that spectrum. Your reference is to the snapshot, not the spectrum, and nobody besides you can modify that data. So if you use one spectrum over and over, for example as a calibration reference, or as a baseline to subtract with, you'll always be accessing the same data. If you change the referred-to spectrum later, you'll be able to manually update the reference to a more up-to-date snapshot. But this won't happen automatically. |
Revert |