Develop a web-based interactive 3D visualization platform that integrates numerical ocean model outputs and in-situ observations.

Description:	Background India's vast Exclusive Economic Zone (EEZ) and coastline demand continuous, high-resolution monitoring of ocean state variables. INCOIS routinely generates and archives large volumes of ocean model outputs - including three-dimensional fields of temperature, salinity, current vectors, chlorophyll, etc. - as well as real-time and delayed-mode observations from autonomous instruments such as Argo profiling floats and underwater Gliders. These datasets are stored in NetCDF and ASCII/text formats and span multiple depth levels, spatial grids, and time steps. Despite the richness of this data, no integrated, web-based 3D visualization platform currently exists that can simultaneously render model fields and in-situ instrument observations in a single interactive environment. Existing tools are either desktop-bound, support only 2D plan views, or lack the ability to co-visualize model outputs alongside instrument profiles. Operational oceanographers and forecasters are therefore forced to toggle between disparate software packages, making it difficult to rapidly correlate model predictions with observational evidence. Key gaps identified include: No web-based, platform-independent 3D rendering of ocean model data (temperature, salinity, currents, etc.) with depth-resolved volumetric views. No unified display of Argo float and Glider profile data (latitude, longitude, depth, time, temperature, salinity, chlorophyll) alongside model fields. Absence of interactive controls for variable selection, depth-slice navigation, time-step animation, and customizable colorbars. Inability to ingest new observational data streams or additional model variables without significant re-engineering. Lack of tools to support intuitive, rapid understanding of complex 3D ocean phenomena for operational decision-making. The absence of such a system impedes timely hazard assessment, search-and-rescue support, fishery advisories, climate monitoring, etc. - all operational mandates of INCOIS. Expected Solution The proposed solution is a web-based, browser-native 3D Ocean Data Visualization System that integrates ocean model outputs with observational data on a single interactive platform. Core functional requirements: 3D Volumetric Rendering: Interactive visualization of ocean model fields (temperature, salinity, current vectors) across the full water column, with support for depth-slice views, isosurface extraction, and time-step animation using WebGL / Three.js or Cesium.js. Instrument Data Overlay: Co-display of Argo float, Glider profile, CTD and BGC data using geospatially accurate markers; users can click a float/glider to inspect a depth-vs-variable profile chart with timestamps. Multi-format Data Ingestion: Automated parsers for NetCDF (via PyNIO / xarray backend) and delimited text formats, with a modular architecture that allows new variables or data sources to be added with minimal code change. Customizable Colorbar & Variable Controls: Dynamic colorbar editor (color palette, min/max range, log/linear scale), variable selector, layer opacity controls, and vertical exaggeration slider for intuitive depth perception. Web-based, Scalable Architecture: Frontend built on modern JavaScript frameworks with a lightweight REST/OPeNDAP API backend, enabling deployment on INCOIS infrastructure without any client-side dependencies. Extensible Design: Plugin-style module for future integration of additional sensors (e.g., CTDs, moorings, HF-radar, Acoustic Doppler Current Profiler (ADCP), etc.), new ocean model variables, and machine-learning derived products. The system will follow open standards ( OGC WMS/WCS, CF Conventions for NetCDF ), enabling interoperability with national and international ocean data portals. The end product will empower INCOIS forecasters to perform rapid, intuitive analysis of complex 3D ocean phenomena - significantly improving the speed and accuracy of operational advisories, in the same way that 3D meteorological visualization has transformed weather forecasting workflows. Public Outreach & Science Communication Beyond operational use, the platform will serve as a powerful science communication tool. Complex numerical ocean model outputs - which are typically inaccessible to non-specialists - can be transformed into visually intuitive, interactive 3D experiences. This makes the tool valuable for educating school and college students about ocean dynamics, engaging the general public during awareness campaigns, and supporting policymakers in understanding marine environmental conditions. INCOIS can use the platform for outreach events, exhibitions, and e-learning initiatives, bridging the gap between cutting-edge ocean science and the common person.
Organization:	Ministry of Earth Sciences (MoES)
Department:	Indian National Centre for Ocean Information Services (INCOIS) Ocean Valley
Category:	Software
Theme:	Disaster Managementtd>
Youtube Link:	Not provided
Dataset Link:	The following dataset links are missing and should be included: a. Numerical Ocean Model Outputs: https://las.incois.gov.in/ & https://data.marine.copernicus.eu/product/GLOBAL_MULTIYEAR_PHY_001_030/description b. Argo Global Data: ftp://ftp.ifremer.fr/ifremer/argo c. Glider Data: ftp://ftp.ifremer.fr/ifremer/glider/v2/ d. Collection of In-situ Data:
Contact info:	Not provided

SIH 2026 Solution Dossier: Web-Based Interactive 3D Ocean Data Visualization Platform

1. Executive Snapshot

Summary

The Indian National Centre for Ocean Information Services (INCOIS), an autonomous organization under the Ministry of Earth Sciences (MoES), generates and archives vast volumes of 3D ocean model fields (e.g., MOM5, GODAS, ROMS, BGC) alongside real-time and delayed-mode in-situ observational profile data (Argo floats, underwater Gliders, CTD, moorings) across India's Exclusive Economic Zone (EEZ) and the broader Indian Ocean [PS]. Currently, oceanographers and operational forecasters must switch between legacy desktop GIS, 2D plan-view web servers, and offline scripts, creating a critical bottleneck in rapidly correlating model forecasts with direct observations during marine emergencies [PS]. This proposed solution delivers a platform-independent, web-native 3D interactive ocean visualization system that seamlessly co-renders 4D/3D volumetric numerical model fields and geospatial in-situ profiles in a single browser viewport [INFERENCE]. By combining WebGL/Cesium.js volumetric GPU raycasting, dynamic depth slicing, custom colorbar/isosurface extraction, and interactive profile chart inspection, the platform accelerates operational decision-making for disaster management, search-and-rescue, and fishery advisories while doubling as an engaging science communication tool for public outreach [INFERENCE].

Metadata Table

Property	Value
PS Number	SIH26067 [PS]
Title	Develop a web-based interactive 3D visualization platform that integrates numerical ocean model outputs and in-situ observations. [PS]
Organization	Ministry of Earth Sciences (MoES) [PS]
Department	Indian National Centre for Ocean Information Services (INCOIS) Ocean Valley [PS]
Category	Software [PS]
Theme	Disaster Management [PS]
Deadline	30 September 2026 [PS]
Ideas Counter	0/500 [PS]

Fundamental System Objective

To empower INCOIS operational forecasters and public stakeholders with an open-standard, browser-native 3D platform that co-renders volumetric ocean numerical model outputs alongside real-time in-situ instrument profiles in a single interactive environment for rapid hazard assessment and science outreach [PS].

2. Problem Deconstruction

The problem statement explicitly highlights existing operational gaps and outlines functional requirements for a web-based 3D ocean data visualization platform [PS].

Explicit Problem Statement Requirements

1. 3D Volumetric Rendering [PS]:

   • Source Text: "Interactive visualization of ocean model fields (temperature, salinity, current vectors) across the full water column, with support for depth-slice views, isosurface extraction, and time-step animation using WebGL / Three.js or Cesium.js." [PS]
   • Interpretation: The frontend must render 3D scalar fields (temperature, salinity) as volumetric textures or isosurfaces and vector fields (currents $u, v, w$) as directional streamlines/particles across multiple depth layers [INFERENCE].
   • Implementation Implication: Requires slicing 4D NetCDF files ($T, Z, Y, X$) into compressed WebGL-friendly 3D texture blocks or WebGPU volume buffers, alongside custom WebGL shaders for GPU raycasting and volumetric slicing [INFERENCE].

