[general]
name=LiDAR Relief Visualization
qgisMinimumVersion=3.0
qgisMaximumVersion=4.99
description=A free, open-source QGIS toolkit with 31 Processing algorithms for archaeological LiDAR visualization and terrain analysis. Reveal subtle earthworks, prepare point clouds, compare surveys, combine LiDAR with satellite imagery, validate anomalies in the field, and produce reproducible research outputs.
version=2.2.1
author=Mark Bouck
email=markbouck@duck.com

about=LiDAR Relief Visualization is a free and open-source archaeological terrain-analysis toolkit for QGIS and part of the Dig:Tools ecosystem.
    Its 31 Processing algorithms help archaeologists, heritage professionals, and landscape researchers examine digital elevation models and LiDAR point clouds for subtle features such as ditches, banks, mounds, hollow ways, scarps, platforms, quarrying, and disturbed ground.
    Core tools include multi-directional hillshade, SLRM, Sky-View Factor, anisotropic Sky-View Factor, positive and negative openness, Local Dominance, MSTP, e4MSTP, Terrain Ruggedness Index, slope, VAT, Simple Red Relief, PCA composites, visualization blending, and batch processing with landscape presets.
    Extended workflows support LAS/LAZ ground filtering, PDAL processing, multi-temporal DEM comparison, LiDAR and Sentinel-2 fusion, Cloud-Optimized GeoTIFF export, interactive web maps, QField survey packages, reproducible visualization recipes, PDF reporting, and optional ONNX-based feature detection.
    Core terrain tools work with libraries supplied by QGIS. Specialized capabilities use clearly identified optional packages and remain isolated, so missing optional dependencies do not prevent the plugin from loading.
    The plugin supports QGIS 3 and QGIS 4 and is tested through automated numerical, packaging, clean-runtime, and desktop-loader checks. It supports transparent, reproducible research without subscription fees or proprietary lock-in.
    Visualizations and automated detections are interpretive aids rather than archaeological classifications. Assess potential features using complementary evidence and, where appropriate, field validation.
    New to the plugin? Run "Visualisation Contact Sheet" to compare techniques on your own DEM in seconds, then open any algorithm and press Help for the full user guide. The guide also ships inside the plugin folder as USER_GUIDE.md, and is online at https://github.com/dig-tools/lidar-relief-qgis-plugin/blob/main/lidar_relief/USER_GUIDE.md

tracker=https://github.com/dig-tools/lidar-relief-qgis-plugin/issues
repository=https://github.com/dig-tools/lidar-relief-qgis-plugin
homepage=https://github.com/dig-tools/lidar-relief-qgis-plugin

hasProcessingProvider=yes

tags=lidar,relief,visualization,dem,archaeology

category=Raster
icon=resources/icon.png

experimental=False
deprecated=False

changelog_url=https://github.com/dig-tools/lidar-relief-qgis-plugin/releases

