In RDMS this is called “flattening”.
There are two main types of curve data in RDMS: “actual” and “forecast”. Both have a CurveID and ValueDate/Value pairs, but an “actual” curve has only one set of pairs, with one ForecastDate (which is 2000-01-01 00:00:00 by convention), whereas a “forecast” curve will have multiple such timeseries, each with a different ForecastDate.
Consider a forecast curve ID 123456 that contains, for each ForecastDate, a set of seven day-ahead forecast prices:
Using endpoints such as /v1/CurveValues/Aggregated, by default this returns the latest forecast only, being the most recent set of seven forward-looking values. Earlier forecasts can be returned by setting the MaxForecastDate parameter to a specific date/time, in which case the most recent seven-day forecast at or prior to that time will be returned. However, each individual forecast will only ever contain seven values.
With “flattening”, we can convert a set of Forecasts into a single timeseries by returning not only the most recent forecast values, but also, for days prior to this, the most recent available forecast value for that ValueDate. To do this, we use the Flatten Boolean parameter (Flatten=true).
So for example:
will return the seven daily values from the most recent forecast.
Will return the same seven values, but also, for all days prior to these, the most recent forecast value available for each ValueDate.
From the above, it follows that the Flatten parameter has no effect on Actuals curves, because there is only a single “forecast” anyway.
For performance reasons, care should be taken to use the MinValueDate parameter to restrict the date range returned to the range required, rather than leaving it to default and trim the result on the client side.
(Note for those familiar with the legacy “ScenarioID 1” form of flattening: The Flatten parameter makes the use of ScenarioID 1 redundant. It also allows for the possibility of curves that have ScenarioIDs other than 0 to also be flattened)