From a legal rule to an open spatial protocol
A rule is not yet a procedure
I work with geospatial analysis, but I am increasingly interested in a wider question: how do we turn a public rule into a process that people can inspect, repeat and improve?
A legal norm may define a distance, threshold or restriction. That still leaves a practical gap. Which data should be used? How is the shoreline represented? How is terrain measured? Can another analyst reproduce the result? If those choices remain inside a closed expert procedure, the public sees a boundary but not how it was made.
My proposal is modest: where a rule has measurable spatial parameters, we can publish its implementation as an open protocol—the instructions, data, algorithm, software model, metadata, tests, limitations and version history needed to examine the calculation.
Why use riparian protective strips?
Ukrainian water and land legislation describes minimum widths for riparian protective strips and a terrain condition under which the minimum width is doubled. The current official texts are available in the Water Code of Ukraine and the Land Code of Ukraine.
This makes the subject useful for testing an open protocol: the rule contains measurable concepts, but its spatial application depends on data quality, scale, shoreline geometry and an explicit calculation procedure.
The result presented here is an analytical screening layer. It is not an official or legally established boundary, does not classify land rights, and does not replace land-management documentation or a competent authority’s decision.
What I tested
For this portal case I used the lighter of two real test datasets so the whole workflow can run on the nettop and remain practical to download:
- a 5.457 km² area of interest;
- a 1 m digital elevation model;
- 42 polygonal and 10 linear water features;
- elevations from 128 to 216 metres;
- source CRS EPSG:5564 (UCS-2000 / Gauss-Kruger zone 6).
The source water attributes do not legally classify every object. I therefore use 50 metres as a visible test parameter, matching the saved example in the model, rather than claiming that 50 metres is the correct statutory width for every feature in the dataset.
Explore the result
How the calculation works
The published derivative follows the method described in the source repository:
- Convert polygonal water objects and buffered linear water objects into a common shoreline representation.
- For every valid terrain pixel, find the nearest shoreline pixel and its elevation.
- At the 50 m ring, compare terrain elevation with the nearest shoreline elevation.
- Flag shoreline pixels associated with a rise greater than the tangent of 3°.
- Keep the standard 50 m screening band everywhere and selectively extend it toward 100 m where the terrain test is triggered.
- Publish the result as a classified GeoTIFF and as GeoPackage and GeoJSON vectors.
The run produced 0.756 km² of standard-width screening zone and 0.411 km² of additional slope-triggered extension. These figures describe this input version and these parameters—not a generally applicable legal result.
The original QGIS model is redistributed unchanged. It uses ProjectCrs and @project_folder, so command-line reproduction requires a QGIS project in EPSG:5564. For the web derivative I also publish a faster array-based build script implementing the documented distance, elevation and threshold steps.
Data, tools and source
The complete resource record provides the original archive, individual DEM and water files, derived raster and vectors, QGIS model, theory note, metadata, checksums and reproducibility script.
The method’s working source, step-by-step explanations and issue history remain in the oleksaboiko/pzs_method GitHub repository.
Attribution: method, data publication and QGIS tool by Oleksii Boiko and Yuliia Maksymova, version 1.0.0, licensed under CC BY 4.0.