[IGN-15587]Possible bug with system.historian.queryAggregatedPoints() returnFormat="CALCULATION"

Ignition
,
1

I’ve been playing around with the new system.historian.queryAggregatedPoints() function in 8.3.2 and I’m seeing some strange results when using returnFormat="CALCULATION".

It almost seems like it is internally performing a cross-join of some sort with the calculated results to return far too many calculated columns - the number of calculated columns returned is equal to len(paths)*len(aggregates). If I pass in 3 tags and 3 aggregates, I’m getting back a dataset with 9 calculated columns (plus the t_stamp and tagpath columns). The calculated column names and values are repeated every 3 columns.

I would assume this is a bug? Or am I missing a key piece of information for how to use this function with that specific parameter value?

Test Code 
tags = [
	"tagpath1", 
	"tagpath2", 
	"tagpath3",
]
start = system.date.getDate(2026, 1, 25)
end = system.date.addMinutes(start, 5)
aggregates = ["Average", "Minimum", "Maximum"]
ds = system.historian.queryAggregatedPoints(tags, start, end, aggregates, returnFormat="CALCULATION")

print "Column Names:", system.dataset.getColumnHeaders(ds)
for r in ds:
	print r[0:2] + [round(c, 1) for c in r[2:]]
Output 
Column Names: [u't_stamp', u'tagpath', u'Average', u'Minimum', u'Maximum', u'Average', u'Minimum', u'Maximum', u'Average', u'Minimum', u'Maximum']
[Wed Feb 25 00:00:00 EST 2026, u'prov:Example:/tag:tagpath1', 1348.0, 1333.0, 1363.0, 1348.0, 1333.0, 1363.0, 1348.0, 1333.0, 1363.0]
[Wed Feb 25 00:00:00 EST 2026, u'prov:Example:/tag:tagpath2', 70.0, 70.0, 70.0, 70.0, 70.0, 70.0, 70.0, 70.0, 70.0]
[Wed Feb 25 00:00:00 EST 2026, u'prov:Example:/tag:tagpath3', 54.0, 54.0, 54.0, 54.0, 54.0, 54.0, 54.0, 54.0, 54.0]
2

That sounds right. It is inherently a "wide" format. (Not that that is best...)

3

Wouldn't you expect one row per time window with a column for every path+aggregate pair in a wide format?

What I’m seeing is a strange hybrid. It gives me one row per path (Tall format), but then uses the column count of a Wide format. What's even more strange is it fills those extra columns with duplicate aggregate data from the row's specific path.

4

Ah, I misunderstood. Sounds like a bug worth reporting.

5

A dev on the historian team did some investigation and filed a ticket for this. It's too early to give any kind of estimate on timeline, but we'll get it fixed.

6

Thanks Paul. Would it be possible to get an answer from the historian team on the intended output format - tall vs wide? Just making sure I avoid bad assumptions on my end.

7

I think the expected format is 'wide' - one column in the output per provided input. Whatever you get if you don't use CALCULATIONS.