WeatherTool/docs/PRODUCT_WORKFLOWS.md

# Product workflows

This document records the current understanding of the visible workspaces. It should be updated when workplace users clarify the real operational purpose.

## Home

Entry point and navigation overview. It identifies the development dataset and links to each workspace.

## Stations

Purpose: inspect station-focused observations, map values, and open detailed charts for a selected station.

Current status: inherited workflow; still requires detailed workplace validation and UI review.

## City Analysis

Purpose: compare historical observations across selected cities.

The operator chooses:

- cities;
- start and end time;
- weather field;
- aggregate key;
- granularity.

Results can be viewed as grid/list data or rendered into the familiar temperature-map formats. Weather-symbol authoring does not belong in this workflow.

## Faktiskā

Purpose: prepare the fixed daily **faktiskā laika ziņu karte**—the current-weather graphic used on air. The supplied production master images are the authoritative output specification, not visual inspiration.

The production template contains:

- the fixed title/source nameplate already present in the production artwork;
- the latest available temperature for each fixed station;
- weather conditions represented by the bundled weather-font glyphs;
- manually entered wind direction, speed, and gust values;
- a fixed 3840×1440 PNG output.

Current operator flow:

1. Open Faktiskā; the fixed station set and latest `tempAvg` observations load automatically.
2. Review the observation timestamp, missing/stale indicators, and temperatures.
3. Override any temperature manually when editorial correction is required; reset restores the fetched value.
4. Enter wind values manually.
5. Select a weather glyph, apply it to all stations where appropriate, and adjust exceptions.
6. Review and download `faktiska-3840x1440.png`.

Fixed positions:

| Position | Station |
|---:|---|
| 0 | Liepāja |
| 1 | Ventspils |
| 2 | Stende (temporary substitute for Talsi) |
| 3 | Saldus |
| 4 | Rīga |
| 5 | Jelgava |
| 6 | Ainaži |
| 7 | Valmiera |
| 8 | Madona |
| 9 | Alūksne |
| 10 | Zīlāni (temporary substitute for Jēkabpils) |
| 11 | Daugavpils |
| 12 | Rēzekne |

The weather symbols are not automatically derived from the historical temperature query. They remain editorial/manual inputs until a reliable phenomena-data mapping is designed and validated.

Symbol selection is manual, but placement is automatic. Each Faktiskā position owns a fixed marker layout that attaches the selected font glyph to the actual rendered edge of its temperature badge. Operators do not position symbols for each export; per-station offsets can be refined centrally against the production master.

Valmiera is included in the development seed so all 13 fixed positions can be exercised. Monta is the production typeface; Rubik remains temporary until the authorized Monta font files are supplied. The export dimensions are locked, but final pixel-level placement must still be compared against the production masters after Monta is installed.

## Latvia overview

Purpose: aggregate selected fields across Latvia for a selected time range.

Current status: inherited workflow; terminology, units, and workplace use still need validation.

## Data archive

Purpose: inspect available database dates and individual stored records/files.

Current status: inherited technical/administrative workflow. Access control and export correctness require review before production use.

## HARMONIE

Purpose: inspect and render forecast-model GRIB fields.

Development limitation: no representative HARMONIE GRIB fixtures are currently included, and valid external-provider access is not configured in staging.

## LVGMC forecast

Purpose: display prepared LVGMC forecast products and broadcast tables.

Development limitation: representative forecast CSV fixtures are not currently included, and valid external-provider access is not configured in staging.

## Decisions still required

- Whether weather conditions can eventually be populated automatically and which provider field is authoritative.
- Whether Stende and Zīlāni remain the production feeds after users test real provider data.
- Confirm how Valmiera is named and sourced when authorized provider data is available.
- Final Monta font files and a pixel-level export comparison against the production masters.
- Required authentication and role separation for analytical, production, and administrative workspaces.