SiteWise Interpolated Queries: Keep the Output Grid Separate from the Data Search Window

A SiteWise interpolation query has two separate distances: the spacing between requested output timestamps and the distance searched for input observations around each timestamp. Widening the search can make a previously unsupported estimate possible without changing the output grid at all.

Keep those controls separate when reviewing sparse industrial telemetry. A denser grid does not create new measurements, and a wider search window does not make the underlying equipment report more often.

This article uses the GetInterpolatedAssetPropertyValues API reference, read on 19 October 2026. The examples are synthetic timestamps and arithmetic; no SiteWise query, data ingestion or equipment test was performed.

Draw the grid before the observations

intervalInSeconds establishes the requested interpolation spacing. An explicit intervalWindowInSeconds searches from each candidate timestamp minus that window to the timestamp plus it, and requires type = LINEAR_INTERPOLATION. If the search window contains no data point, SiteWise returns no interpolated value for that interval.

Use a query covering a three-minute span and focus only on interior grid points at offsets 60 and 120 seconds, with intervalInSeconds = 60. Let the span begin at an arbitrary valid Unix timestamp T; all times below are offsets from T.

The interior points avoid an ambiguity in the reference page: the start parameter is described as exclusive, while its sample response includes a start-time value. This exercise does not use that inconsistent sample to establish endpoint behavior.

Supply four hypothetical GOOD-quality observations:

offset  50 seconds: value 10
offset  70 seconds: value 20
offset 100 seconds: value 30
offset 140 seconds: value 50

These values have no physical units because the example examines query geometry. Any later engineering interpretation needs the property’s real units and signal model.

Compare a narrow window with a wider one

With a fifteen-second window, the 60-second candidate searches offsets 45 through 75. It has the two bracketing observations at 50 and 70. Their straight-line arithmetic gives 15 at offset 60.

The same window at offset 120 covers 105 through 135. None of the four observations lies there. The documented absence condition applies: no interpolated value is returned for that candidate. Leave that result visibly absent rather than inserting numeric zero.

Increase only the search window to twenty-five seconds. The grid remains at offsets 60 and 120. Around 60, the range becomes 35 through 85 and retains the same two bracketing points. Around 120, the range becomes 95 through 145 and now includes observations at 100 and 140.

For that second pair, the original linear calculation is:

30 + (50 - 30) * (120 - 100) / (140 - 100) = 40

The table records intended arithmetic expectations for a controlled test, not an API response captured from the service:

Interior grid point Window of 15 seconds Window of 25 seconds
Offset 60 seconds Bracketing points support 15 Same points support 15
Offset 120 seconds No input in window; result absent Bracketing points support 40
At an interior grid point of 120 seconds, a 15-second search window has no observations; a 25-second window includes points at 100 and 140 seconds without changing the grid.
Original interpolation-support window diagram using synthetic times. No service query was executed.

Do not turn a necessary condition into a complete algorithm

The no-point rule establishes when an estimate is unavailable. It does not establish that any single observation inside a window always suffices for linear interpolation. The worked supported cases deliberately provide observations on both sides of each candidate. A lone-point edge case needs its own documented or observed service behavior before the client relies on it.

The API also documents a different default search extent when the window parameter is omitted: query start minus interval through query end plus interval. Do not describe omission as an explicit per-candidate window equal to the grid spacing. Preserve the actual parameter presence in a query review.

Make estimation distance an application decision

quality = GOOD filters input quality. It does not certify freshness, a maximum physical slew rate or a bounded interpolation error. In this fixture, widening the window admits observations twenty seconds away from the second estimate. Whether that distance is acceptable depends on the measured process.

For a slowly changing monitored temperature, a product team might accept a specified distance after validation. For a short machine transient, the same interpolation could hide the event. The query cannot establish which physical trajectory occurred between the observations.

A proposed acceptance record should preserve the grid, explicit search window, original observations and missing-result handling. Compare the narrow and wide cases while leaving the grid unchanged, then vary grid spacing while leaving the search window fixed. Completion means the client can explain both where estimates were requested and which nearby evidence could support them.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *