{"name": "LiDAR Relief Visualization", "package_name": "lidar_relief", "version": "2.2.1", "experimental": false, "qgis_min": "3.0.0", "qgis_max": "4.99.0", "downloads": 328, "uploaded_by": null, "upload_datetime": "2026-07-28T00:18:50.851542", "changelog": "Version 2.2.1:\n**Fixed**\n- Replaced 19 unscoped Qt and QGIS enum references with their Qt6-compatible\nscoped forms while preserving compatibility with QGIS 3 and PyQt5.\n- Added automated source and release guards so legacy enum forms are rejected\nbefore future plugin versions are uploaded to plugins.qgis.org.\n\nVersion 2.2.0:\n**Added**\n- Native contextual help for every processing parameter, including practical\nguidance on units, scale, performance, and safe starting values.\n- An optional, dismissible contextual-help introduction that can be reopened\nfrom the LiDAR Relief plugin menu and remembers its startup preference.\n- A complete LiDAR Relief menu with native shortcuts to the Processing toolbox,\nContact Sheet, Batch Relief, recipe import, the user guide, contextual help,\nrecent recipes, and recent output folders.\n- DEM preflight reporting for CRS, resolution, dimensions, extent, sampled\nelevation and nodata statistics, memory guidance, terrain-form presets, and\nmetric feature-scale starting radii.\n- Copy-friendly optional-dependency diagnostics covering GPU, CSF, PDAL, ONNX,\nCOG, reports, temporal comparison, fusion, and labelled contact sheets.\n- One-click handoff from DEM preflight to the recommended Batch Relief preset,\nfavorite tools and recipes, and non-destructive recent-item management.\n- Optional Batch Relief output naming templates and reusable recipes containing\nthe successfully resolved run settings.\n- Synchronized two-raster comparison, structured GeoJSON or CSV interpretation\nnotes, and CRS-aware named study-area bookmarks.\n- Redacted support ZIP creation containing diagnostics and optional active-DEM\npreflight information.\n- Advanced e4MSTP controls for openness, Local Dominance, MSTP scales, and tile\nsize, with defaults matching the previous canonical implementation.\n- Regenerated the documentation's synthetic TRI figure directly from the\ncurrent core algorithm, embedded provenance metadata, committed its\ndeterministic generator, and added checks for every local documentation\nimage reference.\n- Added an actual-QGIS screenshot and detailed first-run procedure for every\nProcessing feature, illustrated guides for the plugin-menu workflows, a\nreproducible QGIS screenshot capture script and provenance manifest, and a\nversion-controlled GitHub Wiki landing page.\n**Changed**\n- Contextual-help onboarding now appears once by default instead of at every\nQGIS startup; repeated startup display remains an explicit preference.\n- Updated the optional ML/image stack to Pillow 12.3.0, ONNX 1.22.0, and the\nPython-3.10-compatible ONNX Runtime 1.23.2, with generated test models pinned\nto ONNX opset 23 for QGIS 3.34 compatibility.\n**Fixed**\n- Corrected CI dependency quoting, kept documentation provenance checks free of\noptional Pillow imports, and configured the direct-dependency audit to avoid\nresolving intentionally independent QGIS package pins.\n**Security**\n- Added a pinned direct-dependency audit inventory and automated Semgrep and\npip-audit checks for pull requests, pushes, manual runs, and a weekly\nschedule.\n- Documented GDAL as a QGIS-managed dependency so its Python bindings are not\nindependently upgraded beyond the version bundled with QGIS.\n\nVersion 2.1.2:\nShips the v2.1.1 work, which never reached plugins.qgis.org. No code changes\nbeyond release tooling.\n**Fixed**\n- **A single percent sign in the changelog was silently breaking every\nupload.** `qgis-plugin-ci` injects CHANGELOG.md into `metadata.txt`'s\n`changelog=` field at release time, and the QGIS plugin registry parses that\nfile with configparser's `BasicInterpolation`, which treats the percent sign\nas a control character. One that is not doubled, or followed by an opening\nparenthesis, makes the entire `metadata.txt` unparseable \u2014 so the registry\nrefused the package. Because `qgis-plugin-ci` calls `raise_for_status()`\nwithout ever reading `response.text`, the only symptom was a bare\n`HTTP 400` with no reason given. v2.1.1 failed three times over the phrase\n\"an 84 percent reduction\".\nEvery percent sign is now gone from CHANGELOG.md, and\n`scripts/check_changelog.py` rejects undoubled ones with an explanation, so\n`./test.sh` and the release workflow both catch this before it reaches the\nregistry. A test additionally proves the real changelog survives\ninterpolation, using the same parser the registry uses.\nOlder entries carried the same character for months without incident, only\nbecause they sit below the slice of changelog that `qgis-plugin-ci` injects.\nThe trap was always armed, just out of reach.\n**Added**\n- **Releases now verify they actually reached QGIS users.** A \"successful\"\nrelease job has not been a reliable signal: the v2.1.0 run reported success\nand logged *\"Plugin uploaded on plugins.qgis.org\"*, yet the public repository\ncarried on serving 2.0.22 \u2014 the version was accepted but never approved, so\nit never became installable, and nothing said so. The v2.1.1 upload was then\nrefused with a bare HTTP 400 whose response body `qgis-plugin-ci` discards.\nBoth states were invisible from the workflow.\n`scripts/verify_published.py` now queries the public plugin repository after\nevery release and reports whether the released version is genuinely being\nserved, writing a warning annotation and a run summary. It is advisory\nrather than fatal, because approval is a human queue on the QGIS side and a\nred tick for normal moderation latency would just train everyone to ignore\nit. It runs even when the upload step fails, since that is precisely when\nthe current published state is worth knowing. A network failure reports\n\"unknown\", never \"published\".", "external_deps": null, "download_url": "https://plugins.qgis.org/plugins/lidar_relief/version/2.2.1/download/"}