changelog=
 Version 2.2.1:
 **Fixed**
 - Replaced 19 unscoped Qt and QGIS enum references with their Qt6-compatible
   scoped forms while preserving compatibility with QGIS 3 and PyQt5.
 - Added automated source and release guards so legacy enum forms are rejected
   before future plugin versions are uploaded to plugins.qgis.org.

 Version 2.2.0:
 **Added**
 - Native contextual help for every processing parameter, including practical
   guidance on units, scale, performance, and safe starting values.
 - An optional, dismissible contextual-help introduction that can be reopened
   from the LiDAR Relief plugin menu and remembers its startup preference.
 - A complete LiDAR Relief menu with native shortcuts to the Processing toolbox,
   Contact Sheet, Batch Relief, recipe import, the user guide, contextual help,
   recent recipes, and recent output folders.
 - DEM preflight reporting for CRS, resolution, dimensions, extent, sampled
   elevation and nodata statistics, memory guidance, terrain-form presets, and
   metric feature-scale starting radii.
 - Copy-friendly optional-dependency diagnostics covering GPU, CSF, PDAL, ONNX,
   COG, reports, temporal comparison, fusion, and labelled contact sheets.
 - One-click handoff from DEM preflight to the recommended Batch Relief preset,
   favorite tools and recipes, and non-destructive recent-item management.
 - Optional Batch Relief output naming templates and reusable recipes containing
   the successfully resolved run settings.
 - Synchronized two-raster comparison, structured GeoJSON or CSV interpretation
   notes, and CRS-aware named study-area bookmarks.
 - Redacted support ZIP creation containing diagnostics and optional active-DEM
   preflight information.
 - Advanced e4MSTP controls for openness, Local Dominance, MSTP scales, and tile
   size, with defaults matching the previous canonical implementation.
 - Regenerated the documentation's synthetic TRI figure directly from the
   current core algorithm, embedded provenance metadata, committed its
   deterministic generator, and added checks for every local documentation
   image reference.
 - Added an actual-QGIS screenshot and detailed first-run procedure for every
   Processing feature, illustrated guides for the plugin-menu workflows, a
   reproducible QGIS screenshot capture script and provenance manifest, and a
   version-controlled GitHub Wiki landing page.
 **Changed**
 - Contextual-help onboarding now appears once by default instead of at every
   QGIS startup; repeated startup display remains an explicit preference.
 - Updated the optional ML/image stack to Pillow 12.3.0, ONNX 1.22.0, and the
   Python-3.10-compatible ONNX Runtime 1.23.2, with generated test models pinned
   to ONNX opset 23 for QGIS 3.34 compatibility.
 **Fixed**
 - Corrected CI dependency quoting, kept documentation provenance checks free of
   optional Pillow imports, and configured the direct-dependency audit to avoid
   resolving intentionally independent QGIS package pins.
 **Security**
 - Added a pinned direct-dependency audit inventory and automated Semgrep and
   pip-audit checks for pull requests, pushes, manual runs, and a weekly
   schedule.
 - Documented GDAL as a QGIS-managed dependency so its Python bindings are not
   independently upgraded beyond the version bundled with QGIS.

 Version 2.1.2:
 Ships the v2.1.1 work, which never reached plugins.qgis.org. No code changes
 beyond release tooling.
 **Fixed**
 - **A single percent sign in the changelog was silently breaking every
   upload.** `qgis-plugin-ci` injects CHANGELOG.md into `metadata.txt`'s
   `changelog=` field at release time, and the QGIS plugin registry parses that
   file with configparser's `BasicInterpolation`, which treats the percent sign
   as a control character. One that is not doubled, or followed by an opening
   parenthesis, makes the entire `metadata.txt` unparseable — so the registry
   refused the package. Because `qgis-plugin-ci` calls `raise_for_status()`
   without ever reading `response.text`, the only symptom was a bare
   `HTTP 400` with no reason given. v2.1.1 failed three times over the phrase
   "an 84 percent reduction".
   Every percent sign is now gone from CHANGELOG.md, and
   `scripts/check_changelog.py` rejects undoubled ones with an explanation, so
   `./test.sh` and the release workflow both catch this before it reaches the
   registry. A test additionally proves the real changelog survives
   interpolation, using the same parser the registry uses.
   Older entries carried the same character for months without incident, only
   because they sit below the slice of changelog that `qgis-plugin-ci` injects.
   The trap was always armed, just out of reach.
 **Added**
 - **Releases now verify they actually reached QGIS users.** A "successful"
   release job has not been a reliable signal: the v2.1.0 run reported success
   and logged *"Plugin uploaded on plugins.qgis.org"*, yet the public repository
   carried on serving 2.0.22 — the version was accepted but never approved, so
   it never became installable, and nothing said so. The v2.1.1 upload was then
   refused with a bare HTTP 400 whose response body `qgis-plugin-ci` discards.
   Both states were invisible from the workflow.
   `scripts/verify_published.py` now queries the public plugin repository after
   every release and reports whether the released version is genuinely being
   served, writing a warning annotation and a run summary. It is advisory
   rather than fatal, because approval is a human queue on the QGIS side and a
   red tick for normal moderation latency would just train everyone to ignore
   it. It runs even when the upload step fails, since that is precisely when
   the current published state is worth knowing. A network failure reports
   "unknown", never "published".


