This document captures potential future directions for the GeoPublicHealth QGIS plugin. It is intended for discussion, prioritization, and roadmap planning.
Each item is described using:
WHY: Broaden the analytical coverage beyond current Moran/Geary/Gi tools and support richer exploratory spatial data analysis used in epidemiology.
WHAT: Add LOSH, correlograms, multivariable Moran, local join counts, and diagnostic measures like geosilhouettes and boundary strength summaries.
HOW: Implement new analysis logic in src/core/services/ using PySAL ESDA and surface results in the existing autocorrelation dialog and processing algorithms.
WHY: Support longitudinal disease monitoring and change detection for surveillance workflows.
WHAT: Directional LISA, spatial Markov transitions, and temporal mobility summaries with map outputs and optional charts.
HOW: Use PySAL Giddy for computation, expose time-enabled layers in UI, and connect to QGIS temporal controller for animation export.
WHY: Quantify and map health inequities across populations and geographies.
WHAT: Multigroup and local segregation indices, inference tests, and optional network-based variants for access inequities.
HOW: Use PySAL Segregation in a dedicated service, add new dialogs and Processing tools that output index fields and summary reports.
WHY: Identify coherent health regions and clusters while respecting spatial contiguity and administrative boundaries.
WHAT: Implement SKATER, REDCAP, Max-P, and spectral clustering; keep k-means and DBSCAN with public health presets.
HOW: Use GeoDa-style algorithms where available in PySAL or reimplement in src/core/services/; add clustering outputs as new layers and reports.
WHY: Detect statistically significant disease clusters in space, time, and space-time.
WHAT: Integrate a scan statistics workflow for Poisson, Bernoulli, and space-time permutation models.
HOW: Wrap SaTScan or a compatible open-source implementation; add a data preparation wizard, run engine externally, and import results as layers.
WHY: Measure access gaps, service deserts, and spatial equity in healthcare provision.
WHAT: Service areas, catchments, travel-time thresholds, and facility location options, plus equity overlays.
HOW: Use QGIS network algorithms for routing/service areas and extend with PySAL Spaghetti for network-based metrics; integrate in services and dialogs.
WHY: Improve interpretation and communication of results for public health stakeholders.
WHAT: Small multiples for time steps, narrative map templates, and automated spatiotemporal animations for surveillance reporting.
HOW: Provide layout presets and scripts that drive QGIS temporal controller and atlas export; offer standardized symbology for common metrics.
WHY: Model spatial dependence in health outcomes to avoid biased inference and support explanatory analysis.
WHAT: Add spatial regression tools including OLS with spatial diagnostics, spatial lag/error/Durbin models, robust standard errors, and optional GWR/MGWR.
HOW: Use PySAL spreg (and mgwr when feasible) in src/core/services/, add GUI and Processing tools, and output summaries plus residual fields.
WHY: Ensure reproducibility and batch processing for large workflows.
WHAT: Full parity between GUI tools and QGIS Processing algorithms, including standardized output schemas.
HOW: Centralize logic in src/core/services/ and wrap each service in both GUI dialogs and Processing algorithms.
WHY: Keep analytics trustworthy and maintainable as feature surface grows.
WHAT: Unit tests for new metrics, regression tests for bugs, and concise user-facing docs.
HOW: Add tests under src/test/ following existing patterns, keep test data small, and update docs in docs/ and README.md as needed.
Short term (high value, low integration risk):
Mid term (moderate integration effort, high impact):
Longer term (external dependencies, heavier workflows):