SeaSense · Planning Document · Cassini Hackathon Project · Copernicus Marine Viewer

Data flow &
design specifications

From satellite to farm decision. A visual reference for the build phase — covering data architecture, interface principles, and responsive design across field and desktop contexts.

Sentinel-3 Sentinel-2 CMEMS Processing Dashboard Alert Engine
01 — Data pipeline
Satellite to farm decision
Sentinel-3 OLCI/SLSTR
Sentinel-2 MSI
CMEMS ocean model
Processing / fusion
Dashboard output
Alert engine
🛰
Observe
🌡
Sentinel-3 SLSTR
Sea surface temperature
Daily · free via CMEMS1 km
🌿
Sentinel-3 OLCI
Chlorophyll-a concentration
Daily · HAB indicator300 m
💧
Sentinel-2 MSI
Turbidity / water clarity
5-day revisit · near-shore10 m
🌊
CMEMS IBI model
Currents, waves & salinity
5–10 day forecast~3 km
⚙️
Process
🔬
Processing layer
Downscaling & fusion
S-3 + S-2 + CMEMS combinedfarm-plot
🎚
Threshold engine
Species-specific conditions
Farmer-configured · per siteconfigurable
📊
Temporal context
Site baseline & history
Site-relative · non-prescriptive7-day avg
🧭
Interpret
🗺
Conditions layer
Current farm conditions
Maps + metrics + contextdaily
📅
Cultivation calendar
Seeding & harvest windows
Forecast-linked · species-aware10-day
⚠️
Risk indicators
HAB · storm · low O₂
Named conditions · farmer readspush alert
📱
Present
🖥
Desktop / tablet
Full situational view
Landscape · planningdata-rich
📱
Field mobile
Compact conditions view
Portrait · on the waterglanceable
🔔
Push notification
Risk alert delivery
Configurable · any deviceimmediate
Near-shore limitation — name this in the pitch: Sentinel-3's 300 m pixel covers roughly 9 hectares of ocean surface. Individual farm plots are invisible at that scale. SeaSense addresses this through downscaling — feeding CMEMS regional model outputs into higher-resolution local coastal models, following the precedent of the RAIA observatory on the Iberian Atlantic coast. This is the core technical challenge SeaSense is solving, and naming it builds more credibility than papering over it.
02 — Interface philosophy
Designed for the person on the water
The principle

The dashboard presents what the water is doing. It does not tell the farmer what to do about it. Metrics show values and site-relative context rather than a traffic-light risk score that pre-digests the judgment for someone who knows their water better than any satellite does.

In practice
  • Display: "Chlorophyll 4.2 mg/m³ — elevated vs. 7-day site average"
  • Not: "Bloom risk: HIGH — consider delaying harvest"
  • The farmer reads the condition and decides. The tool holds the data.
  • Source traceable one tap away: satellite, date, resolution, known limits
The principle

Alert triggers are configured by the grower, not preset by the system. A kelp farm in the Gulf of Finland has different temperature tolerances than a mussel farm off Brittany. The farmer's local expertise defines the parameters. The system holds and monitors them.

In practice
  • Onboarding: farmer selects species, sets location, defines alert thresholds
  • Thresholds editable at any time — seasonal adjustment is expected
  • Multiple species per farm site supported for polyculture operations
  • Default suggestions available as a starting point, but never imposed
The principle

Every metric is shown against the site's own historical baseline, not a generic regional average. This respects the ecological specificity of each location and makes the data readable to someone who has watched that particular stretch of water across multiple seasons.

In practice
  • 7-day rolling average per metric, per farm location
  • Seasonal baseline built over time — more useful as the farm matures
  • Year-on-year comparison available in desktop planning view
  • Anomalies named relative to site history, not global norms
The principle

The field context is not an edge case. It is the primary use environment. The interface must work on a device that may be wet, in direct sunlight, held in one hand, by someone whose attention is divided between the screen and the water around them.

In practice
  • Minimum touch target: 56px — larger than the standard 44px guideline
  • High contrast palette tested against direct sunlight simulation
  • No gestures requiring two hands or fine motor precision
  • Critical information visible without scrolling on field mobile view
  • Recommended hardware: 10" tablet in waterproof case as field primary
The principle

Every metric is traceable to its source — Sentinel-3 SLSTR, CMEMS IBI model, Sentinel-2 MSI — accessible one tap away. Farmers and regulators should be able to see exactly what the dashboard is showing and where it came from, without needing to trust the system blindly.

In practice
  • Each metric card: tap to see source satellite, date, resolution, known limitations
  • Near-shore resolution limitation flagged transparently — not hidden in fine print
  • Exportable data logs for certification and regulatory compliance
  • All Copernicus sources are free, open, and publicly documented
03 — Responsive views
Desktop + field mobile
Desktop / tablet Landscape · planning
Overview
Map layers
Calendar
Alerts
Forecasts
Reports
satellite layer · farm overlay
SST
14.2°C
+1.1 vs 7d avg
Chl-a
4.2 ↑
mg/m³ · elevated
Turbidity
0.8 NTU
within normal
Wave ht
0.4 m
calm · 5d fcast
  • Side navigation keeps map dominant — metrics live beneath, not beside
  • Satellite layer toggle: SST · chlorophyll · turbidity · currents
  • Cultivation calendar accessible from main navigation, not buried in settings
  • All metric values show site-relative context as a secondary label
  • Used for planning, regulatory reporting, and certification documentation
Field mobile Portrait · on the water
SST
14.2°
Chl-a
4.2 ↑
Waves
0.4 m
farm coordinates · compact
Chlorophyll elevated vs. 7-day site average
  • Three metrics maximum above the fold — first thing the eye reaches
  • Map compact but present — spatial orientation matters on the water
  • Alert bar names the condition and the comparison, not a risk level
  • Minimum 56px touch targets throughout the interface
  • High contrast palette · direct sunlight readable · no two-handed interactions
  • Recommended: 10" tablet in waterproof case as the primary field device
04 — Prototype sequence
Build in this order
01
Pull one CMEMS variable
SST for one coastal bounding box via the copernicusmarine Python API. Validate near-shore resolution concretely before building anything else.
02
Put it on a map
Display SST layer on a Leaflet.js or MapLibre map. Overlay a geolocated farm plot polygon. See what 1 km pixels look like at actual farm scale.
03
Add chlorophyll
Pull Sentinel-3 chl-a layer. Demonstrate the two-source fusion — SST from SLSTR, ocean colour from OLCI — on the same map view.
04
Build threshold logic
Farmer sets a value. System flags exceedance relative to site 7-day average. Names the condition — does not score it. This is the alert engine core.
05
Cultivation calendar
Separate panel linked to forecast data. Shows upcoming SST and chl-a projections across a 10-day window. Farmer reads it and plans accordingly.
File formats to know before starting: CMEMS model outputs use NetCDF (.nc) — a multidimensional array format carrying time, depth, and geographic dimensions in one file. Sentinel satellite imagery comes as GeoTIFF. Both are natively readable in QGIS without conversion. The copernicusmarine Python package can subset NetCDF files by bounding box and time range before download, keeping file sizes manageable for a first prototype.