WSV3 2025 Next-Gen Terrain/Mapping engine

Not only decent raster imagery/elevation global coverage with the proprietary Landsat dataset, but over Europe, should be no problem to have default vector mapping layers with at least country boundaries. I am sure low-res international primary roads also exists. We will have an excellent representation of Europe and other non-CONUS areas in the base mapping components. Everything will download compressed vector tiles and raster tiles from a centralized data streaming server, with full-space shapefiles only optionally present if the user wants to extend the mapping.

The second shot below shows how great the new screenspace-extruded line rendering is compared with traditional world-space method, a difference particularly notable at angled/perspective views. I am developing a very efficient 3D terrain line rendering pipeline using GPU compute shaders and compact vector tiles for this.

Further strides in GIS vector/polyline rendering and accelerated vector tile generation from input shapefiles. Going to have to spend multiple months in this area. Resurrected the experimental summer 2023 SDF line rendering offset-effects I had previously pictured some experiments with. Another cool little utility to aid myself in making these screenshots is a proper screenshot export feature - Ctrl+S automatically saves to configurable directory and clips to window rectangle. No file prompt window appears, for maximal convenience and minimal annoyance. It launches a Windows explorer window once containing the dedicated Screenshots folder in the user-specific AppData folder - similar concept to Android smartphone "screenshot" folder. We want this to be a convenient part of the experience. Also using JPG now with high quality/low compression which still massively reduces file size over PNG at little visual cost. An additional feature further enhancing convenience on the new embedded screenshots feature will be to detect if a Windows explorer window is already opened to the screenshots folder and not re-launch it if so.

OptimallyAxel Spot on. That is a L2 scan of the September 8th severe thunderstorm event, which ravaged Andover where I was at the time with convective wind damage, ironically, driving back to NH during the first week of development of WSV3 Tactical Mesoanalyst 2025. I said to myself while stuck on 495 it would make a great test dataset to use for radar graphics during development. I found it serendipitous that the most notable severe convective event within 20 miles of my Windham headquarters in the past few years coincided with my initial beginnings this past early September on the next-generation rewritten from scratch WSV3 product. Yes, I included the last shot to highlight the 3D terrain-projected lines and also the rendering feature of using a different/customizable line style where terrain-occluded (i.e. "behind" terrain).

MeteoLatvia I'm right on the cusp of whipping-up a basic UI, similar to what's in first-generation V6 Prototype, for basic shapefile import and line styling settings. Then I will be able to easily churn-out some cool international/Europe-focused mapping graphics as I'm sure Google will yield some free shapefiles I can drag-in. Right now I can only programmatically control this which is a pain, so to maximize efficiency, I will discipline myself to hold-off until I have a basic UI. This kind of discipline has been a common theme for me in the past 5 months because I know how cool very nearly accessible things are (such as volume rendering), but I know that I will be a position in X months' time to implement them more time-efficiently. So, given the extremely daunting amount of work I have created for myself in a timeframe maximally extending to 11:59pm on 12/31/2025, I have to be very tactical and efficient (just like the software itself) about development/coding prioritization.

radioman10 Definitely would not force JPG and leave an option for PNG. However, I think we can safely omit all other image export formats. The philosophy of the new WSV3 is to do the most useful things very well as opposed to a low-quality implementation of a bunch of useless options. This is core to the overriding Data Oriented Design philosophy which has guided me since 2021, when I first watched Mike Acton's famous 2014 CppCon talk. Even the aspect of writing a highly performant, specialized Windows-based PC GPU graphics program instead of a bloated web application is an example of this principle. So getting back to the high-level application, JPG and PNG export, and the broadcast version will have extensive automation abilities to trigger a command line/batch file if you need to do more than that. Getting back to the philosophy for a second, you can see why this is so useful in a world where we have things like ImageMagick for absolutely free. No need to bloat the software reinventing the wheel. It should offer a highly optimized experience to accomplish the bare minimum requirements and, in the broadcast version, allow for automation/command line execution for custom processing after the fact, where you can use open-source, easy solutions.

I want to revisit your great ideas for the screenshot saved indicator. This is one of many areas where something like this will be useful, so it's something I need to wait until I can understand better in relation to those other areas. This will likely be connected with the HUD/text/vector graphics system, which I haven't created yet beyond the very simple V6P hard-coded city label rendering example.