2. Instrument Data Overlay [PS]:

   • Source Text: "Co-display of Argo float, Glider profile, CTD and BGC data using geospatially accurate markers; users can click a float/glider to inspect a depth-vs-variable profile chart with timestamps." [PS]
   • Interpretation: In-situ point and trajectory profile datasets must be geospatially anchored over the 3D terrain/globe [INFERENCE]. Selecting an instrument marker triggers interactive popups displaying depth profiles ($Z$ vs $T/S/Chl$) and time-series plots [INFERENCE].
   • Implementation Implication: Ingest Argo trajectory index files and Glider NetCDF profiles into GeoJSON/CZML format; link map interaction events to Chart.js/Plotly.js rendering overlays [INFERENCE].

3. Multi-format Data Ingestion [PS]:

   • Source Text: "Automated parsers for NetCDF (via PyNIO / xarray backend) and delimited text formats, with a modular architecture that allows new variables or data sources to be added with minimal code change." [PS]
   • Interpretation: Backend service must auto-parse NetCDF files (CF-compliant) and ASCII/CSV text files from INCOIS LAS or FTP feeds, converting them into structured API responses or Zarr/COG/JSON formats [INFERENCE].
   • Implementation Implication: Build a Python FastAPI ETL pipeline using xarray, netCDF4, dask, and pandas [ASSUMPTION]. (Note: PyNIO is deprecated in modern scientific Python, so xarray + netCDF4/h5netcdf serves as the resilient backend driver) [RESEARCHED].

4. Customizable Colorbar & Variable Controls [PS]:

   • Source Text: "Dynamic colorbar editor (color palette, min/max range, log/linear scale), variable selector, layer opacity controls, and vertical exaggeration slider for intuitive depth perception." [PS]
   • Interpretation: User interface must provide real-time controls over shader lookup tables, data stretching, opacity, variable switching, and vertical scale adjustment ($Z$-scaling) to accommodate shallow coastal vs. deep ocean bathymetry [INFERENCE].
   • Implementation Implication: Map UI sliders directly to WebGL uniform variables (u_min, u_max, u_opacity, u_zExaggeration, u_colormapTexture) without requiring full scene re-renders [INFERENCE].

5. Web-based, Scalable Architecture [PS]:

   • Source Text: "Frontend built on modern JavaScript frameworks with a lightweight REST/OPeNDAP API backend, enabling deployment on INCOIS infrastructure without any client-side dependencies." [PS]
   • Interpretation: No desktop software, Java applets, or plugins required on the user device [INFERENCE]. Runs in standard WebGL2-enabled web browsers (Chrome, Firefox, Edge, Safari) [KNOWN].
   • Implementation Implication: React / Vite single-page application frontend communicating with an OPeNDAP/THREDDS server or FastAPI microservice over REST/WMS [INFERENCE].

6. Extensible Design [PS]:

   • Source Text: "Plugin-style module for future integration of additional sensors (e.g., CTDs, moorings, HF-radar, Acoustic Doppler Current Profiler (ADCP), etc.), new ocean model variables, and machine-learning derived products." [PS]
   • Interpretation: Architecture must enforce modular abstraction layers for data loaders, UI controls, and visualizers [INFERENCE].
   • Implementation Implication: Abstract Data Provider Interface pattern in JavaScript/TypeScript and adapter pattern in Python ETL pipeline [INFERENCE].

7. Open Standards Compliance [PS]:

   • Source Text: "The system will follow open standards (OGC WMS/WCS, CF Conventions for NetCDF), enabling interoperability with national and international ocean data portals." [PS]
   • Interpretation: Services must conform to Open Geospatial Consortium (OGC) specifications (WMS/WCS) and NetCDF Climate and Forecast (CF) Metadata Conventions (v1.8+) [RESEARCHED].
   • Implementation Implication: Serve standard GeoTIFF/WMS layers via GeoServer/THREDDS alongside custom 3D volume tiles [INFERENCE].

8. Public Outreach & Science Communication [PS]:

   • Source Text: "Beyond operational use, the platform will serve as a powerful science communication tool... educating school and college students about ocean dynamics, engaging the general public... and supporting policymakers." [PS]
   • Interpretation: Platform must feature dual UX modes: an "Operational Mode" with dense technical controls and a simplified "Public Outreach Mode" with guided 3D story maps and intuitive tooltips [INFERENCE].

3. Stakeholders & User Needs

Stakeholder	Goal	Current Pain	System Need
INCOIS Operational Forecasters [PS]	Issue rapid, accurate marine advisories (storm surge, ocean state, SAR) [PS].	Toggling between disparate desktop software, 2D plan-view maps, and static scripts [PS].	Integrated 3D co-visualization of model outputs & real-time float/glider observations [PS].
Marine Disaster Managers (NDRF / Coast Guard) [INFERENCE]	Plan search-and-rescue (SAR) and oil spill containment [PS].	Complex NetCDF model outputs are hard to digest under time pressure [PS].	3D visual current particle fields, surface/subsurface velocity vector plots [PS].
INCOIS Data Administrators [PS]	Ingest new sensor types (ADCP, HF-Radar, Moorings) without code overhaul [PS].	Inability to ingest new data streams without significant re-engineering [PS].	Modular ETL pipeline and plugin-style registry architecture [PS].
Research Oceanographers / Climate Scientists [INFERENCE]	Validate numerical models against in-situ observations (Argo, Gliders) [PS].	Manual spatial-temporal matching of 3D grids with sparse point profile data [PS].	Interactive depth slice navigation, isosurface extraction, profile comparison popups [PS].
Students, Educators & Public [PS]	Understand complex ocean dynamics (thermocline, circulation, marine heatwaves) [PS].	Raw ocean model outputs are completely inaccessible to non-specialists [PS].	Interactive 3D globe outreach mode with pre-set camera tours and explanatory tooltips [PS].
Policymakers & Coastal Authorities [PS]	Evaluate marine environmental conditions and climate impacts [PS].	Summary reports lack intuitive visual context for decision-making [PS].	High-impact 3D visual storytelling and exportable high-res figures/animations [PS].

4. Requirements Traceability

Feature ID	Proposed Platform Feature	Source Requirement	Justification
F-01	GPU-Accelerated WebGL Raycasting Volume Renderer	Core Requirements - 3D Volumetric Rendering [PS]	Allows interactive 3D rendering of 3D ocean temperature/salinity volumes across the water column [PS].
F-02	3D Isosurface Extractor & Slice Plane Navigator	Core Requirements - 3D Volumetric Rendering [PS]	Enables extraction of specific physical boundaries (e.g., $20^\circ\text{C}$ thermocline boundary) and horizontal/vertical $X-Z / Y-Z$ slices [PS].
F-03	Animated 3D Particle/Streamline Vector Field Visualizer	Core Requirements - 3D Volumetric Rendering [PS]	Renders 3D ocean currents ($u, v, w$) dynamically across time steps [PS].
F-04	Geospatial In-situ Marker Layer (Argo & Gliders)	Core Requirements - Instrument Data Overlay [PS]	Renders float positions and underwater glider 3D trajectory lines accurately on globe [PS].
F-05	Interactive Depth Profile & Time-Series Inspector	Core Requirements - Instrument Data Overlay [PS]	Displays interactive $Z$-vs-Variable line graphs when clicking markers [PS].
F-06	Modular Python xarray/NetCDF ETL Pipeline	Core Requirements - Multi-format Data Ingestion [PS]	Auto-parses CF-compliant NetCDF files and ASCII profile data into API chunks [PS].
F-07	Dynamic Shader Palette Editor & Vertical Exaggeration	Core Requirements - Dynamic Colorbar Controls [PS]	Controls min/max ranges, palettes, log scales, and vertical $Z$-axis stretch ($1\times - 100\times$) in real-time [PS].
F-08	Plugin Adapter Architecture for New Sensors	Core Requirements - Extensible Design [PS]	Allows developers to add ADCP, HF-Radar, or ML products with simple JSON/Python adapters [PS].
F-09	OGC WMS/WCS & OPeNDAP Interoperability Layer	Open Standards Compliance [PS]	Ensures integration with national/international portals using standard protocols [PS].
F-10	Dual UX (Operational Workbench vs. Public Outreach Mode)	Public Outreach & Science Communication [PS]	Serves both expert forecasters and student/public science communication [PS].

