Attention! This page is marked as deprecated, use it as reference only if you are sure you need these specific information.
Establish the specifications of a profiles viewer
We can continue individual development, but look for ways to collaborate and leverage resources. When we can collaborate, we should attempt to create clear, attainable goals with timelines. In general, we should select a platform(s) that both allows us to use our current in-house resources and collaborate with other groups. We should attempt to use open-source packages so that many groups can use the results and so that we can continue to use them as our employment status changes.
Here are the tasks that we should accomplish:
- Create an online resource for exchanging ideas, code, and tracking projects
- ensure SNOWPACK and observational datasets are available in the IACS-CAAML format
- profile viewer - software that can visualize CAAML profiles and is suitable for desktop and web applications. This software should be easy to modify so that it can grow with changing requirements.
- standard output that includes both numerical element and aggregated levels/layers exists in the version of the model version to be used
- software that can display many elements of model output including the temporal development of successive model simulations. This software should be easy to modify so that it can grow with changing requirements.
- Plots interactions
- Zoom in to certain layers to track their parameters
- Visualize the temporal development of modelled profiles or specific layers
- Create easy to interpret profiles for practitioners of single time steps (in a similar look-and-feel as SnowPro, option for 0 HS at the surface)
Requirements and specifications
This is the description of the basic architecture of the snow profile visualization (SnopViz)
The goal is to design a snow profile visualization (and latter, snow profile manipulation) tool that could be reused as much as possible. In order to do so, this would be implemented as a Java library.
This library would run both on a server to generate plots (and more) for the operational systems (on demand or at regular intervals) and be used to power a client application for research use. Later, some tools manipulating the profiles (extracting some parameters time series, aggregating profiles, etc) could also be implemented that would rely on this library.
At the core of the library, there would be the necessary structures to store snow profiles (centered around the concept of a snow profile at a specific date and time), to read and write them and to generate a graphical representation and save it to disk. The read/write routines would be implemented as plugins (without the dynamic loading), that is as an abstract class defining the interface and classes implementing it for various formats/protocols. The graphical representations would be implemented as widgets for the different possible views that could be integrated in a fat client or dumped to an image file.
The required plots are the following:
- an X/Y plot, with potentially swapped Y axis (ie on the right), for showing a temperature profile
- a bar plot with the Y axis on the right and the X axis going right to left, for showing a density profile
- a profile plot with the snow classification symbols (and annotations)
- a colored surface plot, showing the time evolution of a profile with colors used for the 3D dimension, for showing a temperature distribution in a time-resolved profile
The first priority would be to provide a replacement for the current plot generator used on the operational systems. This would therefore require the following (on top of the basic architecture):
- the ability to read CAAML profiles
- the above defined plots
- the ability to write a plot as PNG image (color indexed, high compression)
The second priorities would be to bring more flexibility in integrating in the operational systems:
- the ability to write CAAML profiles
- the ability to read from the IMIS database
- the ability to read .pro profiles
long term goals
Once the core features would be implemented (reading/plotting/writing), other modules would be implemented in order to provide some degree of interactivity to the web interface as well as build the fat client application. This application should aim at replacing all the current features of sngui. Finally, some profiles manipulation features would be implemented (aggregation, data extraction, etc).
The goal would be to keep each application relying on this library as simple as possible, that is to say to implement most of the features in the library itself, so it could be shared by the other interfaces/applications.