EARTH- Planetary Intelligence Platform

"Earth" is an AI-powered planetary intelligence platform that fuses satellite, ocean, and atmospheric data to predict environmental disasters and protect critical infrastructure in real-time.

Comment

ARTIFICIAL INTELLIGENCE, SUSTAINABILITY AND CLIMATE INNOVATION

Inspiration

Our story began with a terrifying realization: we are drowning in data, but starving for wisdom.

We watched as friends in rural communities lost entire harvest seasons to "unexpected" soil saturation, and urban commuters found themselves trapped by flash floods that standard weather apps merely described as "heavy rain." The problem wasn't a lack of satellites; it was a lack of translation. To a meteorologist, "100mm of rain" is a data point. To a farmer, it's a destroyed livelihood. To a city planner, it's a grid failure.

We realized that while billion-dollar satellites constantly monitor our planet, the people on the ground are still "blind" to the real risks. We built EARTH to close this deadly gap. We wanted to create a system that doesn't just display the weather, but understands it living the planet a voice to warn us before the disaster strikes. Our mission was to democratize safety, ensuring that the most advanced planetary intelligence isn't just for governments, but for everyone.

What it does

EARTH is a Planetary Intelligence Platform that serves as a centralized "Situation Room" for environmental safety. Instead of simply displaying raw weather data, it uses AI to fuse atmospheric, oceanographic, and satellite information into actionable risk assessments, helping users understand not just what the weather is, but how it will impact their lives.

It operates on three critical levels to transform raw data into survival intelligence:

  1. Real-Time Infrastructure Protection (The Oracle) EARTH acts as a digital guardian for physical systems. We developed a proprietary logic engine that translates complex meteorological data into real-world impacts.

    • Power Grid Sentinel: It predicts grid stress and blackout risks by analyzing high wind speeds (>50km/h) combined with extreme heatwaves, warning utility managers before lines go down.
    • Road Network Monitor: It warns of "Mud Hazards" and flash floods by correlating rainfall forecasts with deep-soil moisture saturation levels, preventing vehicles from driving into washout zones.
    • Communication Shield: It monitors Space Weather (solar flare activity) to predict when geomagnetic storms might disrupt GPS navigation and radio signals.

  2. Multidomain Environmental Monitoring The platform breaks down scientific silos by aggregating four distinct domains into a single, unified dashboard:

    • Ocean Intelligence: Automatically calculates "Sea State" safety for coastal communities using wave height and period physics.
    • Biodiversity & Land: Leverages Google Earth Engine to process satellite imagery, calculating Vegetation Health Indices (VHI) to detect drought stress weeks before crops fail.
    • Space Weather: Tracks solar activity to protect modern technology from invisible geomagnetic threats.

  3. The "Ark Protocol" (Resilient Early Warning) Recognizing that internet access is often the first casualty of a disaster, EARTH features a "Dead Man's Switch."

    • When the system's AI detects a critical risk probability (e.g., Flood Probability > 80%), it automatically bypasses the visual dashboard.
    • It triggers the Ark Protocol, sending low-bandwidth SMS alerts to registered phones. This ensures that the "Digital Divide" does not become a death sentence, delivering life-saving warnings to offline communities when they need it most.

What makes EARTH unique?

In a market crowded with standard weather apps and passive monitoring tools, EARTH stands alone as an Active Planetary Defense System. We don't just show you the data; we tell you what it means for your survival.

Here is how we compare to industry standards and why EARTH is the superior solution:

1. Action vs. Observation (The "So What?" Factor)

  • Industry Standard (The Problem): Traditional apps like AccuWeather or Windy display raw numbers: "Wind: 40km/h" or "Rain: 20mm." They leave the user to guess the impact.
  • The EARTH Advantage: We bridge the "Cognitive Gap." Our Infrastructure Oracle translates raw data into physical risks. We don't just say "40km/h wind"; we say "Power Grid Stress Warning: High probability of line failure." We answer the question, "So what?" before the user even asks.

2. The "Ark Protocol" (Offline Equity)

  • Industry Standard (The Problem): Most disaster management platforms rely heavily on high-speed internet (4G/5G). When a hurricane knocks out cell towers, these apps become useless blank screens.
  • The EARTH Advantage: We built for the worst-case scenario. Our proprietary Ark Protocol acts as a "Dead Man's Switch." If the internet fails, EARTH autonomously downgrades to SMS-based alerts, ensuring that life-saving warnings reach even the most remote, offline communities on basic feature phones.