5. Constraints & Environment Realities

1. Client-Side Hardware Diversity [INFERENCE]:

   • Operational forecasters may possess high-end workstations with discrete GPUs, whereas schools and public users operate on basic laptops, tablets, or integrated graphics [INFERENCE].
   • Mitigation: WebGL2 fallback modes, Level-of-Detail (LOD) volumetric texture sub-sampling, and adaptive frame-rate adjustment [INFERENCE].

2. Network Bandwidth Constraints [INFERENCE]:

   • Raw 3D ocean model outputs (e.g., $0.083^\circ \times 0.083^\circ \times 50 \text{ depth levels} \times 24 \text{ time steps}$) exceed several gigabytes per day [RESEARCHED]. Streaming uncompressed NetCDF directly to browser viewports will choke internet connections [INFERENCE].
   • Mitigation: Server-side data sub-sampling, Zarr chunking, and compressed WebGL 3D texture format generation ($256 \times 256 \times 50$ RGB alpha atlas) [INFERENCE].

3. Geospatial & Vertical Scale Disparity [KNOWN]:

   • The horizontal extent of India's EEZ spans thousands of kilometers (e.g., $60^\circ\text{E} - 95^\circ\text{E}$), while depth spans only 0 to 6,000 meters [KNOWN]. On a true-scale 3D globe, the entire water column is a paper-thin surface sheet [KNOWN].
   • Mitigation: Implement real-time GPU vertical exaggeration slider ($10\times$ to $200\times$) and local bathymetric sub-surface curtain rendering [INFERENCE].

4. Heterogeneous Data Coordinates [KNOWN]:

   • Ocean models use structured curvilinear grids or regular lat-lon grids with vertical depth/sigma levels [KNOWN]. Argo floats provide discrete vertical point profiles at irregular temporal intervals [KNOWN]. Gliders record continuous diagonal sawtooth path profiles [KNOWN].
   • Mitigation: Normalize coordinate metadata on the backend into WGS84 ($EPSG:4326$) horizontal coordinates and standard depth levels ($meters$), keeping raw profile points intact for hover inspection [INFERENCE].

5. Deployment Environment [PS]:

   • Platform must deploy seamlessly on INCOIS server infrastructure without requiring end-users to install desktop software, browser extensions, or administrative plugins [PS].

6. Research Questions

1. How can multi-gigabyte 4D ocean NetCDF datasets be streamed efficiently to a browser for real-time 60 FPS WebGL rendering without memory crashes? [INFERENCE]
2. What is the optimal WebGL/WebGPU library stack (Cesium.js vs. Three.js vs. Deck.gl/vis.gl) for combining a global geospatial virtual globe with complex 3D volumetric raycasting? [INFERENCE]
3. How do we handle the vast spatial disparity between horizontal extent ($1,000\text{s of km}$) and ocean depth ($0 - 6\text{ km}$) without distorting terrain bathymetry or in-situ markers? [INFERENCE]
4. How can Argo float trajectories and underwater Glider profile paths be parsed from live Ifremer/INCOIS FTP feeds in real time and cached for low-latency browser requests? [INFERENCE]
5. What interface abstractions are required to ensure new sensors (ADCP, Moorings, HF-Radar) can be plugged into both the backend ETL and frontend rendering pipeline with zero breaking changes? [INFERENCE]

7. Data Requirements & Sources

