b0txec
142 lines
6.7 KiB
Markdown
142 lines
6.7 KiB
Markdown
# Product workflows
|
||
|
||
This document records the current understanding of the visible workspaces. It should be updated when workplace users clarify the real operational purpose.
|
||
|
||
## Operator language
|
||
|
||
Operator-facing workspace names, map names, export names, and production labels should use the established Latvian newsroom terminology. Development discussion and internal code may remain in English where useful, but that must not force English wording into the interface used by Latvian operators.
|
||
|
||
## 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 normalized transparent image assets;
|
||
- 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 symbol, 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 normalized image 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.
|
||
|
||
Completed Faktiskā checkpoint:
|
||
|
||
- fixed 13-position station set with no repeated city selection;
|
||
- automatic latest-temperature loading with observation time and stale/missing states;
|
||
- manual temperature correction and reset to the fetched value;
|
||
- manual wind direction, speed, and gust values;
|
||
- manual weather-symbol selection with apply-to-all and station exceptions;
|
||
- automatic badge-relative image placement using consistent 256×256 asset geometry;
|
||
- guarded 3840×1440 export using the fixed wind production artwork.
|
||
|
||
Valmiera is included in the development seed so all 13 fixed positions can be exercised. Confirmed Monda Regular/Bold files are now bundled and used. The export dimensions are locked, but final pixel-level placement must still be compared against the production masters after the font change.
|
||
|
||
## Ūdens temperatūra
|
||
|
||
Purpose: prepare the fixed water-temperature newsroom map as a separate production workflow. It must not be mixed into Faktiskā or City Analysis.
|
||
|
||
Authoritative references:
|
||
|
||
- `UDENS_TEMPERATURA.png` defines the finished on-air composition;
|
||
- `UDENS_TEMP_NOSAUKUMI.png` defines the operator-facing names of the manually entered water areas/fields.
|
||
|
||
Required behavior:
|
||
|
||
1. Open the dedicated **Ūdens temperatūra** workspace.
|
||
2. Display the fixed set of Latvian-named water-temperature fields.
|
||
3. Enter or correct every water temperature manually.
|
||
4. Place values automatically at their locked production positions.
|
||
5. Preview and download either a 1920×1080 or 3840×1440 PNG.
|
||
|
||
The background, title, source, field set, and value positions remain fixed. Only the water-temperature values are routinely edited. Both output sizes are production requirements and must be validated independently; implementation must not assume that browser preview dimensions define export geometry.
|
||
|
||
When switching output size, the background may use the target canvas aspect ratio, but boxes, typography, and nameplate elements must scale uniformly. They must never be independently stretched on the horizontal and vertical axes.
|
||
|
||
Implementation status: first working version implemented. The page provides six Latvian-named manual min/max controls, automatic fixed placement, Monda rendering, explicit resolution selection, completeness validation, and Latvian PNG filenames. Pixel-level comparison and independent calibration of both output sizes remain required.
|
||
|
||
## 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 pixel-level Monda export comparison against the production masters.
|
||
- Required authentication and role separation for analytical, production, and administrative workspaces.
|