Same is true for video export: how this works and all the options are partitioned depends a lot on the broadcast functionality/version, which I am nowhere near. For the non-broadcast primary version which I still want to keep in the current $25-30/month range, I do not want to deprive the user of manual video export. Actually, I want to make it faster and easier to use. I will likely have to force a small watermark to justify allowing broadcast-quality weather graphics export at consumer prices, which is an idea I was previously resistant to. However, let me opine more on philosophy with the sandwich analogy:

I want to subdivide the different versions of WSV3 Tactical Mesoanalyst 2025, from low-cost consumer to industrial/TV broadcast, like cutting a sandwich vertically and NOT horizontally. Instead of only getting bread and no meat in the smaller cuts, I would rather everyone get a lesser dose of the maximal experience (advanced 3D rendering, value-added streaming server-side compressed data products, highly customizable graphics and friendly export graphics usage rules for individuals, etc) than give fuller doses of a more limited experience.

As it concerns the video export feature, an example of this is allowing and even encouraging it on the personal, non-broadcast license, but adding a watermark to drive sales to keep the price for consumers low and further differentiate between the industrial version.

Anyways, getting back to the indicator idea, here is another requirement I already considered for a status indicator. Each map needs to have a concept of "loading" vs "loaded". This logic will be of utmost importance in any broadcast version, where preloading hot data into memory for rapid transitions is required. It also plays into the tactical-grade low-power-optimized rendering engine design where the product only uses the GPU to render frames when something is changed - camera view, data load status, and remaining animation effects being three large categories. When you merely move the map, somewhere there needs to be an indicator that briefly goes from "loading" to "loaded". When you first run the software and it needs to download a lot of mapping data, there should be a clear indicator the map is still loading raster and vector tiles. I already have this half-working where it stops rendering after new tiles are loaded, however it still does full-framerate rendering during the loading period itself instead of constraining to new texture/etc loads, efficient logic which will be added. This is similar to the concept of "edge computing".

As for UI indications of "map loading", I thought of maybe a green vs yellow circle in the upper map tab. It's possible it could be in the on-map HUD as well. Need to think of this in the context of other small status indicators like the one you proposed. There will likely be others. I want there to be a on-battery indicator and automatic switchover between power/graphics modes based on plugged-in-or-not. Lots of ideas to ruminate. Thankfully, the UI and on-map HUD are going to come last in development, due to the order of dependencies, so we have a lot of time to think about this.

Following shots from the last three days made possible by satisfying progress on GIS vector polyline rendering in the new 3D engine. Map style customizations reflected throughout shots below are manual shader code edits on my part - i.e., these will be wrapped in a user-facing graphical interface and, since they are merely shader constants, will enable rapid, instantaneous switching of styles on-command. The 2016 background engine in the first-generation product has the "Map Styles" window, but this required reloading the map. It was also tied to background/terrain only and did not include vector line/polygon styles. WSV3 Tactical Mesoanalyst will have one unified map style setting and deliver impressively fast switching between map styles. I also intend the map style to be able to differ independently across open maps.

OptimallyAxel Great question. Most likely, I will spend the rest of the year just on the mapping and HUD/map object graphics engine. I've known since September that there is so much potential for a useful GIS application for map making and custom shapefile work that this should be a separate product. It should be the base tier and constitute the engine upon which the full product is built with meteorological data and algorithms.

I have mostly decided this will be called WSV3 Tactical Cartographer, and can be the base tier of the overall next-gen product suite. Mesoanalyst will be built in 2025 upon the killer mapping engine and data display abilities of Cartographer in 2024. It would be great to release Mesoanalyst on the 10 year anniversary of WSV3 on 12/13/25.

Still haven't touched shapefile labeling (road signs, text street names, maybe general DBF-based labeling), point data rendering, generic raster engine with terrain overlay abilities, contour lines, nor the extensible unified SDF-based HUD graphics system for pop-ups, overlays, text, etc which will be critical for user analysis and interrogation of on-map content. Animated vector field particle stream and volume rendering might be more exclusive to Mesoanalyst or otherwised developed closer to release. Doing the base Cartographer edition lets me focus on perfecting the base components before progressing to real-time data.

I'll have more info on this, but it would be a shame to have to make people wait an additional 8-12 months to derive value from the new base 3D GIS rendering engine solely because all the meteorological content hasn't been developed.

I am embracing wild ideas about automatic cross-device web account sychronized custom map content/style customization, social media like map styles sharing and community voting system, and even ways of crowdsourcing manual high-res orthoimagery stitching and assembly for deeper imagery than the base datasets. There are many opportunities in purely the GIS/cartography/map styling case before we even get to real-time geospatial data and meteorological algorithm/data service development.