Data Type	Purpose	Ideal Real-World Source	Hackathon Substitute	Access Method	Availability	Privacy Sensitivity	Confidence
Numerical Ocean Model Fields (Temp, Salinity, Currents)	3D Volumetric Rendering & Animation	INCOIS LAS (las.incois.gov.in) [PS] / Copernicus Marine (GLOBAL_MULTIYEAR_PHY_001_030) [PS]	Downsampled NetCDF subset for Indian Ocean ($40^\circ\text{E}-100^\circ\text{E}, -10^\circ\text{S}-30^\circ\text{N}$)	OPeNDAP / HTTPS / NetCDF download	Publicly available [PS]	Public Open Data [KNOWN]	[PS]
Argo Profiling Float Data (Lat, Lon, Depth, T, S)	In-situ profile marker overlay & validation	Global Data Assembly Centre (Ifremer FTP ftp://ftp.ifremer.fr/ifremer/argo) [PS]	Argo Indian Ocean NetCDF profile subset (synthetic / recent 30-day snapshot)	FTP / HTTPS REST API	Publicly available [PS]	Public Open Data [KNOWN]	[PS]
Underwater Glider Profiles (Lat, Lon, Depth, Time, T, S, Chl)	High-resolution vertical transect co-display	Ifremer Glider FTP (ftp://ftp.ifremer.fr/ifremer/glider/v2/) [PS]	Sample NetCDF/ASCII Glider mission transect file	FTP / HTTPS	Publicly available [PS]	Public Open Data [KNOWN]	[PS]
Bathymetry / Topography	3D Seabed floor background rendering	GEBCO / ETOPO1 3D Global Relief dataset [KNOWN]	Cesium World Terrain / Mapbox 3D Terrain Tiles [ASSUMPTION]	OGC WMS / Quantized Mesh Tiles	Publicly available [KNOWN]	Public Open Data [KNOWN]	[KNOWN]
CTD & BGC Observations	Conductivity-Temp-Depth & Biogeochemical profiles	INCOIS Ocean Data Information System (ODIS) [RESEARCHED]	Sample CF-compliant ASCII/CSV profile datasets	REST API / CSV Parsing	Publicly available [PS]	Public Open Data [KNOWN]	[RESEARCHED]

8. Existing Solutions & Gap Analysis

1. INCOIS Live Access Server (LAS) / ODIS Portal

• Description: Official INCOIS web-based data preview tool powered by Ferret/PyFerret backend [RESEARCHED].
• Strengths: Directly connected to INCOIS MOM4/MOM5/GODAS models; reliable 2D plot generation [RESEARCHED].
• Weaknesses: Limited to static 2D plan views, Hovmöller diagrams, and basic 2D horizontal/vertical slices [PS]. Lacks true WebGL-based interactive 3D rendering and co-display of in-situ profiles [PS].
• Relevance: Current operational baseline at INCOIS [PS].
• Gap: Cannot render 3D volume fields or co-display 3D float trajectories interactively in the browser [PS].
• Source: INCOIS LAS (https://las.incois.gov.in/) [PS].
• Confidence: [PS]

2. Copernicus Marine MyOcean Viewer

• Description: Web-based interactive portal for global marine dataset exploration developed by Mercator Ocean International [RESEARCHED].
• Strengths: Excellent 2D tile animation, horizontal depth level selector, time slider, point query graphs [RESEARCHED].
• Weaknesses: Primary display is 2D map plan-view with vertical slider; lacks true 3D volumetric raycasting across full water column and full 3D in-situ profile trajectory rendering [INFERENCE].
• Relevance: Benchmark for web UX and OPeNDAP integration [RESEARCHED].
• Gap: No true 3D volumetric isosurface extraction or 3D subsurface profile co-display [PS].
• Source: Copernicus Marine (data.marine.copernicus.eu) [PS].
• Confidence: [RESEARCHED]

3. Ocean Data View (ODV) / ParaView Desktop

• Description: Industry-standard desktop applications for oceanographic profile analysis and general 3D scientific visualization [RESEARCHED].
• Strengths: Highly accurate 3D volume rendering, isosurface extraction, profile scatter plots, section slicing [RESEARCHED].
• Weaknesses: Heavy desktop installation required; steep learning curve; cannot be embedded into zero-footprint web browsers for operational or public use [PS].
• Relevance: Gold standard for analytical feature set [RESEARCHED].
• Gap: Desktop-bound, lacks web accessibility, requires manual dataset prep [PS].
• Source: Public scientific documentation [RESEARCHED].
• Confidence: [KNOWN]

9. Candidate Solution Approaches

Approach 1: Virtual Globe (Cesium.js) + WebGL2 Volume Raycasting Shader (Recommended)

• Mechanism: Use Cesium.js for the global 3D geospatial context, terrain bathymetry, and in-situ 3D point markers/trajectories [INFERENCE]. Integrate custom WebGL2 3D texture raycasting shaders bound to a sub-surface bounding box frame to perform volumetric scalar rendering, dynamic depth slicing, and isosurface rendering [INFERENCE].
• Required Data: Pre-sliced Zarr / 3D PNG texture atlas generated by Python FastAPI backend from NetCDF inputs [INFERENCE].
• Architecture: React + Cesium.js + Custom WebGL Shaders frontend; FastAPI + xarray + Zarr backend [INFERENCE].
• Complexity: Moderate-High (Custom GLSL raycasting shader logic required) [INFERENCE].
• Explainability: High (Direct physical scalar mapping and geospatial anchoring) [INFERENCE].
• Cost: Low (100% Open Source: CesiumJS, FastAPI, Zarr) [INFERENCE].
• Scalability: High (Tile-based and chunked volume streaming) [INFERENCE].
• Hackathon Feasibility: 9/10 (Can build working MVP in 36-48 hours with sample NetCDF) [INFERENCE].
• Production Feasibility: 9.5/10 (Scales to full INCOIS operational infrastructure) [INFERENCE].

Approach 2: Server-Side VTK/PyVista Rendering with WebRTC/HLS Live Stream

• Mechanism: Perform heavy 3D volumetric rendering and isosurface extraction on a GPU server using Python VTK/PyVista/ParaView Server [INFERENCE]. Stream the rendered 3D scene frame-by-frame to the web client using WebRTC or WebSocket image frames [INFERENCE].
• Required Data: Direct NetCDF access on GPU server [INFERENCE].
• Architecture: Python PyVista / VTK server cluster + WebRTC stream + React control client [INFERENCE].
• Complexity: Very High (Heavy server GPU requirements, complex streaming latency management) [INFERENCE].
• Explainability: High [INFERENCE].
• Cost: High (Requires dedicated server-side GPU instances for concurrent web users) [INFERENCE].
• Scalability: Low (Poor scaling for public outreach with thousands of concurrent users) [INFERENCE].
• Hackathon Feasibility: 5/10 (High streaming latency and server configuration risk) [INFERENCE].
• Production Feasibility: 6/10 (Prohibitive server infrastructure costs for public use) [INFERENCE].

Approach 3: Hybrid Three.js 3D Volumetric Canvas + Deck.gl Geospatial Overlay

• Mechanism: Construct a custom 3D ocean scene using Three.js for volumetric rendering and Deck.gl for 2.5D/3D geospatial vector layers [INFERENCE]. Sync camera matrices between Deck.gl and Three.js [INFERENCE].
• Required Data: Client-side binary array buffers (Float32Array) via REST API [INFERENCE].
• Architecture: Three.js + Deck.gl React frontend + FastAPI backend [INFERENCE].
• Complexity: High (Camera matrix synchronization across two WebGL rendering contexts) [INFERENCE].
• Explainability: Moderate-High [INFERENCE].
• Cost: Low [INFERENCE].
• Scalability: High [INFERENCE].
• Hackathon Feasibility: 7/10 (Matrix sync bugs can waste significant build time) [INFERENCE].
• Production Feasibility: 8/10 [INFERENCE].

10. Recommended Approach & Why

Selection: Approach 1 (Cesium.js + WebGL2 Custom 3D Volume Raycasting + Python xarray Backend)

Why It Wins:

1. Geospatial & Volumetric Integration: Cesium.js natively handles global WGS84 coordinates, 3D terrain/bathymetry, and camera navigation [INFERENCE]. Custom WebGL2 volume raycasting shaders embedded within Cesium Primitive stages provide true 3D volumetric scalar rendering ($T, S$) directly inside the sub-surface water column [INFERENCE].
2. Zero Client Dependencies: Operates natively in any WebGL2-compliant web browser without third-party plugins [PS].
3. High Hackathon Feasibility: Cesium.js handles globe camera navigation out of the box, allowing the student team to focus energy on GLSL volumetric shaders, xarray data chunking, and profile UI popups [INFERENCE].
4. Outreach & Operational Flexibility: Supports both dual-perspective rendering (dense operational slicing vs. public guided camera tours) [INFERENCE].

Rejection Reasons for Alternatives:

• Approach 2 (Server-side VTK Streaming) was rejected because server-side GPU rendering for hundreds of concurrent public users introduces high infrastructure costs, streaming latency, and server bottlenecks [INFERENCE].
• Approach 3 (Three.js + Deck.gl Dual Canvas) was rejected due to complex WebGL depth-buffer and camera synchronization issues across two distinct canvas contexts, which poses high delivery risk during a timed hackathon [INFERENCE].

11. Technical Architecture

Layered Architecture Diagram

+-----------------------------------------------------------------------------------+
|                            USER INTERFACE LAYER (Browser)                         |
|  +-----------------------------------+   +-------------------------------------+  |
|  |   Operational Forecaster View     |   |    Public Science Communication View |  |
|  | - Advanced Shader & Slice Controls|   | - Guided 3D Camera Tours            |  |
|  | - Isosurface & Vector Streamlines |   | - Educational Popups & Tooltips     |  |
|  +-----------------------------------+   +-------------------------------------+  |
+-----------------------------------------------------------------------------------+
                                         |
+-----------------------------------------------------------------------------------+
|                           FRONTEND RENDERING ENGINE                               |
|  +-----------------------------------------------------------------------------+  |
|  | Cesium.js Virtual Globe Canvas (3D Bathymetry + Geospatial Markers)         |  |
|  |                                                                             |  |
|  | +-------------------------------------------------------------------------+ |  |
|  | | WebGL2 Custom Primitive Stage (GLSL Volume Raycasting Shader)          | |  |
|  | | - 3D Scalar Textures (Temp/Sal)    - Raymarching & Depth Slicing      | |  |
|  | | - Dynamic Isosurface Extraction    - Dynamic Colormap Lookup            | |  |
|  | +-------------------------------------------------------------------------+ |  |
|  | +-------------------------------------------------------------------------+ |  |
|  | | Vector Particle Engine (Current u, v, w Velocity Vector Fields)         | |  |
|  | +-------------------------------------------------------------------------+ |  |
|  +-----------------------------------------------------------------------------+  |
|  +-----------------------------------------------------------------------------+  |
|  | Chart.js / Plotly.js Overlay Engine (Depth-vs-Variable Profile Popups)     |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+
                                         | REST / OPeNDAP / GeoJSON
+-----------------------------------------------------------------------------------+
|                             BACKEND API & PIPELINE LAYER                          |
|  +------------------------------------+   +------------------------------------+  |
|  | FastAPI REST Microservices         |   | OPeNDAP / THREDDS Data Gateway     |  |
|  | - /api/v1/model/volume-chunk     |   | - Direct CF-NetCDF Subset Access   |  |
|  | - /api/v1/insitu/argo-profiles     |   | - OGC WMS/WCS Layer Endpoint       |  |
|  | - /api/v1/insitu/glider-transects  |   +------------------------------------+  |
|  +------------------------------------+                                           |
|  +-----------------------------------------------------------------------------+  |
|  | Extensible Sensor Plugin Registry (ADCP / Mooring / HF-Radar / ML Adapters)  |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+
                                         |
+-----------------------------------------------------------------------------------+
|                        DATA PROCESSING & STORAGE LAYER                            |
|  +------------------------------------+   +------------------------------------+  |
|  | Python Data ETL Pipeline           |   | Data Cache & Storage Store         |  |
|  | - xarray + netCDF4 Engine          |   | - Zarr / Compressed Binary Cache   |  |
|  | - Deldelimited Text / CSV Parsers  |   | - Redis Metadata Cache             |  |
|  | - WGS84 Resampling & Depth Slicing |   | - PostGIS (Argo/Glider Indexes)    |  |
|  +------------------------------------+   +------------------------------------+  |
+-----------------------------------------------------------------------------------+
                                         |
+-----------------------------------------------------------------------------------+
|                             DATA SOURCE REPOSITORIES                              |
|  +-----------------------+ +-----------------------+ +-------------------------+  |
|  | INCOIS LAS / MOM5     | | Copernicus GLORYS     | | Ifremer Argo/Glider FTP |  |
|  | NetCDF Files          | | NetCDF Products       | | Repositories            |  |
|  +-----------------------+ +-----------------------+ +-------------------------+  |
+-----------------------------------------------------------------------------------+

Data-Flow Narrative Step-by-Step

1. Ingestion & Processing: The backend ETL pipeline uses xarray and netCDF4 to monitor ocean model output repositories (INCOIS LAS / Copernicus) and in-situ FTP servers (Ifremer Argo/Glider) [INFERENCE].
2. Chunking & Formatting: 3D model variable grids ($T, S, u, v, w$) are processed into multi-dimensional Zarr store arrays or packed into 3D binary byte buffers [INFERENCE]. In-situ profile points and trajectories are indexed into GeoJSON/CZML structures with depth attributes [INFERENCE].
3. API Serving: When a user selects a spatial bounding box, time step, and model variable, the frontend issues a REST request to the FastAPI service [INFERENCE].
4. WebGL Volume Loading: The frontend downloads the downsampled 3D scalar byte array, loads it into a WebGL2 WebGLTexture3D, and passes uniform parameters (u_min, u_max, u_sliceDepth, u_zExaggeration) to the GLSL volume raycasting shader [INFERENCE].
5. Raymarching Render: The custom WebGL shader casts rays from the camera through the 3D bounding volume, sampling texture points to compute color and opacity based on user-configured colormaps and isosurface thresholds [INFERENCE].
6. In-situ Overlay & Interaction: Argo and Glider markers are placed on the Cesium globe at precise WGS84 locations [INFERENCE]. Hovering or clicking an in-situ marker triggers an event that fetches profile array data and renders an overlay graph using Chart.js/Plotly.js [INFERENCE].

12. Technology Stack

Layer	Selected Technology	Why	Alternative	Why Rejected
Frontend Framework	React (v18+) + Vite [ASSUMPTION]	Fast component rendering, strong ecosystem for UI state management and mapping controls.	Angular / Vue	Slower build setup during hackathon; larger boilerplate.
3D Geospatial Engine	Cesium.js (v1.110+) [PS]	Native 3D virtual globe, terrain bathymetry support, accurate geospatial positioning, CZML animation support [PS].	Three.js (alone)	Lacks built-in geospatial coordinate projections (WGS84) and globe tile streaming out of the box.
3D Shaders / Rendering	WebGL2 GLSL Custom Shaders [PS]	Native hardware-accelerated 3D texture raymarching, isosurface extraction, high FPS [PS].	WebGPU	WebGPU browser support is still evolving across older client devices; WebGL2 offers maximum compatibility [KNOWN].
Chart Overlay	Chart.js / Plotly.js [INFERENCE]	Highly interactive, lightweight line chart rendering for depth-vs-variable profiles [INFERENCE].	D3.js (raw)	Longer development time for basic profile line charts during hackathon.
Backend API	Python FastAPI (v0.100+) [ASSUMPTION]	High-performance async REST framework, native OpenAPI specs, seamless integration with Python scientific libraries [ASSUMPTION].	Node.js / Express	Lacks native, efficient C-bound NetCDF/xarray scientific processing tools.
Data Processing	xarray + netCDF4 + dask [PS]	Gold standard for multi-dimensional oceanographic array parsing and chunking [PS].	PyNIO	PyNIO is unmaintained/deprecated in modern scientific Python distributions [RESEARCHED].
In-Situ Indexing DB	PostgreSQL + PostGIS / SQLite [ASSUMPTION]	Spatial indexing (ST_DWithin, spatial bounding box queries) for fast Argo/Glider marker lookup [ASSUMPTION].	MongoDB	Weaker native support for complex 3D geospatial trajectory bounding box queries.
Standards Interface	OGC WMS/WCS & OPeNDAP Gateway [PS]	Ensures strict compliance with INCOIS/MoES interoperability mandates [PS].	Proprietary WebSockets	Non-standard, breaks compliance with national ocean data portals.

13. AI/ML Justification

Proposed AI/ML Component: 3D Spatial Profile Gap-Infilling & Ocean Feature Extraction (Eddy Detection)

1. What exact problem does AI solve?
   • Ocean model outputs and in-situ profiles have spatial-temporal gaps (e.g., cloud cover in satellite SST, sparse Argo float spatial density) [INFERENCE]. AI algorithms (e.g., 3D Kriging neural networks or Convolutional Autoencoders) perform spatial gap-infilling and automatically extract 3D oceanic features such as mesoscale eddies and thermocline boundary layers [INFERENCE].
2. What is the input?
   • 3D gridded numerical model scalar fields ($T, S$) and sparse in-situ profile vectors [INFERENCE].
3. What is the output?
   • Infilled continuous 3D scalar arrays and 3D bounding geometry metadata marking mesoscale eddy centers and boundary contours [INFERENCE].
4. Why can a simpler rule/system not solve it?
   • Simple linear or bi-cubic interpolation smooths out non-linear physical dynamics like sharp fronts and eddy boundaries [INFERENCE].
5. What data is required?
   • Historical 3D MOM5/GODAS reanalysis fields (e.g., Copernicus GLOBAL_MULTIYEAR_PHY_001_030) and synchronized Argo profile datasets [PS].
6. How will it be evaluated?
   • Mean Squared Error (MSE) and structural similarity (SSIM) against cross-validated holdout Argo profile observations [INFERENCE].
7. What happens when it is wrong?
   • The system falls back to standard inverse-distance weighting (IDW) or raw physics model output [INFERENCE].
8. Does it require training? Yes [INFERENCE].
9. Does it require fine-tuning? Yes, on regional Indian Ocean high-resolution datasets [INFERENCE].
10. Does it require RAG? No [INFERENCE].
11. Does it require computer vision? Yes (3D CNNs for spatial volume pattern detection) [INFERENCE].
12. Does it require speech processing? No [INFERENCE].
13. Does it require forecasting? Optional (short-term eddy movement prediction) [INFERENCE].
14. Is human oversight required? Yes, INCOIS forecasters must visually verify AI-extracted eddy boundaries against direct observation profiles before issuing advisories [PS].

Where AI Should NOT Be Used

• Raw Render Pipeline: AI should NOT be used to generate or synthesize the primary WebGL rendering shaders or raw physical data values [INFERENCE]. Forecasters require exact physical numerical values, not AI-hallucinated imagery [PS].

14. Data Architecture & Offline/Low-Network Design

Data Schema (PostGIS & Zarr Structure)

In-Situ Observation Metadata Table (insitu_platforms)

• platform_id (VARCHAR, PK): e.g., "ARGO_2901542", "GLIDER_INCOIS_04"
• platform_type (ENUM): 'ARGO', 'GLIDER', 'CTD', 'BGC', 'MOORING'
• last_latitude (FLOAT), last_longitude (FLOAT)
• trajectory_geom (GEOMETRY(LineStringZ, 4326)): 3D spatial track
• last_updated (TIMESTAMP)

Profile Measurement Table (insitu_profiles)

• profile_id (UUID, PK)
• platform_id (FK -> insitu_platforms)
• timestamp (TIMESTAMP)
• location (GEOMETRY(PointZ, 4326))
• depth_array (FLOAT[]): Array of depth values ($m$)
• temp_array (FLOAT[]): Temperature values ($^\circ\text{C}$)
• salinity_array (FLOAT[]): Salinity values ($\text{PSU}$)
• chlorophyll_array (FLOAT[]): Chlorophyll values ($\text{mg/m}^3$)

Offline & Low-Network Strategies

+-----------------------------------------------------------------------+
|                       LOW-NETWORK RESILIENCE                          |
|                                                                       |
|  +---------------------+    +-------------------+    +-------------+  |
|  | Progressive LOD     |    | Browser Cache     |    | Delta Sync  |  |
|  | Sub-sampling        |    | (IndexedDB Layer) |    | Engine      |  |
|  | (128x128 -> 256x256)|    | - Geometry/Tiles  |    | - Metadata  |  |
|  |                     |    | - Profiles        |    |   Only      |  |
|  +---------------------+    +-------------------+    +-------------+  |
+-----------------------------------------------------------------------+

1. Progressive Level-of-Detail (LOD) Volume Sub-sampling: Under constrained bandwidth, the backend serves low-resolution 3D grid volumes ($64 \times 64 \times 25$). As network throughput allows, high-resolution volume grids ($256 \times 256 \times 50$) stream progressively [INFERENCE].
2. Local Caching (IndexedDB): Client-side IndexedDB caches downloaded bathymetry tiles, in-situ platform metadata, and profile array JSONs [INFERENCE].
3. Bandwidth Reduction via Byte Packing: Floating-point scalar arrays ($T, S$) are normalized to 8-bit unsigned integers (uint8) mapped to min/max scalar ranges, cutting network payload size by 75% [INFERENCE].
4. Offline UX Mode: If network connection drops, the UI displays a warning banner, preserves the currently loaded 3D scene, and allows offline inspection of cached profiles and slices [INFERENCE].

15. Security, Privacy & Governance

1. Personal Data: The system processes oceanographic environmental data; no personal identifiable information (PII) is stored or processed [PS].
2. Location Data: Platform stores WGS84 geospatial coordinates of ocean observations [PS]. All data belongs to public Exclusive Economic Zone (EEZ) and open ocean domains [KNOWN].
3. Authentication & Authorization:
   • Public Outreach View: Open access, no login required [PS].
   • Operational Forecaster View: Role-Based Access Control (RBAC) via INCOIS Single Sign-On (OAuth2 / OpenID Connect) to access pre-publication numerical model runs and sensitive advisory drafts [INFERENCE].
4. Encryption: Transport Layer Security (TLS 1.3) HTTPS/WSS for all REST and WebSocket API endpoints [KNOWN].
5. Data Ownership & Licensing: Data products originate from MoES/INCOIS and Copernicus Marine Services, governed by Open Government Data License (OGDL) and Copernicus Open License [PS].
6. Audit & Governance: Log all user access to operational advisory export endpoints for administrative auditing [INFERENCE].
7. Liability & Disclaimer: Visualizations serve as decision-support aids [PS]. Final operational disaster advisories (e.g., Tsunami, Cyclone Storm Surge) require human sign-off by authorized INCOIS duty officers [PS].

16. MVP Scope (Hackathon Build)

In Scope (MUST BUILD)

• 3D Volumetric Ocean Field Visualizer: WebGL/Cesium.js rendering of 3D ocean temperature and salinity volumes over the Indian Ocean using sample NetCDF files [PS].
• Depth Slicing & Vertical Slider: Interactive $X-Z$ and $Y-Z$ slice plane controls and vertical exaggeration slider ($1\times - 50\times$) [PS].
• In-situ Marker Overlay: Geospatially accurate markers for Argo profiling floats and Glider tracks in the Bay of Bengal / Arabian Sea [PS].
• Interactive Profile Chart Inspection: Clicking float/glider markers opens popups displaying interactive depth-vs-temperature/salinity charts [PS].
• Customizable Colorbar & Controls: Dynamic palette switcher, min/max range sliders, variable selector ($T$ vs $S$), and opacity sliders [PS].
• NetCDF & Text ETL Backend: Python FastAPI backend parsing CF-compliant NetCDF files and CSV in-situ profiles [PS].
• Dual UX Switcher: Simple UI toggle between "Operational Forecaster Mode" and "Public Science Communication Mode" [PS].

Described Only / Out of Scope (HACKATHON BUILD)

• Full production deployment across multi-node INCOIS Kubernetes clusters [INFERENCE].
• Live real-time ingestion of live HF-Radar, ADCP, and Mooring streaming hardware feeds [PS].
• Complex machine learning-based 3D eddy feature extraction models [PS].
• Full national SSO enterprise identity integration [INFERENCE].

17. Live Demo Simulation Plan

To ensure a flawless live presentation without relying on external network availability or live government endpoints:

+-------------------------------------------------------------------------------+
|                         HACKATHON DEMO ARCHITECTURE                           |
|                                                                               |
|  +--------------------+   +---------------------+   +----------------------+  |
|  | Mock INCOIS LAS    |   | Local NetCDF        |   | Pre-fetched Argo     |  |
|  | Server Endpoint    |   | Sample File Cache   |   | FTP Json Datasets    |  |
|  | (Local FastAPI)    |   | (Bay of Bengal /    |   | (30 Active Floats /  |  |
|  |                    |   | Arabian Sea)        |   | 2 Glider Tracks)     |  |
|  +--------------------+   +---------------------+   +----------------------+  |
|             \                       |                      /                  |
|              +----------------------v---------------------+                   |
|                                     |                                         |
|                    Local React + Cesium.js Viewport                           |
+-------------------------------------------------------------------------------+

1. Simulated Model Output Feed: Host a local FastAPI server serving pre-processed NetCDF subsets (Copernicus GLORYS & INCOIS ROMS/MOM5 samples) covering the Bay of Bengal and Arabian Sea [ASSUMPTION].
2. Simulated In-situ FTP Feeds: Include 30 real historical Argo float profile JSONs from Ifremer FTP and 2 underwater Glider mission transects, pre-cached locally [ASSUMPTION].
3. Simulated Sensor Stream (ADCP/Mooring Plugin Demo): Provide a live "Simulate New In-Situ Feed" button in the admin interface that injects a newly generated CSV profile stream, proving the platform's extensible plugin architecture in real time [INFERENCE].
4. Transparency: State explicitly during judging: "Model fields and float profiles shown use cached authentic INCOIS/Copernicus NetCDF and Ifremer Argo files to guarantee 60 FPS performance without internet dependence." [INFERENCE]

18. Implementation Roadmap

Project Timeline (Targeting 30 September 2026)

2026-09-05              2026-09-12            2026-09-20          2026-09-26       2026-09-30
   |-----------------------|---------------------|-------------------|----------------|
 Phase 1: Data ETL & API  Phase 2: WebGL Core   Phase 3: In-situ    Phase 4: UI/UX   Phase 5: Demo
 & NetCDF Parsing         Raymarching Shader    Overlay & Charts    & Polishing      Submission

Phase 1: Data ETL & Backend API Setup (Days 1 - 7 | Target: Sept 12, 2026)

• Develop Python FastAPI backend with xarray and netCDF4 parsers [INFERENCE].
• Ingest sample ocean model NetCDF files (las.incois.gov.in / Copernicus) [PS].
• Implement Zarr chunking and 3D binary byte buffer serialization [INFERENCE].
• Parse Argo FTP and Glider NetCDF/ASCII files into GeoJSON profile endpoints [PS].

Phase 2: WebGL Core Volume Rendering (Days 8 - 15 | Target: Sept 20, 2026)

• Set up React + Vite frontend with Cesium.js 3D Virtual Globe [INFERENCE].
• Write GLSL WebGL2 volume raymarching shaders for 3D scalar fields ($T, S$) [INFERENCE].
• Implement dynamic depth slicing ($X-Z, Y-Z, X-Y$) and vertical exaggeration slider [PS].

Phase 3: In-situ Overlay & Interactivity (Days 16 - 21 | Target: Sept 26, 2026)

• Render Argo float markers and Glider 3D trajectory lines on Cesium globe [PS].
• Connect marker click events to Chart.js/Plotly.js depth-vs-variable profile popups [PS].
• Implement dynamic colorbar editor (palette, min/max, log/linear scale, opacity) [PS].

Phase 4: Plugin Architecture, Science Communication UX & Testing (Days 22 - 27 | Target: Sept 28, 2026)

• Build extensible sensor plugin adapter interface for new data streams [PS].
• Implement dual UX view: Operational Workbench vs. Public Outreach Mode [PS].
• Perform cross-browser performance testing and offline caching setup [INFERENCE].

Phase 5: Live Demo Preparation & Final Dossier (Days 28 - 30 | Target: Sept 30, 2026)

• Freeze code, assemble offline demo dataset, test live pitch presentation [INFERENCE].

19. Testing & Validation Plan

Test Category	Target / Metric	Test Procedure	Pass Criteria
Functional Rendering	3D Volumetric & Depth Slicing	Load 3D model NetCDF, apply depth slice plane at $100\text{m}, 500\text{m}, 1000\text{m}$.	Slice plane updates smoothly without visual tearing or mesh distortion.
Performance	WebGL Frame Rate	Measure FPS during rapid 3D camera rotation and volume slicing.	$\ge 45\text{ FPS}$ on integrated GPUs; $\ge 60\text{ FPS}$ on dedicated GPUs.
In-Situ Interaction	Marker Click & Chart Sync	Click Argo float marker #2901542 on 3D globe.	Popup chart opens in $< 200\text{ms}$ rendering complete $Z$-vs-$T/S$ profile curves.
Dynamic Shader Control	Colorbar & Range Stretch	Modify min/max temperature sliders from $10-30^\circ\text{C}$ to $15-22^\circ\text{C}$.	Shader lookup table updates color mapping instantly ($< 16\text{ms}$) without re-fetching data.
Extensibility	Sensor Plugin Ingestion	Submit sample ADCP ASCII text file to plugin API endpoint.	Backend auto-parses profile and frontend renders new vector markers without system restart.
Offline Resilience	Network Loss Behavior	Disconnect internet connection while exploring loaded 3D scene.	System displays offline banner; cached 3D volume and profile charts remain fully interactive.

20. Risk Register

Risk	Likelihood	Impact	Severity	Mitigation
WebGL GPU Shader Performance Drops on Low-End Laptops [INFERENCE]	Medium	High	High	Implement adaptive raymarching step size and automatic LOD resolution downsampling [INFERENCE].
Large NetCDF Data Streaming Latency Over Public Web [INFERENCE]	High	High	High	Convert NetCDF files to compressed Zarr chunks and byte-packed uint8 3D binary buffers [INFERENCE].
Disparity Between Horizontal Scale & Vertical Ocean Depth [KNOWN]	High	Medium	Medium	Provide real-time GPU vertical exaggeration slider ($1\times - 200\times$) [PS].
Heterogeneous In-situ File Formats (Argo vs. Glider vs. CTD) [KNOWN]	Medium	Medium	Medium	Build standard Python xarray abstraction layer that normalizes all formats to unified GeoJSON profile objects [INFERENCE].
Tight Hackathon Timeline (Build Window) [INFERENCE]	High	High	High	Strict MVP scoping: prioritize WebGL volume raycasting and Argo marker popups first [INFERENCE].

21. Cost & Scalability

Hackathon Phase

• Hosting & Compute: $0 (Local host / free tier Vercel frontend deployment + render.com / Railway backend API) [ASSUMPTION].
• Data Storage: $0 (Cached local NetCDF/Zarr files and open datasets) [ASSUMPTION].
• Third-Party Services: $0 (100% open-source software stack: CesiumJS, FastAPI, Chart.js) [ASSUMPTION].

Production Deployment (INCOIS Infrastructure)

• Compute Infrastructure: On-premise INCOIS Linux server cluster or Cloud Kubernetes (3 Nodes, 16 vCPU, 32GB RAM) [INFERENCE].
• GPU Server Acceleration: 1x NVIDIA T4 / A10 Tensor Core GPU instance for automated Zarr re-chunking and heavy 3D tile generation [INFERENCE].
• Storage Infrastructure: 10 TB NVMe SAN storage for rolling 3D model archives and historical Argo/Glider database [INFERENCE].
• Bandwidth & CDN: INCOIS NKN (National Knowledge Network) gigabit backbone with Cloudflare CDN for public outreach caching [INFERENCE].

22. Differentiation

Capability	Generic Hackathon Submissions	Proposed INCOIS Solution
Visual Scope	Static 2D map views (Leaflet / OpenLayers) with flat horizontal overlays.	True 3D Volumetric Water Column Raycasting + 3D Bathymetry on Virtual Globe [PS].
Data Integration	Model outputs and observational profiles displayed in separate web tabs.	Simultaneous Co-Display of 3D Model Fields & In-Situ Float/Glider Profiles in 1 Viewport [PS].
Extensibility	Hardcoded parsing scripts for specific sample NetCDF files.	Plugin-Style Adapter Architecture supporting ADCP, Moorings, HF-Radar & ML products [PS].
Performance	Downloads raw gigabyte NetCDF files to browser, causing client crashes.	Server-side Zarr chunking + WebGL byte-packed 3D textures for 60 FPS streaming [INFERENCE].
Target Audience	Single rigid dashboard UI.	Dual-Mode UX: Dense Operational Workbench for Forecasters + Storytelling Mode for Public Science Outreach [PS].

23. Future Scope

1. WebGPU Raytracing Engine Upgrade: Transition core GLSL volume shaders to WebGPU compute pipelines for hyper-realistic sub-surface light scattering and volumetric shadow rendering [RESEARCHED].
2. Real-Time HF-Radar & ADCP Vector Streaming: Connect live WebSocket feeds from coastal HF-Radar stations and moored ADCP arrays for real-time surface/sub-surface current vector fields [PS].
3. VR/AR Immersive Ocean Inspection: Support WebXR for immersive Virtual Reality headset tours through 3D ocean canyon currents and thermocline layers for public science museums [INFERENCE].
4. Automated ML Marine Heatwave & Upwelling Detection: Deploy deep learning models to automatically flag 3D marine heatwaves and upwelling zones with automated alerts sent to fishery advisories [PS].

24. Assumptions & Open Items Log

Consolidated Assumptions Log

• [ASSUMPTION-01]: React + Vite is selected as the frontend web application framework for rapid hackathon iteration.
• [ASSUMPTION-02]: Python FastAPI is selected for the backend microservice due to seamless C-bound xarray and netCDF4 integration.
• [ASSUMPTION-03]: Cesium World Terrain / Mapbox 3D Terrain Tiles serve as the default bathymetric surface model.
• [ASSUMPTION-04]: Hackathon demo will use a local pre-cached dataset covering the Bay of Bengal and Arabian Sea.
• [ASSUMPTION-05]: PostgreSQL with PostGIS extension will be used for indexing in-situ profile metadata.

Consolidated Open Items Log

• [NEEDS VALIDATION-01]: Exact INCOIS OPeNDAP server endpoint bandwidth limits and access permissions for real-time model streaming.
• [NEEDS VALIDATION-02]: Specific format variations in INCOIS underwater Glider ASCII log files versus standard IFREMER v2 NetCDF formats.
• [NEEDS VALIDATION-03]: Maximum hardware specification of operational workstations used by INCOIS duty forecasters.

Final Decision & System Summary

Final Recommendation

Build a web-native 3D ocean data visualization platform using React + Cesium.js on the frontend, powered by custom WebGL2 GLSL 3D volume raycasting shaders, and supported by a Python FastAPI backend with xarray, Zarr, and netCDF4. This architecture delivers true 3D volumetric rendering, depth slicing, dynamic colorbar controls, and co-display of Argo float and Glider profiles in a single interactive browser window without client dependencies [PS].

Recommended Stack

• Frontend: React, Vite, Cesium.js, WebGL2 GLSL Shaders, Chart.js / Plotly.js [ASSUMPTION].
• Backend: Python FastAPI, xarray, netCDF4, zarr, pandas [PS].
• Database / Cache: PostGIS, Redis [ASSUMPTION].
• Protocols: OGC WMS/WCS, OPeNDAP, REST, GeoJSON [PS].

Key Project Metrics

• Biggest Dependency: Availability of CF-compliant 3D ocean numerical model NetCDF files (INCOIS / Copernicus) [PS].
• Biggest Risk: Browser WebGL performance degradation when rendering high-resolution 3D volumetric textures on lower-end client hardware [INFERENCE].
• Biggest Technical Challenge: Writing performant WebGL2 GLSL raymarching shaders that accurately render 3D volume scalar fields while respecting geospatial bathymetric bounds [INFERENCE].

First 5 Actions for the Student Team

1. Download Sample Datasets: Obtain sample Indian Ocean 3D model NetCDF outputs from Copernicus (GLOBAL_MULTIYEAR_PHY_001_030) and Argo profile NetCDF files from Ifremer FTP [PS].
2. Setup FastAPI & xarray Prototype: Write a Python script using xarray to slice 3D NetCDF temperature arrays into 3D binary byte buffers and Zarr chunks [INFERENCE].
3. Initialize Cesium.js Viewport: Create a React + Vite project displaying the Cesium 3D virtual globe focused on the Indian Ocean / Exclusive Economic Zone [INFERENCE].
4. Implement WebGL2 Raycasting Shader: Develop a basic GLSL 3D volume raymarching shader bound to a 3D box Primitive inside Cesium.js [INFERENCE].
5. Build Marker & Profile Popup Component: Add GeoJSON markers for Argo floats on the globe and hook click events to Chart.js depth-vs-temperature line charts [INFERENCE].

Validation Before Coding

• Test xarray NetCDF parsing on sample files to verify coordinate names (depth, latitude, longitude, time, thetao) follow NetCDF CF-Conventions [INFERENCE].
• Verify target web browsers support WebGL2 texImage3D calls for 3D texture mapping [KNOWN].

Overall Assessment

Metric	Score / Value
Buildability Score	88 / 100 [INFERENCE]
Confidence Level	HIGH [INFERENCE]

Research Sources

1. INCOIS Live Access Server (LAS)

   • URL: https://las.incois.gov.in/ [PS]
   • Source Type: Official Government Portal (MoES / INCOIS) [1.1, 1.3]
   • Supported Claim: Serves numerical ocean model outputs (MOM5, GODAS, ROMS) and satellite data products via OPeNDAP and LAS [1.1, 1.3].
   • Reliability: High [1.1]

2. Copernicus Marine Service - Global Ocean Physics Reanalysis

   • URL: https://data.marine.copernicus.eu/product/GLOBAL_MULTIYEAR_PHY_001_030/description [PS]
   • Source Type: Official Data Repository (EU Copernicus Marine Service) [2.1]
   • Supported Claim: Provides 3D global ocean reanalysis (GLORYS12V1, $1/12^\circ$ horizontal resolution, 50 depth levels) for temperature, salinity, and current vectors [2.1].
   • Reliability: High [2.1]

3. Global Argo Data Assembly Centre (Ifremer FTP)

   • URL: ftp://ftp.ifremer.fr/ifremer/argo [PS]
   • Source Type: Official International Oceanographic Repository (Ifremer / Coriolis) [3.1]
   • Supported Claim: Hosts global Argo float profile datasets, metadata, and trajectory index files in CF-compliant NetCDF format [3.1].
   • Reliability: High [3.1]

4. Ifremer Glider Data Repository

   • URL: ftp://ftp.ifremer.fr/ifremer/glider/v2/ [PS]
   • Source Type: Official Data Repository (Ifremer) [3.1]
   • Supported Claim: Serves underwater glider vertical profile transect datasets in NetCDF/ASCII formats [3.1].
   • Reliability: High [3.1]

5. MDPI Applied Sciences / Web-based 3D Ocean Volume Rendering

   • URL: https://www.mdpi.com/2076-3417/15/5/2782 [RESEARCHED]
   • Source Type: Peer-Reviewed Scientific Journal Publication [4.1]
   • Supported Claim: Validates the feasibility of WebGL/WebGPU volume raycasting and 3D texture mapping for interactive web visualization of scalar ocean model fields [4.1, 4.11].
   • Reliability: High [4.1]