From article to assessment: a connected pilot

Geoportal Pilot — Sat, 15 Aug 2026 21:00:00 GMT

Short finding

A useful geospatial publication should let readers move from interpretation to the exact source data—and let practitioners reuse a recorded source version in a structured assessment. This pilot demonstrates that connection with artificial data.

Warning

The three demonstration zones are synthetic. They are not measurements, administrative boundaries, or evidence for a real environmental decision.

Explore the territory

Open the geostory in a separate local view

Method

Three non-overlapping polygons were written as GeoJSON in EPSG:4326.
Existing GDAL tools on the nettop validate the source.
The build creates GeoPackage and CSV/WKT distributions.
SHA-256 checksums identify the exact downloadable files.
Django registers version 1.0.0 as an immutable catalogue record.
A SEA project can reference that exact version and retain the relationship.

Data and reproducibility

Limitations

The current geostory is a lightweight, dependency-free local export so the interface works before Docker is installed. When GeoLibre becomes available, the same versioned data and narrative should be recreated there and exported back into this site.

The pilot does not claim legal completeness, regulatory compliance, or fitness for a real SEA.

From a legal rule to an open spatial protocol

Oleksii Boiko — Sat, 15 Aug 2026 21:00:00 GMT

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.

Warning

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

Open the geostory full screen Open the data and tool record

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.

From an expert result to shared infrastructure

The point is not that an algorithm should replace public authority. The state still defines the norm, its legal meaning, official data requirements, procedural safeguards and routes for appeal.

The useful change is that the operational layer can become inspectable. Analysts can challenge a parameter. Data holders can improve the inputs. Communities can see where uncertainty enters. Developers can report a software problem. Each correction can create a new, traceable version rather than an unexplained replacement.

That is what I mean by an open spatial protocol: not government by software, but a shared technical object around which public reasoning can happen.

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.