3. True Data Fusion (Breaking Silos)

  • Industry Standard (The Problem): Currently, a user needs four different apps to stay safe: one for weather, one for marine tides, one for earthquake/land data, and one for solar storms.
  • The EARTH Advantage: We are a Unified Intelligence Platform. We fuse four distinct scientific domains—Atmospheric, Oceanographic, Terrestrial (Google Earth Engine), and Space Weather—into a single "Planetary Status" score. We recognize that these systems are interconnected (e.g., high tides + heavy rain = flash floods), and our logic engine analyzes these correlations in real-time.

4. Defensive Engineering (Null-Safe Logic)

  • Industry Standard (The Problem): Many hackathon projects and prototypes crash when external APIs fail or return missing data, rendering them unreliable in a real crisis.
  • The EARTH Advantage: We engineered EARTH with Defensive Logic. Our system is "Null-Safe," meaning it uses historical caching and fallback algorithms to remain operational even if satellites go offline or sensors fail. Reliability is our core feature.

How we built it

We approached the development of EARTH not just as a web app, but as a mission-critical system of systems. Our goal was to create a platform that is lightweight, resilient, and intelligent. We achieved this through a Microservices-First Architecture divided into three distinct layers:

1. The Intelligence Layer (Python & FastAPI)

The core "brain" of EARTH is built on Python 3.11 using the FastAPI framework. We chose this stack for its high-performance asynchronous capabilities (asyncio), which allow the platform to fetch data from multiple planetary sources simultaneously without blocking the user interface.

  • Data Fusion Engine: We wrote custom services (open_meteo.py and marine.py) that act as adaptors. They ingest raw JSON data—atmospheric pressure, soil moisture, wave height—and normalize it into a unified "Planetary State" object.
  • The Logic Oracle: Instead of using a black-box AI model, we engineered a deterministic logic layer (infra.py). This module uses conditional algorithms to cross-reference meteorological thresholds (e.g., Wind > 50km/h) against infrastructure resilience curves, allowing us to mathematically predict grid stress or road hazards with precision.
  • Resilience Caching: We implemented a "Smart Cache" mechanism. If external satellite APIs fail or timeout (a common scenario in disasters), our backend automatically serves the last known valid dataset from a local JSON store, ensuring the dashboard never goes blank.

2. The Planetary Data Grid (Google Ecosystem)

We leveraged the power of Google’s ecosystem to handle heavy computation and security:

  • Google Earth Engine (GEE): We integrated the GEE Python API to offload the processing of petabytes of Sentinel-2 satellite imagery. By calculating the Vegetation Health Index (VHI) on Google’s cloud servers and only fetching the lightweight analysis results, we kept our application incredibly fast.
  • Google Charts: We utilized the Visualization API to render our "Neon" risk forecasts. We customized the area charts with transparency and gradients to visualize trend lines for flood and drought risks over a 7-day period.
  • Firebase Authentication: To ensure security without managing a complex database, we implemented Firebase Auth. This handles user identity via Google Sign-In, securing our API endpoints so only verified users can access the "Situation Room."

3. The "Command Console" Frontend (Vanilla JS & HTML5)

For the user interface, we rejected heavy frameworks like React or Angular in favor of Vanilla JavaScript (ES6+) and optimized HTML5/CSS3.

  • Why? In a disaster zone with 2G/3G connectivity, every kilobyte counts. Our dashboard is extremely lightweight, loading instantly even on unstable connections.
  • SpaceX-Inspired UI: We designed a "Dark Mode" interface using the Inter font family (via Google Fonts) and Material Icons. This high-contrast aesthetic is designed to be readable in low-light environments (e.g., during a power outage) and reduces battery consumption on OLED screens.

4. The "Ark Protocol" (Offline Resilience)

Finally, we built the "Ark Protocol" directly into the backend logic. We created a conditional trigger that constantly monitors the aggregated risk score. If the probability of a life-threatening event (like a flood) exceeds 80%, the system bypasses the frontend entirely and is architected to push a text-only payload to an SMS gateway. This ensures that the "Digital Divide" does not become a death sentence—delivering alerts to basic feature phones when the internet is down.

Challenges we ran into

Building EARTH wasn't just about writing code; it was about taming the chaos of the real world. We moved fast, broke things, and had to rebuild them stronger. Here are the specific hurdles we faced:

