I would like to solicit feedback on this topic. I have a few designs in my head and have not fully decided yet the best model.
WSV3 2025 must offer full flexibility with offering a programmable timeline state so that the eventual broadcast version has logic for saving and reproducing loop animation state in the real-time (past to present) and forecast model timelines.

Problem:
-Different timeseries raster weather datasets spanning past-to-present and near-present to future.
-Different timeseries datasets have different max loop length reasonable limits; National Radar obviously longer than full Level 2 max loop length; GFS forecast out 384 hours vs HRRR out 12/18
-Desire to simplify timeline state adjustment and loading of desired data
-Sometimes want to view only forecast data loop, sometimes want single-frame future forecast on map with looping past-to-present real-time data, sometimes want to view past to future seamless transition loop only showing one dataset, switching from observed to forecast (something WSV3 2025 should be able to do)
-User must have option to specify forecast start times and durations; turning on a GFS parameter doesn't automatically download 384 hours
-Going from single frame to moving, animated timeseries data should be as immediate as clicking one play button

Concepts:
-Two separate timelines with separate state. Clicking play on one loads data for set loop length. Loop length adjustable. Does not solve all problems/cases.
-One timeline with two drop-down lists for start and end times ("-6hr to current", "forecast data start to 24hr", etc)
-Settings to snap timeline past/future extents to maximum extent of data loadable
-Per-layer settings controlling number of hours of data to load separate from timeline length
-Different selectable timeline modes offering different timeline logic functionalities

Solution currently undecided; active product research and development question.

