Add Applications section with Ag Forecasting API docs

Author: mariaob1201

_toc.yml

@@ -4,4 +4,8 @@
 format: jb-book
 root: index
 chapters:
-  - file: worker
+  - file: worker
+  - file: applications/index
+    title: Applications
+    sections:
+      - file: applications/ag-forecasting-api

applications/ag-forecasting-api.md

@@ -0,0 +1,145 @@
+# 🌾 Agricultural Forecasting API
+
+FastAPI-based service for **crop disease risk forecasting** and **winter rye biomass estimation** using multi-source weather data.  
+Developed by the University of Wisconsin–Madison Data Science Institute.
+
+---
+
+## Overview
+
+The API provides geospatial agricultural intelligence for Wisconsin, combining weather data with validated agronomic models.
+
+### Key Features
+- 🌽 Crop disease risk forecasting (corn & soybean)
+- 🌱 Winter rye biomass estimation
+- 🌦 Multi-source weather integration (IBM EIS, WiscoNet, NOAA)
+- 📍 Coordinate and station-based queries
+- 🗺 GeoJSON outputs for GIS applications
+- ⚡ Async batch processing for multi-station analysis
+
+---
+
+## System Architecture
+
+The system is structured into four main layers:
+
+- **API Layer (FastAPI)**  
+  Handles incoming requests and routing (`/ibm`, `/wisconet_g`, `/models`)
+
+- **Data Layer**  
+  - IBM EIS: high-resolution global weather API  
+  - WiscoNet: Wisconsin mesonet station network  
+
+- **Processing Layer**  
+  Weather normalization, unit conversion, GDD calculation, rolling features
+
+- **Model Layer**  
+  Disease risk models and winter rye biomass model
+
+---
+
+## Core Modules
+
+- Weather ingestion (IBM + WiscoNet)
+- Disease risk modeling
+- Winter rye biomass estimation
+- Async pipeline orchestration
+- GeoJSON response formatting
+
+---
+
+## API Endpoints
+
+### IBM Forecasting (Coordinates)
+`GET /v2/ag_models_wrappers/ibm`
+
+Returns disease risk + biomass using IBM weather data.
+
+---
+
+### WiscoNet Forecasting (Stations)
+`GET /v2/ag_models_wrappers/wisconet_g`
+
+Returns station-based time-series disease risk and biomass.
+
+---
+
+### Model Metadata
+`GET /v2/ag_models_wrappers/models`
+
+Returns available disease and biomass models.
+
+---
+
+## Disease Models
+
+- **Tarspot (corn)** – humidity and temperature-based risk
+- **Gray Leaf Spot (corn)** – temperature + dew point model
+- **Frogeye Leaf Spot (soybean)** – GDD + rainfall model
+- **White Mold (soybean)** – precipitation and soil moisture model
+
+---
+
+## Winter Rye Biomass Model
+
+Predicts dry biomass (lb/acre) using:
+
+- Growing Degree Days (0°C base)
+- Planting date (day-of-year)
+- Fall precipitation
+- Logistic growth curve
+
+### Outputs
+- Biomass (lb/acre)
+- Color class (gray / yellow / green)
+- Interpretation message
+
+---
+
+## Data Sources
+
+### IBM Environmental Intelligence Suite (EIS)
+- High-resolution global weather data
+- Hourly forecasts and historical data
+- Requires authentication
+
+### WiscoNet
+- Wisconsin mesonet (~100 stations)
+- Daily weather observations
+- Public API access
+
+---
+
+## Response Format
+
+All outputs are returned as **GeoJSON FeatureCollections**, including:
+
+- Weather variables
+- Disease risk scores
+- Biomass predictions
+- Station metadata
+
+---
+
+## Performance Features
+
+- Async multi-station processing
+- Cached weather and station data (6h–7d TTL)
+- Parallel risk computation
+- Optimized data aggregation pipeline
+
+---
+
+## Setup
+
+```bash
+git clone <repo>
+cd ag_forecasting_api
+
+python -m venv .venv
+source .venv/bin/activate
+
+pip install -r requirements.txt
+
+uvicorn app:app --reload
+```

applications/index.md

@@ -0,0 +1,14 @@
+# Applications
+
+We are building OL to support a wide range of applications with minimal changes required from those applications. Our approach is to port more real-world workloads and let their needs drive incremental improvements to the platform.
+
+## Want to deploy FastAPI apps on OpenLambda?  Just ASGI us how.
+
+In this post, we look at an agricultural forecasting application and an ASGI-based web service. The ag app is a natural fit for serverless because it is fundamentally stateless: results can be regenerated on demand from underlying data rather than relying on persistent runtime state. This also influenced the choice of FastAPI for a modern, async-friendly interface.
+To situate ASGI, it builds on the long history of WSGI-based Python web serving, where earlier work (including Jaime’s contributions) helped shape synchronous server patterns. ASGI extends this model with native async support, enabling higher concurrency and better I/O utilization, but requiring deeper runtime integration.
+A broader design question is whether it is beneficial to consolidate multiple functions into a single Lambda-like unit. We believe it is: co-locating functions enables opportunistic state reuse, faster warm starts, and reduced overhead.
+On the implementation side, OL removes its dependency on Tornado and adds optional support for both WSGI and ASGI applications. The ag forecasting app also surfaced practical issues, including /dev/shm constraints when using process pools, which required targeted adjustments.
+Looking ahead, improved visibility into execution—such as detecting when applications are blocked on I/O—opens the door to new billing models that distinguish compute from idle waiting time, addressing a longstanding serverless concern.
+More broadly, expanding the set of supported applications continues to drive OL’s evolution, alongside features like environment variables and GitHub-based deployments that further reduce friction for onboarding new workloads.
+
+- [Ag Forecasting API](ag-forecasting-api.md)