1. The "Null Data" Crash (Handling Real-World Imperfection) Our biggest headache came from the unpredictable nature of live environmental APIs. Initially, our Infrastructure Oracle assumed that weather sensors would always return perfect numbers. However, during a critical test, we hit a TypeError: '>' not supported between instances of 'NoneType' and 'float'.

  • The Reality: Real-world sensors often go offline or return "null" for specific regions (like missing soil moisture readings in remote areas).
  • The Fix: We had to rewrite our entire risk logic engine (infra.py) to be "Null-Safe." We implemented a robust fallback system that treats missing data as "0" (Safe) or serves the last known valid cache, preventing the entire platform from crashing just because one sensor is down.

2. The 10-Second Timeout Wall We wanted EARTH to be a "System of Systems," fetching atmospheric, ocean, and flood data simultaneously. But this ambition caused a bottleneck. Our backend frequently hit httpx.ConnectTimeout errors because we were trying to pull too much heavy data across slow connections within a tight window.

  • The Reality: The server would hang and eventually throw a 500 Internal Server Error, leaving the user with a blank screen.
  • The Fix: We abandoned sequential processing and implemented Asynchronous Parallel Fetching. This allowed the system to grab Ocean, Air, and Soil data at the exact same time, reducing load times by 60% and solving the timeout crisis.

3. Wrangling Satellite Data (The Deprecation Trap) Integrating Google Earth Engine was our most ambitious technical feat, but it came with a curveball. We initially built our vegetation analysis on the COPERNICUS/S2_SR dataset, only to find our logs flooded with deprecation warnings and "Band Mismatch" errors mid-development.

  • The Reality: The satellite dataset we targeted had been superseded, breaking our vegetation math.
  • The Fix: We had to rapidly migrate our pipeline to the newer COPERNICUS/S2_SR_HARMONIZED collection. We recalibrated our band selection logic to ensure the Vegetation Health Index (VHI) remained accurate and future-proof.

4. The "Async Race" on the Frontend We built a lightweight Vanilla JS frontend to keep the app fast, but this created a "Race Condition." The dashboard would sometimes try to request private user data before Firebase had finished confirming who the user was, leading to 401 Unauthorized errors.

  • The Reality: The code was running faster than the authentication handshake.
  • The Fix: We implemented a whenAuthReady Promise structure in our app.js. This acts as a digital gatekeeper, pausing all network requests until the secure "handshake" with Google Identity is fully complete, ensuring a seamless user experience every time.

What we learned

Building EARTH was more than just a coding exercise; it was a transition from writing scripts to engineering a life-saving system. Here is what we learned during this journey:

1. The Real World is "Noisy" (Defensive Engineering) My biggest technical takeaway is that real-world data is never perfect. When our logic engine crashed because of a NoneType error from a missing sensor, I learned that relying on "happy path" scenarios is dangerous.

  • The Lesson: I learned the art of Defensive Programming. I can no longer assume an API will always return a number; I must build "Safety Nets" (fallbacks and null-checks) into every logic block. Reliability is not about the code working when things go right, but the code staying up when external sensors fail.

2. Asynchronous Orchestration is a Superpower Initially, I thought Python ran line-by-line. Facing the httpx timeout errors taught me the power—and complexity—of Asynchronous Programming.

  • The Lesson: I learned how to orchestrate a digital symphony. By fetching Ocean, Air, and Soil data simultaneously rather than sequentially, I realized that high-performance engineering isn't just about writing fast code; it's about efficient concurrency—doing more with the same amount of time.

3. Simplicity is a Feature, Not a Compromise In a world obsessed with heavy frameworks, I chose Vanilla JavaScript for the frontend.

  • The Lesson: I learned that Constraint Breeds Creativity. By stripping away heavy libraries, I was forced to understand the raw DOM and event loops. I learned that for a disaster-response tool, "loading speed" is a feature as critical as the data itself. A beautiful app that takes 10 seconds to load on a 2G network is useless in a crisis.

4. The "Action Gap" (Technology vs. Humanity) Perhaps the most profound lesson was philosophical. I realized that having terabytes of satellite data means nothing if it doesn't reach the person in danger.

  • The Lesson: Building the Ark Protocol taught me that my job as a developer isn't just to display data; it is to bridge the gap between complex science and human survival. I learned to prioritize Impact over Information—shifting from "Here is the rain forecast" to "Evacuate now."

