hillcountrywx Excellent, thank you for sharing. #1, 2, 3 virtually guaranteed (see V6P prototype on first-gen download page for functional demo of live-updating probe functionality). The only likely hard-no in your list is KMZ/KML. I want any worthwhile data, like Texas A&M Forest Service Fire Danger, to be available to you inside WSV3 natively with optimal transmission, speed, and rendering performance. I am building a highly versatile ingest system so I can add novel datasets with great speed and facility as native, optimized, embedded offerings. Also the whole switch to VM-permissive use-anywhere cross-device means zero custom user data can be imported, so it actually has to be this way. Importing custom private data is the broadcast/industrial side, not tactical/in-field. We are finally logically separating the two thankfully. The tactical product is the opposite of allowing custom data import (other than vector shapefile and map customization) - WSV3 Tactical is a streaming client/server data service where bandwidth and power use optimization is key. We are losing money due to the frustrating VM nonsense and we need to embrace a philosophy where you run it wherever you want, just one copy at a time (or N quantity) - in-house floating licensing possibly with settings synch.
I am a militant software optimization/Data Oriented Design absolutist with WSV3 Tactical and cannot soil my honor by parsing XML in the client application anyways 🙂
But for a separate/associated/broadcast product where there is a premise to import your own data, then what you would do is give your web account the KML, and the new engine would ingest the data and transmit to client with the "special sauce" high-efficiency geospatial raster/vector rendering. KML itself is extremely inefficient and unfocused. You will see the absolutist philosophy of the new product is very refreshing: we reduce all import to core raster, vector line, point, and polygon elements, using the proprietary ultra-efficient/compressed progressive loading and client-server streaming.
So the server is what you will be paying for to do the heavy lifting of ingesting inefficient, traditional formats (like KML for vector or even GRIB2 for raster) and 24/7 compressing/processing them into the special optimized content streaming system with dynamic resolution.
Nota bene: I understand the expectation to import shapefile lines. I do intend for this to be an exception. Also because shapefile format is a good, clean, small binary format with an 50kb open source C library - that is acceptable. So the philosophy of the next-gen WSV3 must insist that in such cases the user would convert their KML or whatever to the optimized, simple, straightforward format that is acceptable for the tactical-grade usage context (storm chasing on laptop battery and cellular WiFi).
After the tactical product there is intended a studio/broadcast version where custom data import is more of a thing.
On #5, understood loud and clear. This is a huge area for me to spend even years working on (forecast data). Like the original WSV3, I will release with at least a small selection of forecast parameters, but the core focus is real-time in-field situational awareness/nowcasting. I.e., release emphasis on the new radar/satellite (raster), mapping engine/customization, volume rendering, and graphics/ultra-optimized software architecture, and de-emphasis on model data - just at first, only for release. I am excited that now we have free public GRIB2 ECMWF data. I will strongly attempt to include at least one product therefrom for release.
I do however anticipate I might get pressed for time around September - I am going to focus on the few new "special sauce" items (like WSV3 RadarHalo Polyradial mosaic) before release, even leaving intentional omissions to first-gen if need be. Because it's clear the more basic stuff will be coming, so I want to maximize the attention span/release spotlight on the new, unique stuff. I will be working likely just as hard in 2026 as in 2025.
#6 is confirmed (it's basically the single most defining aspect of WSV3 Tactical) and is actually up to eight/8x multi-map display as I have already previewed in some other threads here. It will be more than just multi-map - I intend to have the ability to have completely independent camera views as well as unique data products, unique timeline states, and unique map styles. There will also be immediate realtime switching between 2D and 3D for individual maps, so you can have some 2D and some 3D.
Interactive color palette editor (#9) also confirmed and not only this, I released almost two years ago now a working demo in V6P which you can download and test right now if you have a first-gen license. Also - the updates will apply to actual on-map raster layers like radar in real-time, at 120fps, as you edit the color palette.
I am personally very excited for #13 (to have the MADIS mesonet observations), but it's 150k obs per hour and will require a lot of work and processing - probably not going to be inside the base price for Mesoanalyst, which I am striving to keep as low as possible ($25/month for first-gen has been since 2018 after years of improvements and inflation - the base level really can't be more than $30/month or else I have to cut content to make it cheaper, also because the industry gets more competitive and people expect more at the same price compared to 10 years ago, very reasonably so).
Also on the new observations system, I strongly desire to implement realtime client-side GPU compute shader generated interpolated fields/objective analysis from sparse point observations with inverse distance weighting. This will be very unique.
#10 gets into custom graphics authoring - I need to charge more for this because the tactical product is distinguished from broadcast and should be discounted to exclude graphics authoring functionality. I think the best is to have a separate "WSV3 Graphics Producer" product in 2026 that requires a separate Tactical Mesoanalyst license but is about the same price. The separation is desirable because the reputation of the product needs to be scientific - optimized geospatial dataset rendering for bandwidth and power constrained contexts. To this subset of users, flashy graphics tools are viewed as a distraction or cheapening. But other users have a completely different use: such as creating operational graphics for other people. Basically, the product for creating graphics for tactical in-field awareness should be a separate entity than creating graphics for others.
WSV3 Professional tried to shove these two diverse purposes together into one product and greatly suffered accordingly.
ProbSevere will be fun to integrate. It's a vector format which I like. It's in the horrible travesty which is JSON format, but the WSV3 Tactical server ingest infrastructure will run its special magic to pre-parse and pack it up very tight for fast access by client.
Thanks again for this list and let me know if you have any further comments/rebuttals/ideas/questions based on my reply. Also if you have any other general ideas or requests.