Open to ideas and discussion.

    Paul

    I'm apologizing that I'm once again recommending from the previously mentioned "SmartMet / GeoWeb" workstation, but it is only real product I have access to, so I can recommend what it really does.

    So in this workstation the timeline/time control logic is as follows (numbers releated to numbers in picture below):

    1. Timeline lenght. For example, when selecting 12h, the timeline will be 12h in lenght, but when selecting 1h, it will be 1h in lenght, so you can change how precise the control over it is.

    2. Loop lenght. On the timebar you can see this marked area (number 9), which is part, who will be animated when "Play" will be clicked. You can drag this area on timebar to select which part of you want to animate, or you can click and drag by sides to extend the animation lenght in both sides.

    3. Time step. It allows to select the time step of data. For example if you don't want to load all of radar images that are updating every 5 minutes, you can select time step of 15 or 30 minutes, so the data will load faster and will be displayed with time step 15 or 30 minutes.

    4. Animation speed is very similliar that is available right now on WSV3 V5.9. On WSV3 it is measured in ms I guess, but here it is just 1x, 2x, 4x, 8x, 16x, 32x, 64x, which probably is not the best option, but still.

    5. Toogle for auto-update. If you are monitoring live data, you can select this option, and it will automatically update to latest data and insert it into timeline.

    6. One frame back/forward or play. These controls allows to move frame-by-frame just like WSV3 already does or autoplay animation, that you have selected in 2. and 9. part.

    7. The first part to the left (colored in blue) is the observation data timeline part. In this part all of observed data goes in. For example you select radar, satellite and lightning data, and all of this goes there. For example, if radar data is available 6 hours in past, but satellite data 12 hours in past, once you move past radar data time limit, the radar image will dissapear and it will keep showing the data that is available there (satellite data in this case).

    8. Forecast data timeline part (colored in pink) is the forecast data timeline part. In this part all of the forecast data goes in. For example you can select the GFS model and ECMWF model, and both of them will be placed there. The time limit logic is the same as for observation data - once you reach the limit of ECMWF data (+240h), the ECMWF will dissapear and only GFS will keep showing for the rest of the available time limit (+384h).

    9. Animation area marker. In the step 2. you where able to select the lenght of animation, but if you don't want to do it precisely, you can just drag the animation area marker and choose manually the data you want to animate.

    10. Current timeline position. It is marker that shows - where you are at timeline right now. You can drag and move this manually the same way, it could be done in WSV3, you just manually move it to change the timeline position.

    Very long and probably unnecessary explanation, but I hope you get the logic behind it, and while it maybe is not directly applicable for your case for WSV3 2025, maybe some of the logic ideas will be helpful. 🙂

    • Paul replied to this.

        MeteoLatvia Thank you for sharing. There are some useful UI concepts I like about their approach, however, correct me if I am wrong about the following limitations:

        1. This design does not allow the same map view to have looping real-time past-to-present radar/sat/obs/etc data concurrently displayed with one static color fill frame of forecast model data at a different timestamp. It is crucial to decide whether to allow this ability, as simplifications can be made without it. I do believe this is necessary and was told it does have mesoanalytic value in early September on the original forums. I can try to find the thread.

        2. This design does not allow the user to have dual or quad panels within the same window where the map position is synchronized between frames (so, not a completely separate map with separate camera but one multi-panel map) while having diverse real-time vs forecast content across different said panels. I.e., not possible to have panel 1 with looping observed radar and panel 2 with HRRR forecast reflectivity non-looping but set to a certain time. It is also crucial to decide whether to have this ability. I do believe it is necessary and valuable, since this allows users to compare real-time observed data with what a given forecast model had predicted, in order to quantify model trends. Of course, the simpler option would be to have one timeline, not two, and force the user to make such comparisons with separate free-form map frames in the new UI, rather than having an embedded side-by-side within the same map, which then requires the extra dual-timeline logic.

        One follow-up question:

        1. The distinction between "model" and "mesoanalysis" in WSV3 V5.9 should go away as the rendering engine for both is identical: a subset of the raster engine allowing color fill, vector field, and contour rendering of GRIB2 data. "Mesoanalysis" is "real-time mesoanalysis" and "model" is "forecast mesoanalysis". My current putative design has one UI interface and rendering engine for both, with a high-level per-product selection of "real-time" vs. "forecast" to determine which timeline controls it and what data options are given. Q: How does the product you showed handle this distinction? Let's take the case of a blank map with only MSLP pressure lines. Does the software have one "MSLP" parameter that can be looped from past through present to future, or does it provide an interface for discriminating the analysis/observed MSLP from future model MSLP? And if the latter, does it provide control over whether the switchover point is based on current time or model start time? The current time on your watch is always newer than the start time of available operational models. This is why the 1hr HRRR for instance is often used for real-time analysis. I view it as a requirement that the user have total control and ability to view the 0hr and 1hr, etc. frames of the current model run, even if likely in the past, and to be able to compare this to RTMA analysis or observed data.

            Paul

            Happy to hear it. 🙂

            In this case, when you switch to multi-panel view (unfortunately I don't have screenshot of this program state, I will try to ask my friend, maybe he has shift at weather office now and can share it) the timeline control appears under each panel separately. For example - if you select 2x2 panel mode with radar, satellite, METAR and ECMWF data, you can individually select the parameters I mentioned in previous post. For example, you can select, that radar data loops from -6h to present (for example: 3:30 PM - 9:30 PM), then you can select, that the satellite data loops -3h to present (for example 6:30 PM - 9:30 PM), METAR data then maybe will loop only -2h to present (7:30 PM - 9:30 PM) and finally - ECMWF model loops from 0h to +240h. With this I wanted to say - you can select that each panel timeline is fully customised to its own data product displayed and is not connected/syncronized to other pannels. You can actually syncronize it, but then it will glitch out, for example, when radar, satellite and METAR data loops for past 6h, the ECMWF will stay at 0h and once this position is reached, then ECMWF will start playing till +240h. Very complicated, but I hope you got the point.

            How does the product you showed handle this distinction?

            Well there is 2 parameters METAR (MSLP) and ECMWF (MSLP) in that software. If you select both, then it would automatically place the METAR (MSLP) observation data with contours plotted in the timeline observation part and the model data with MSLP contours into forecast timeline part. When you animate, it will go from the earliest METAR (MSLP) observation time you selected (for example -24h) till the present and then just switch to ECMWF model MSLP contours.

            The point where the data switches from the observation data (METAR) to ECMWF model data is determined in 2 ways - user can select the current PC time or the latest observation time. When PC time is selected, all of observation data that is past the current PC time will not show anymore and it will switch to model data, and when latest observation time is selected, it will display all data till the latest available time, and then switch to model data.

            This seems very complicated, and generally it really is, because the system was developed in 2010, and is ment for operational meteorologists at weather office, where the graphics or user interface is not in the main role, so my ideas in this case may just be not useful, but I just wanted to share at least something.

              Good Morning once again Paul. I am reading through your initial post above, please note that I am still racking my brain around the full span of your "Problems" section, however I will try to explain a solution based on how I use the current version of WSV3.

              When using the timeline section here are items that I would find beneficial to improve:

              • Timeline wrapping: In the current version of WSV3, if my timeline readout is set to (hh:mm:ss) then all data, such as watch/warn box times, report relay times (NWS sources, USGS Earthquakes, etc) and the main on-screen timelines will readout the timeline to the corresponding format above. The software does not appear to allow for variable timeline formats. This would come in handy... How so?
                Ex: Main timeline, (upper third) could be set to (hh:mm) while on the info box readout for on-screen datasets (USGS earthquake reports) could be formatted to (ddd:hh:mm:ss) while the readout for watch/warning info box time could be (hh:mm)

              Also: In the future it would be nice to wrap the main on-screen timeline (which would go on an upper third) to specific datasets. Let's suppose I display radar currently... My timeline readout for this could be (hh:mm) but if I switch to the USGS earthquake data, my banner timeline format switches to (hh:mm:ddd) Maybe I want to display the NWS hazards dataset. I can format the timeline to switch to a custom text which would read ('RIGHT NOW") Please note that if this option were pursued, text size and timeline location is crucial here, and it would be nice to see this implemented as a variable also...

              Second, the AM/PM readouts on the main timeline, are tied or wrapped with the current (hh:mm:ss) variable, which makes the AM/PM readout not stay in place with the banner. I would love to see this as a variable option to allow users to move the AM/PM elsewhere on the screen or to wrap it with the (hh:mm:ss) portion of the timeline as it currently functions.

              • Timeframe/Timeseries Differences for datasets:
                Another note you bring up is that different datasets do not span to the same maximum timeframe (6hr, vs. 12hr.) If I understand your logic correctly, a combination of the two concepts I quoted below would help. I could see this being handy if implemented in a menu, please let me know your thoughts on this.

              Quote: (Paul)
              "-Per-layer settings controlling number of hours of data to load separate from timeline length
              -Different selectable timeline modes offering different timeline logic functionalities"

              Additionally: I would find it useful to have more independent control over datasets playback speed and dwell time.
              Ex: Lets say I display meso data, in my options I can speed up the playback to 4 seconds total loop time on 500mb Winds but slow down the total loop time of the Surface Visibility data to 10 seconds. Maybe I want Satellite data to loop for a time of 10 seconds while surface temperature fill data loops for 5. There is variability for control here.

              I hope this helps, I need to read over this more to fully understand the entire goal here, however that's all I've got on this for now.

              Kind Regards,
              Kody

              Thank you both for your feedback. I have reviewed it and will return for more commentary later.

              10 days later

              Kody: We will have a separate graphical engine, named "HUD" or "map text" or "map UI" or something, with full customizability over things like timestamp display formatting. That is a given and not dependent on the logic for overall timeline functionality. There still remains some question about the difference, if any, between a "map interaction" system (like current severe warning polygon click info boxes, rollovers on point observations, etc) and the "HUD"/"map text" system. They could be related.

              Here I summarize the current development intentions regarding the broader issues of timeline logic and raster timeseries product selection.

              1. In keeping with the overall design requirement for robust, tactical mesoanalysis, the rendering engine and data layouts must absolutely be determined in a performance-optimal way dictated by realities of the hardware and not dictated by the high-level world modeling concepts we like to think of as humans. This is a fundamental tenet of "Data Oriented Design", the philosophy which challenges OOP and which distinctively characterizes the design of WSV3 Tactical 2025 in every corner.

              2. The underlying concept is 2D timeseries raster data. This is agnostic to the high-level human perceptive difference between real-time loops (past to present) and forecast model data (starting at an hour near present, but likely a few hours before).

              3. The software must deliver absolute power to the user to maximize permutations offered within the intended multi-channel multi-panel and multi-map flexible data rendering engine. The user interface convenience is secondary, because the high-level "saved maps" or "workspaces" system (or whatever that becomes named) covers the complexity of initial configurations.

              4. The user should be able to combine real-time and forecast datasets without restriction, except the existence of two separate timelines maintains data correctness and independent control of real-time vs forecast timeseries loading and playing.

              5. If real-time raster parameters are playing (past to present), any forecast raster parameters in that same panel will be paused at the draggable timestamp in the timeline controls.

              6. The sidebar that offers timeline controls will have a "real-time" vs "forecast" drop-down to expose the different timelines, similar to V5.9. This UI area also enables changing the duration of either.

              7. All loaded parameters, forecast or real-time, automatically load within the set timeline duration. If the user sets the forecast timeline to 384 hours but loads HRRR forecast fields, the map will go blank during forecast loop playing at the correct time. An additional abstraction could offer the option of trimming the forecast loop to the maximum of loaded raster forecast parameters.

              8. The user should be able to have looping forecast data in a separate panel within the same map which contains looping real-time past-to-present data in another panel. The two panels have respective timestamps. In other words, two panels within the same map can be intertemporal, with automatically fixed camera view and synchronized point probe functionality. This is the essence and benefit of the multi-panel-within-map (1, 2, or 4) beyond the separate and totally flexible maps themselves, of which there will be a limit of likely 4 or 8 in the broadcast version, and definitely at least 2 in the primary WSV3 2025 Tactical Standard tier. Different maps have unique camera views; panels within maps do not, but contain diverse parameters and/or timeline states.

              9. The design must preserve the representative correctness of data by applying two timestamp labels in the case fixed frame forecast parameter is included within the same panel as real-time data, but should not deprive the user of the mesoanalytic value of comparing a moving real-time raster parameter to a similar parameter belonging to a forecast model. E.g., the design must preserve the value of allowing a current reflectivity loop up to time T to be compared with a model reflectivity simulation for the same time. This allows mesoanalysts to assess model accuracy vs real-time observations on the fly.

              10. Additional levels of abstraction/optional modes should be thought-of to support this special comparative purpose, such as perhaps a mode which constrains the loop timeline to start at the given run zero model hour (e.g., some short time in the past) and to end at the current time, to narrow-in temporally on the overlap portion between the past-generated forecast and the real-time conditions so far observed. This is valuable for nowcasting and tracking model tendencies.

                19 days later

                Hello again Paul, sorry for such a late reply. I do apologize. I have read over your reply to my last post, and I understand a bit more of your goal and vision for the new 2025 product.

                I especially agree with point number seven where you state "An additional abstraction could offer the option of trimming the forecast loop to the maximum of loaded raster forecast parameters." as this is a very logical feature in my opinion. I appreciate your focus on the software's performance and user interface rather than just the look of the software.

                I'll stay tuned for any updates you have!
                Kind Regards,
                Kody

                • Paul replied to this.

                  K-McPheron Thanks; here's a recent further-streamlined thought I have about this. There can be one unified list that contains preset items for real-time vs loop selection and for duration/length. So, "Real-time (1 hour)", "Real-time (3 hour)", "Forecast ..." (3, 6, 12, 18, 24, 48, 96, etc), instead of clutter with separate controls for timeline selection plus duration.

                  If there is a true need to have an exact odd time, such as a 49 hour forecast instead of a 48, then a separate menu/screen can allow the user to customize the combinations and order in the main drop down.

                  This discretization of the time options has a few benefits. It requires the user to consciously select a timeframe and allows me to optimize content for certain presets rather than variable ranges. For instance, certainly in the broadcast/industrial version but perhaps also in the standard subscription, it may be possible to allow more than 6 hours. If I had two discrete "12" and "6" hour selections, I can foreordain temporal resolution scales for all products at that duration. A tapered scheme could dynamically transition, say, National Radar frames, from every 6 mins for the last 60 minutes, to every 12mins for the T-1 to T-2 hrs, etc. From 6 to 12, even if the temporal resolution was downscaled to one full hour frames, at least that offers more useful info at the same bandwidth/memory cost as higher temporal resolutions at shorter lengths.

                  Here is a screenshot of the tool bar menu where the timeline mode + duration selector could be. Enjoy also the progress shot on the multi-maps rendering infrastructure, now having attained the level of being able to render the terrain with multiple camera views simultaneously.

                      Paul I think this is going to be extremely helpful and I believe the way you have described going about it to be the most logical too. This overhaul is worth waiting for in my opinion as I know you are really taking WSV3 to a next level and putting everything you have into it. The screenshots you sent prove this is hands down going to beat the competitors! Keep up your hard work Paul!

                      Kind Regards,
                      Kody

                        Paul - great work and awesome to see some new leaks. Are you considering implementing soundings into the software, similar to how RadarScope implemented that, perhaps a new add-on payment feature?

                          OptimallyAxel Nothing is off the table. I would love to examine soundings. Like the surface point observations, this is something I haven't fully examined yet to plan out the corresponding system. The generic system for typical 2D raster datasets (whether radar, satellite, or model) is the first to design in terms of data, and I'm still likely months away from even starting that, as currently the base mapping and graphics engine is the priority. But it's not too early at all to send me ideas or requests if you want to make a new thread about what the integration of sounding data in an optimal next-generation weather analysis graphics product would look like.

                            a month later

                            Paul Point 7: An alternative to the map going blank is the ability to load a frame from another model starting from the point where the first model ends. In your HRRR example, you could have HRRR and GFS within the same loop. HRRR from hours 1-48 and GFS from 51-384. Even if not for the consumer version, I think this could be useful for the broadcast version as I've seen some stations transition from a high res model to a lower res model but they always use a new scene. This could be something unique to WSV3

                                NinjaShuriken Your post introduces the concept of blending/compositing together multiple distinct datasets of the same parameter into different positions on the time axis. This is an excellent concept, and one I have been thinking about in addition to the similar and extended concept of compositing the same parameter from different datasets at the same time, varying by spatial extent, such as the HRRR/GFS you noted. One area I'm already certain that can and will be helpful is with precip-typing: a the server should process global seamless p-type fields, low-res version based on GFS, with high-res HRRR-based superimposed. I did a proof of concept of this in August. This uses special GPU methods, to which we have unique access, to render both into offscreen surfaces and use the final p-type field as an input to the drawing of any reflectivity data of any projection - very useful.

                                A mode which keeps GFS as a fallback for distant times and higher-res short-term models like HRRR for shorter loops could be abstracted into the selection of two concurrent models at the same time and a common parameter between the two. This might limit parameter selections when two models aren't fully orthogonal in GRIB2 outputs, but this could be a separate mode from the single-model viewer.

                                This is also similar to my groundbreaking concept from early November I have unofficially termed "WSV3 NXUltra Polyradial Reflectivity Mosaic", a real-time CONUS radar display idea I will post about soon.

                                  The notion of a generic "two models at once" by common parameter has other powerful extensions by introducing the notion of a "synthesis mode" or "composition mode".

                                  I want there to be options like:
                                  -Overlay (same as you noted - HRRR over GFS when extant)
                                  -Maximum (displays max value from the two models at a given point)
                                  -Minimum (same)
                                  -Difference/subtract (uses separate color palette, possibly screen-maxima-adaptive, to show + and - delta comparison regions - explanation below)

                                  I have always known since the inception of WSV3 Tactical 2025 that advanced tools for comparison between datasets should be included, making use of the incredibly powerful rasterization hardware found in modern GPUs for such things.

                                  One common case is the desire to compare trends from previous runs.

                                  The same "dual-model" display option, which in "overlay" mode could take "HRRR" and "GFS", overlaying both, providing a seamless global forecast that appears to have higher resolution for the first 18 hours over CONUS (HRRR grid), could offer the option to compare the same models at different runs, e.g., "HRRR (1Z)" vs "HRRR (2Z)", with the "difference" mode.

                                  The same dual-concurrent-model feature could provide all this functionality with a simple design putting full control in the hands of the user.

                                  This seems like an incredibly cool idea, Paul, and I think it would most assuredly set WSV3 apart.

                                  I'm also intrigued by this "WSV3 NXUltra Polyradial Reflectivity Mosaic" idea. If it's what I think it is (probably not), that could be incredible.