5. Adaptation is Key When the Google Earth Engine dataset was deprecated mid-project, I didn't panic; I adapted.

  • The Lesson: I learned that software is a living organism. Technologies die and evolve. Being a great engineer isn't about knowing everything; it's about how fast you can unlearn the old and implement the new.

Accomplishments that we're proud of

Engineering the "Planetary Data Fusion" I are incredibly proud of successfully architecting a backend that harmonizes four distinct scientific domains into a single "source of truth." It was a significant challenge to synchronize asynchronous data streams—balancing ocean wave physics, atmospheric models, and space weather data without crushing the server. Overcoming the initial API timeout bottlenecks to create a system that fuses these global datasets and outputs a coherent, unified risk score in milliseconds is a major architectural victory for our team.

The "Ark Protocol" & Offline Equity In an industry obsessed with 5G and high-speed data, I are proud that I had the foresight to build for the "offline" reality of disaster zones. Developing the Ark Protocol our "Dead Man's Switch" that bypasses the visual dashboard to trigger low-bandwidth SMS alerts was a defining moment. It proves that I didn't just build an app for tech-savvy urbanites; I built a resilience tool capable of serving the most vulnerable communities when internet infrastructure collapses.

Taming Google Earth Engine From a technical standpoint, I take pride in successfully integrating Google Earth Engine to process live satellite imagery. This was our steepest learning curve. I moved beyond simple API calls to handling complex band math and successfully navigating the migration to the "Harmonized" Sentinel-2 dataset. Delivering a live Vegetation Health Index (VHI) to a mobile dashboard proves that Ican democratize access to petabytes of scientific data that is usually locked away in research labs.

The "Null-Safe" Infrastructure Oracle Finally, I are proud of the resilience of our code itself. Transitioning from "happy path" coding to defensive engineering was a crucial accomplishment. I successfully built a "Null-Safe" logic engine that can withstand real-world sensor failures—meaning if one data source goes dark, our platform doesn't crash. Seeing our "Infrastructure Oracle" correctly interpret raw wind data to flag a specific "Power Grid Stress" warning during simulations was the moment I knew I had moved beyond a simple weather app and built a true intelligence platform.

What's next for EARTH

We have built the prototype; now we build the future. Our roadmap focuses on evolving EARTH from a passive monitoring tool into an active planetary defense system.

1. Integration of Gemini AI (The "True" Narrator) Currently, our "AI Narrator" uses logic-based templates to give advice.

  • The Vision: We will integrate the Google Gemini Pro API directly into the backend.
  • The Impact: Instead of generic alerts, Gemini will analyze the user's specific location, housing type, and demographics to generate hyper-personalized survival guides (e.g., "Ian, wind speeds are 80km/h. Your roof type is vulnerable. Secure loose panels and move your vehicle inside.").

2. From APIs to IoT (The "Ground Truth" Network) Right now, we rely on third-party satellite data, which can have a lag.

  • The Vision: We plan to deploy low-cost, open-source IoT Sensors (ESP32-based) for hyper-local data collection.
  • The Impact: These "EARTH Nodes" will measure soil moisture and air quality at the village level, feeding "Ground Truth" data back into our system to calibrate satellite models in real-time.

3. The "Ark" Hardware (LoRaWAN Mesh) The current Ark Protocol relies on SMS (GSM towers). But what if the towers fall?

  • The Vision: We are designing a physical "Ark Box"—a standalone device using LoRaWAN (Long Range Radio) technology.
  • The Impact: This will allow EARTH to transmit emergency signals between devices over kilometers without needing any cellular network or internet, creating a decentralized "mesh network" for disaster communication.

4. Machine Learning for Predictive Disasters Our current infra.py uses hard-coded thresholds (e.g., If Wind > 50km/h).

  • The Vision: We will implement TensorFlow models to analyze historical environmental patterns.
  • The Impact: Instead of reacting to a flood, the system will learn to predict it 48 hours in advance by recognizing complex correlations between soil saturation trends, tide levels, and atmospheric pressure that a human might miss.

5. Enterprise & Government API Disaster resilience is valuable.

  • The Vision: We plan to expose our "Infrastructure Oracle" as a commercial API.
  • The Impact: Insurance companies, logistics firms, and local governments could subscribe to our "Risk Score" endpoints to automate their own safety protocols (e.g., smart power grids that automatically shut down before a storm hits).
Share this project:

Updates