Draft Proposal

EE 547: Applied and Cloud Computing for Electrical Engineers

Team Members: [Name 1, Name 2, Name 3]

Idea 1: Irrigation Advisor for Small Farms

Summary

An application that predicts soil moisture levels for a user’s land and recommends when to irrigate. Users register fields by location and crop type, view current and forecasted soil conditions, and receive alerts when irrigation is recommended.

Problem and Application

Small-scale farmers and gardeners make irrigation decisions based on instinct or fixed schedules, which leads to over- or under-watering. This application lets users define fields by drawing a boundary on a map or entering coordinates, select their crop type, and view a dashboard showing estimated soil moisture, recent rainfall, and a forecast for the next several days. Users configure alert thresholds per field and receive notifications when conditions indicate irrigation is needed. The system also displays satellite imagery of the user’s area so they can visually track vegetation health over time.

Technical Sketch

A web frontend provides the map interface for field registration and displays the moisture dashboard and satellite imagery. Background workers run on a schedule to fetch new weather forecasts and satellite data for all registered fields. An ML model estimates current soil moisture and predicts moisture levels over the coming days from weather history, forecast data, crop type, and soil characteristics. The API serves field data, moisture estimates, predictions, and alert configuration. A database stores user accounts, field definitions, weather and moisture history, and alert preferences.

Data Sources

Weather observations and forecasts from the Open-Meteo API (free, no key required, hourly resolution, global coverage).
Soil properties (type, drainage class) from the USDA SSURGO database via the SoilGrids REST API (free, global coverage at 250m resolution).
Satellite vegetation index (NDVI) imagery from the Copernicus Sentinel-2 API (free with registration, updated every 5 days, 10m resolution).
Evapotranspiration reference data derived from weather variables using the FAO Penman-Monteith equation — computed from the weather data already being collected.

Idea 2: [Title]

Summary

Describe the application in 2-3 sentences: what it does, who would use it, and what domain it belongs to.

State what the application is, not why it’s important
Be specific enough that someone can picture using it
Avoid “helps users” or “enables” — say what it actually does

Problem and Application

Describe what the user can do with this application. Focus on concrete functionality.

Name specific actions: “users upload X, browse Y, receive Z” — not “users can interact with data”
If you can’t describe three distinct things a user does, the application may be too thin
Avoid justifying why the problem matters — just describe what the system does about it

Technical Sketch

Describe the major components of your system and what role each one plays.

Identify what handles user interaction, what processes data in the background, and where ML fits in
Describe components by their role (“a background worker polls external data”) not by technology (“a Celery task running on EC2 with SQS”)
You will specify technologies in the revised proposal — here, focus on what each piece does and how they relate
If your sketch has only one component (an API that does everything), you are missing the asynchronous/distributed aspects of the project requirements

Data Sources

Name the specific data your application needs and where it comes from.

If using an external API: name it, confirm it exists, and note access constraints (rate limits, authentication, free tier limits, terms of use)
If using a public dataset: link to it and note its size, format, and update frequency
If relying on user-generated data: describe what users provide and whether the application is useful before users contribute (cold start)
“Various APIs” or “publicly available data” is not a data source — name it or you haven’t verified it