ZiwaVision: Uncertainty-Aware Satellite Inspection for Lake Victoria

Turning satellite imagery into reviewable observations through OpenCV 5, active inspection and human oversight.

Inspiration

ZiwaVision grew out of my work on ZiwaClear, an environmental initiative addressing water hyacinth on Lake Victoria and helping connect hotspot information with community-based removal and downstream utilisation.

Field conversations challenged one of my early assumptions: hyacinth does not necessarily remain in the same place or affect every landing site continuously. Some locations appeared relatively clear, while fishermen described periods when floating vegetation obstructed boat launches and then moved away. That made reliable, location-specific observation more important than simply assuming a persistent infestation.

I also wanted to understand how computer vision could contribute to environmental monitoring without presenting uncertain predictions as established facts. Research from the Kenya Marine and Fisheries Research Institute (KMFRI) introduced me to Sentinel-1-based approaches, prompting me to explore radar imagery alongside the more familiar optical satellite workflow.

ZiwaVision is my attempt to turn that exploration into an inspectable technical system while learning how existing research and monitoring efforts could inform its future development. It is designed to complement, not replace, scientific monitoring, institutional expertise or observations from affected communities.

What it does

ZiwaVision is a prototype for satellite-based environmental inspection. It retrieves satellite scene information, applies an OpenCV 5 vision pipeline to identify candidate vegetation patches within a defined monitoring area, and exposes the resulting observations through an API and a dashboard.

Its focus is not simply generating detections. It is also deciding when a result is too uncertain to trust automatically.

The current prototype supports:

  • Sentinel-2 Level-2A scene discovery through the Earth Search STAC catalogue.
  • OpenCV 5 processing to generate candidate vegetation regions within a spatially constrained area.
  • Candidate inspection and alternative-segmentation comparison.
  • Human-review requests when visual evidence is inconsistent.
  • API endpoints for retrieving inspection results, checking run status and recording eligible review decisions.
  • Persisted run and verification traces intended to make inspection decisions more observable and auditable.

A candidate is not a confirmed water-hyacinth detection. Vegetation signals alone cannot reliably establish the species, and the prototype is not yet a lake-wide operational monitoring service.

How I built it

1. Satellite data discovery

I used the Earth Search STAC API to discover Sentinel-2 Level-2A scenes covering a small study area around Dunga Beach and the Winam Gulf. The initial evaluation examined 12 retrieved scenes from July to September 2026.

Starting with a defined study area helped me inspect individual results, investigate failures and avoid making broad claims about the entire lake from a limited sample.

2. OpenCV 5 vision pipeline

The processing pipeline uses OpenCV 5 to work with image-derived vegetation candidates and spatial masks. A geographic constraint helps keep analysis within the intended monitoring domain instead of treating every green region in a satellite image as a relevant hotspot.

This constraint matters because shoreline vegetation, mixed pixels and connected land-water boundaries can distort the apparent size of a candidate. The pipeline therefore needs to treat candidate area and confidence as measurements requiring scrutiny, not proof of invasive-species presence.

The project uses opencv-python==5.0.0.93. The technical report documents the processing workflow, dependencies and reproducibility instructions.

3. Active inspection and human oversight

The most important design decision was to make uncertainty affect the system's next action.

The Active Inspector compares alternative segmentation results. When the resulting masks disagree substantially, the system can request human verification rather than automatically treating the candidate as reliable.

The intended workflow is:

Inspect imagery → generate candidate → compare visual evidence → evaluate uncertainty → accept, reject or request human review → record the decision.

This is the Agentic Vision aspect of ZiwaVision: visual evidence affects the inspection decision and whether human approval is requested. The current approach is an explicit, rule-driven inspection workflow; I do not claim that a general-purpose LLM agent or MCP integration has been implemented.

The application also restricts review transitions. Only eligible candidates can be verified or rejected; invalid decisions are rejected, repeated final decisions are handled idempotently, and changing a final decision requires an explicit re-review request.

4. API, dashboard and cloud architecture

The project includes a Python API and a React dashboard. The API supports hotspot retrieval, inspection details, run-status polling and verification workflows. The dashboard presents observations for inspection rather than requiring users to interpret raw satellite files directly.

The backend is packaged for a container-based AWS Lambda deployment, with S3-backed persistence configured for results, traces and run records. The deployment configuration specifies a Python 3.12 Lambda container, 1,024 MB of memory and a 300-second timeout.

The final submission will document the actual deployed AWS resources and configuration and link to the working endpoint after a successful deployment smoke test. The architecture and deployment claims should be read alongside that verified evidence.

Evaluation: what the data showed

The initial evaluation was deliberately limited to a small set of scenes from the Dunga Beach/Winam Gulf study area.

Most of the 12 Sentinel-2 scenes produced no candidate detections. That is an observation about this dataset, area and pipeline, not evidence that water hyacinth is absent from Lake Victoria. A zero-candidate result may reflect genuinely clear imagery, limitations of the method or conditions that require further investigation.

