Skip to content

Add inverse distance weighting (IDW) as an alternative interpolation method #16

@tomhoag

Description

@tomhoag

Description

The current DensityGrid uses Gaussian kernel density estimation (KDE), which is designed for estimating where events are concentrated (e.g., crime maps, foot traffic). For use cases where weighted points represent measured values at known locations — such as weather station temperatures — inverse distance weighting (IDW) or similar spatial interpolation methods would produce more accurate results.

KDE answers "how dense are events here?" while IDW answers "what is the estimated value here, given nearby measurements?" The distinction matters for sparse station networks where you want to interpolate between known values rather than estimate event density.

Proposed API

HeatMapConfiguration(
    radius: 1000,
    interpolation: .idw(power: 2),  // default: .kde (current behavior)
    gradient: .thermal
)

Proposed Interpolation Methods

  • .kde — Current Gaussian kernel density estimation (default, preserves backward compatibility)
  • .idw(power:) — Inverse distance weighting. The power parameter (default 2) controls how quickly influence decays with distance. Higher values give more weight to nearby points.

Design Considerations

  • This changes the semantic meaning of the grid from "density" to "interpolated value," so the contour thresholds will represent actual data values rather than density levels.
  • The contour extraction (marching squares) and rendering pipeline remain unchanged — only the grid computation step differs.
  • IDW with compact support (clamped to radius) keeps the same bounding box and padding logic.
  • The weight property on HeatMapPoint would represent the measured value for IDW, vs. event intensity for KDE.
  • Could be implemented as a strategy on DensityGrid.compute or as a separate grid computation path.

Notes

This is separate from #10 (additional KDE kernel functions like Epanechnikov/Tricube), which varies the kernel shape within the KDE framework. This issue proposes an entirely different interpolation approach for a different class of use case.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions