Water Level Satellite Platform: Matching Imagery to River Gauges
The "Level-Satellite" service tackles the challenge of selecting satellite images based on water levels at specific river gauges. Hydrologists often run into a mismatch: an image is available, but the water level at that time doesn't align with what they're analyzing. The platform filters Landsat and Sentinel-2 collections not just by date and cloud cover, but also by hydrological data from Russia's Federal Information System for State Water Register (AIS GMVO), delivering relevant scenes for analyzing river channels, floodplains, and inundation areas.
Prototype in Google Earth Engine: Early Limitations
The initial prototype was built in Google Earth Engine for one river basin district using AIS GMVO data. Filtering images by gauge geometry revealed issues: sluggish interface, slow collection processing, and quota exhaustion. Switching to preprocessing via the GEE API generated a lookup table (gauge, image ID, cloud cover), easing the load on the frontend.
However, this approach had drawbacks:
- Processing one district took 8–10 hours; for 20+ districts, it was impractical.
- Scaling required recalculation whenever new data was added.
- Errors at any step meant starting over from scratch.
Data Collection in Extreme Conditions
Access to AIS GMVO hydrological data was at risk of being cut off. The parser for bulk downloads was refined in the field—on a boat using AI. A successful download at 17:55 just before deadline secured a database of millions of observations. Data is now stored locally, eliminating reliance on external sources.
Shift to STAC and Microsoft Planetary Computer
The key upgrade was adopting the STAC standard for cataloging satellite scenes and Microsoft Planetary Computer (MPC) for API access. STAC standardizes metadata across collections, enabling searches by geometry and time regardless of provider.
Architecture simplified to:
- Database of gauges and observations.
- Filter by water level, period, cloud cover.
- Search scenes in MPC by metadata.
- Load images on demand.
This eliminated heavy collection filtering, delivering blazing speed.
Database Architecture
Switching from CSV/Excel to PostgreSQL with PostGIS handled 28 million observations. The core entity links "hydro observation → date → satellite scene." Queries now run in milliseconds: hydrological filter first, then scene search, then loading.
The DB features tables for:
- Gauges (coordinates, geometry).
- Observations (level, discharge, date).
- Scene metadata (ID, cloud cover, dataset).
Indexes on dates and geometry speed up JOINs.
Current Implementation and Tech Stack
Users select a gauge, water level range, period, and filters—the service returns scenes on a map with export options. Leaflet.js powers the map, Chart.js handles hydrographs.
Tech stack:
| Layer | Technologies |
|-------|--------------|
| Backend | Python, Flask, Gunicorn |
| Database | PostgreSQL, PostGIS (28M records) |
| Satellite Data | Microsoft Planetary Computer |
| Frontend | Leaflet.js, Chart.js |
| Infra | Docker, nginx, HTTPS |
Service live at level-satellite.ru, repo: github.com/ruorv/level-satellite-public.
Key Takeaways
- Image selection ties directly to actual water levels, avoiding incomparable data.
- STAC/MPC provides flexible access without GEE quotas.
- PostGIS accelerates spatial queries on massive datasets.
- Scalable architecture: add gauges/data without full rebuilds.
- Open-source code for community contributions.
— Editorial Team
No comments yet.