Part of #27 (adopt views-frames v1.0.0). Foundation — #CONF builds on this. Cross-repo dependency: views-platform/views-pipeline-core#188 (the upstream PredictionFrame re-export shim). Solution-open.
Context
unfao/managers/unfao.py ingests point-estimate predictions (datafactory loader for historical; Appwrite prod_forecasts parquet for forecasts) and wraps them in pipeline-core's PGMDataset:
# views_postprocessing/unfao/managers/unfao.py:7
from views_pipeline_core.data.handlers import PGMDataset
# :58-60 self._historical_dataset = PGMDataset(source=self._historical_dataframe, ...)
# :100 self._forecast_dataset = PGMDataset(self._forecast_dataframe)
Adopt the published views_frames.PredictionFrame for the (time, unit) prediction values instead of the pipeline-core container. Because the current pipeline is point estimates (no posterior axis), each prediction becomes a (N, 1) frame (sample axis size 1), SpatialLevel.PGM, identifiers {time=month_id, unit=priogrid_gid}.
What stays unchanged (domain): the GAUL enrichment (unfao/enrichment.py, the 9-column METADATA_COLS) and the FAO parquet delivery. The frame is the transport for the prediction values; the GAUL string-metadata columns and the delivery format remain postprocessing's own DataFrame layer. (A float32 PredictionFrame cannot carry the string metadata — that's by design; enrichment lives outside the frame.)
Sequencing / approaches (open)
- Depends on pipeline-core #188 (pipeline-core re-exports
views_frames.PredictionFrame). Interim: postprocessing can construct the frame directly from its loaded (month_id, priogrid_gid) index + values + SpatialLevel.PGM, so it isn't hard-blocked.
- A re-point ingestion to yield a
PredictionFrame; B a thin adapter at the read boundary that wraps the loaded values in a frame. Your call — you know the read path.
Suggested DoD (refine)
References: see #27; pipeline-core upstream views-platform/views-pipeline-core#188.
🤖 Filed by the views-frames maintainer agent (issues only; no postprocessing code touched).
Part of #27 (adopt views-frames v1.0.0). Foundation — #CONF builds on this. Cross-repo dependency: views-platform/views-pipeline-core#188 (the upstream
PredictionFramere-export shim). Solution-open.Context
unfao/managers/unfao.pyingests point-estimate predictions (datafactory loader for historical; Appwriteprod_forecastsparquet for forecasts) and wraps them in pipeline-core'sPGMDataset:Adopt the published
views_frames.PredictionFramefor the(time, unit)prediction values instead of the pipeline-core container. Because the current pipeline is point estimates (no posterior axis), each prediction becomes a(N, 1)frame (sample axis size 1),SpatialLevel.PGM, identifiers{time=month_id, unit=priogrid_gid}.What stays unchanged (domain): the GAUL enrichment (
unfao/enrichment.py, the 9-columnMETADATA_COLS) and the FAO parquet delivery. The frame is the transport for the prediction values; the GAUL string-metadata columns and the delivery format remain postprocessing's own DataFrame layer. (A float32PredictionFramecannot carry the string metadata — that's by design; enrichment lives outside the frame.)Sequencing / approaches (open)
views_frames.PredictionFrame). Interim: postprocessing can construct the frame directly from its loaded(month_id, priogrid_gid)index + values +SpatialLevel.PGM, so it isn't hard-blocked.PredictionFrame; B a thin adapter at the read boundary that wraps the loaded values in a frame. Your call — you know the read path.Suggested DoD (refine)
views-framesdependency resolvable (see the distribution-channel note in Epic: Adopt views-frames v1.0.0 (consumer; first live conformance proof) #27)views_frames.PredictionFrame(SpatialLevel.PGM,(N, 1))PGMDatasetdependency on the prediction path droppedpoetry run pytest tests/greenReferences: see #27; pipeline-core upstream views-platform/views-pipeline-core#188.
🤖 Filed by the views-frames maintainer agent (issues only; no postprocessing code touched).