Hi,
There have been a few posts which relate to this feature request.
viewtopic.php?t=409
Also,
viewtopic.php?f=14&t=135&hilit=bundle+center+lat
The bundle must retain information about the data within it, the saved window size, id's set in the layer control, etc. Is there/could there be a way to interrogate this from a script?
Joleen
interrogating bundle
Re: interrogating bundle
This is a good idea, and it would be really handy for debugging stuff too. Though I keep thinking of edge cases that could complicate things…
To actually answer your question (d'oh), there's currently no way to do it aside from writing some XML parsing code to extract the relevant info from the bundled XML (and handle zipped bundles too).
To actually answer your question (d'oh), there's currently no way to do it aside from writing some XML parsing code to extract the relevant info from the bundled XML (and handle zipped bundles too).
Re: interrogating bundle
Jon,
I wonder if an inquiry should be added to this topic. It seems there are a few ways which it might be useful. One use would be to interrogate the bundle in a script, which is helpful to know what you have or do a quick check before loading. This capability could also be used to add a bundle properties feature which could describe the bundle size, data contained or needed, etc. This would be seen before opening the bundle for loading. This would be extremely useful for bundles which rely on data in a certain location. It could save time and headache if you know that the bundle will not load because a certain piece of data has been moved. In fact, it would be useful to reassign data paths if they change.
Joleen
I wonder if an inquiry should be added to this topic. It seems there are a few ways which it might be useful. One use would be to interrogate the bundle in a script, which is helpful to know what you have or do a quick check before loading. This capability could also be used to add a bundle properties feature which could describe the bundle size, data contained or needed, etc. This would be seen before opening the bundle for loading. This would be extremely useful for bundles which rely on data in a certain location. It could save time and headache if you know that the bundle will not load because a certain piece of data has been moved. In fact, it would be useful to reassign data paths if they change.
Joleen
Re: interrogating bundle
I agree with all the 3 postings above.
Me and Joleen where just talking about it this morning.
Me and Joleen where just talking about it this morning.
Re: interrogating bundle
Hi Joleen,
I have added and inquiry to address your needs.
http://mcidas.ssec.wisc.edu/inquiry-v/?inquiry=1158
I have added and inquiry to address your needs.
http://mcidas.ssec.wisc.edu/inquiry-v/?inquiry=1158
Re: interrogating bundle
Thanks Rick, I think this could become a very useful feature. Someone was just commenting to me that they sometimes receive bundles where the screen size was set so big, that using "Replace Session" can be a bad idea on smaller screens. If the saved size is known before opening, any user can make the decisions needed to display the bundle on their machine.
Joleen
Joleen
Re: interrogating bundle
I spoke with Tom W. and Tom R. They explained how complicated it would be to parse the xml and get the information I am requesting. A reasonable solution might be to add a comment box when saving a bundle. The comment which the user enters would then be added as a comment string in the xml. Kaba and I have discussed that one useful piece of information to have in the bundle is the window size(s) in the bundle. Perhaps some useful practices are
1.) When loading a bundle from a script, always use a specific size when loading the bundle. This might be a way to keep image sizes consistent when running multiple times.
2.) When working in the interactive session, try to take advantage of full screen mode and set a preferred size so that is what gets saved to the bundle.
Also, if there could be a comment section added to the bundle when saved, it may allow the user to add other information to help them to remember what was in the bundle.
Comment: 10.7 micron image centered at 14.3 -71.6, full resolution. Full screen size of 500x500. 5 windows saved in bundle. One window is super-duper large and should not be opened as replace session or create new windows for most monitors.
One disadvantage of relying on a window size from the mode which is not full screen size, is that the legend width can vary, thus changing the area for the display.
Joleen
1.) When loading a bundle from a script, always use a specific size when loading the bundle. This might be a way to keep image sizes consistent when running multiple times.
2.) When working in the interactive session, try to take advantage of full screen mode and set a preferred size so that is what gets saved to the bundle.
Also, if there could be a comment section added to the bundle when saved, it may allow the user to add other information to help them to remember what was in the bundle.
Comment: 10.7 micron image centered at 14.3 -71.6, full resolution. Full screen size of 500x500. 5 windows saved in bundle. One window is super-duper large and should not be opened as replace session or create new windows for most monitors.
One disadvantage of relying on a window size from the mode which is not full screen size, is that the legend width can vary, thus changing the area for the display.
Joleen