One inspection from 23 August 2026 demonstrated why uncertainty handling matters. Alternative segmentation outputs contained 405 pixels and 57 pixels respectively, with an intersection-over-union (IoU) of approximately 0.141. The disagreement prompted a human-verification request rather than an unqualified detection claim.

This example also exposed the difficulty of interpreting connected vegetation regions near shorelines. A large connected component can include areas outside a conservative open-water core; its measured area should not automatically be interpreted as confirmed hyacinth coverage.

Other cases tested the system's ability to communicate uncertainty and failure explicitly:

  • 12 September 2026: a scene produced no candidates under the evaluated pipeline.
  • 29 August 2026: no scene was available for the requested inspection, so the system recorded a failure rather than substituting fabricated detections.
  • Segmentation disagreement: the alternative masks differed substantially, triggering review instead of silent acceptance.

The software verification results provide a separate measure of engineering reliability: the API test suite reported 74 passing tests, and six fault-injection checks passed. The dashboard production build and Python compilation checks also succeeded. These are software and workflow checks, not a measurement of water-hyacinth detection accuracy. Establishing accuracy will require independently labelled reference data and a suitably designed evaluation.

Exploring Sentinel-1

The KMFRI research that motivated my exploration of radar imagery also helped clarify what this prototype has not yet achieved.

I discovered 29 Sentinel-1 scene records for the July–September 2026 period and successfully read small VV/VH data windows. However, the files explored so far are uncalibrated Level-1 GRD products and have not completed the radiometric-calibration and terrain-correction workflow needed for defensible downstream analysis.

I therefore do not present these exploratory radar reads as validated Sentinel-1 water-hyacinth detections. They establish a direction for further work, not a completed detection capability.

Challenges and lessons learned

This project required me to learn OpenCV 5 while confronting the difference between a functioning software pipeline and a trustworthy environmental observation.

One important debugging lesson came from discovering that previous dashboard results included fixture data. I tightened the separation between sample fixtures and retrieved observations, regenerated the results from real scene retrievals, and added checks to prevent sample detections from being mistaken for real satellite findings.

I also learned that uncertainty needs to be visible throughout the system. A candidate with conflicting masks, an unavailable satellite scene and a scene with no candidates are three different outcomes; collapsing them into a single empty map would hide important information.

Cloud deployment has been another learning curve. I am more accustomed to platforms such as Render and Railway, and adapting the application to an AWS-oriented container and serverless architecture introduced additional operational considerations. It felt like moving from tic-tac-toe to chess.That work has reinforced the importance of documenting deployment configuration and verifying behaviour in the actual target environment.

What makes the approach useful

ZiwaVision is not built on the claim that existing water-hyacinth monitoring is inadequate or that this prototype already outperforms established systems.

Its contribution is an inspectable workflow that brings together satellite-scene discovery, OpenCV 5 candidate generation, spatial constraints, uncertainty checks, explicit human-review decisions and traceable API operations.

That approach is useful to investigate because environmental monitoring is not just a detection problem. People also need to know what was observed, what the system could not establish, when a result needs review and how the decision was reached.

What comes next

The next phase is about validation and collaboration, not simply adding more features.

  1. Compare against existing work. Review relevant KMFRI research and other established monitoring approaches, identify compatible reference products, and investigate whether comparisons or data access can be arranged with the appropriate institutions.
  2. Validate with independent observations. Engage relevant researchers, environmental and fisheries authorities, county stakeholders and Beach Management Units to explore field-reference data and appropriate validation protocols, subject to their agreement.
  3. Develop a defensible Sentinel-1 pipeline. Complete the necessary preprocessing, test candidate methods and evaluate results against independent references before presenting radar-derived detections as validated.
  4. Bring forecasting back onto the roadmap. Explore the integration of suitable weather, rainfall and wind information, including relevant ACMAD/ICPAC products where available, to investigate how environmental conditions may help explain the movement or recurrence of candidate hotspots. Forecasting is planned work, not a capability implemented in the current prototype.
  5. Connect observations to action responsibly. Investigate how validated observations could inform ZiwaClear's broader coordination work without presenting automated detections as instructions to harvest or as a substitute for local judgement.
  6. Strengthen cloud evaluation. Verify the deployed AWS endpoint, record runtime behaviour and failures, and document the deployment configuration and reproducible tests.

Limitations and responsible use

The current study covers a small area and a limited time window. The pipeline identifies candidate vegetation rather than confirming water-hyacinth species, and the initial evaluation does not establish sensitivity, specificity, precision, recall or lake-wide coverage.

Sentinel-2 observations can be affected by scene quality, clouds, mixed pixels and the resolution of the imagery. The exploratory Sentinel-1 work is not yet a validated detection pipeline. No forecasting or predictive risk model is implemented in the current version.

For these reasons, ZiwaVision should be treated as a research and decision-support prototype. Candidate observations require appropriate review before being used to guide field operations. Future evaluation should report both successful and unsuccessful cases, compare against suitable independent reference data, document uncertainty and involve relevant local expertise.

The longer-term aim is to develop a dependable bridge between satellite observation and responsible environmental action—one that acknowledges existing scientific work, exposes its own limitations and earns trust through reproducible evidence.

Built With

Share this project:

Updates

Submission history