Jens/geointel
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(scope): make Belgium and North Sea operational default
GeoIntel release gates / Compile, test, contracts and builds (push) Canceled after 0s
Details
GeoIntel release gates / Python and npm vulnerability policy (push) Canceled after 0s
Details
GeoIntel release gates / GIS image, SBOM and container scan (push) Canceled after 0s
Details

Browse Source
This commit is contained in:
Codex
2026-07-22 02:11:48 +02:00
parent 46884cbbc9
commit 0aff8e3b8c
61 changed files with 2499 additions and 194 deletions
Download Patch File Download Diff File Expand all files Collapse all files
frontend/README.md
+13 -3
View File
@@ -1,8 +1,12 @@
# GeoIntel Frontend (Sprint 4)
React + TypeScript + MapLibre workbench for regional geographic analysis.
React + TypeScript + MapLibre workbench for Belgium and the Belgian North Sea.
The persisted `Kempen Regional Workbench` is the automatic operational data context. Its datasets are loaded once for the complete official 28-municipality Vlaamse vervoerregio; the operator chooses Mol, another municipality or the complete region as a spatial work-area filter. The primary map no longer asks the user to choose a technical project or region before data becomes usable. Regional population and modern forest snapshots use the same current/evolution flow as Mol, while explicit project selection stays available under advanced management.
The persisted `Belgium and North Sea Workbench` is the unconditional primary
data context whenever it exists. The map opens at national extent and supports
bounded selections across Flanders, Wallonia, Brussels and the legally labelled
Belgian maritime zones. Mol and the Kempen remain selectable golden regression
areas, but are never used as an implicit product boundary or startup fallback.
The Status workspace includes one compact `Actualiteit en versiecontrole`
surface. It separates sources that are current, due for a catalogue review,
@@ -29,7 +33,13 @@ as historical observations.
The user-facing shell is task based: `Kaart`, `Bronnen`, `Kwaliteit`, `Beeldanalyse`, `Downloads`, `Status` and `Beheer`. Internal benchmark projects, raw dataset metadata, provider capabilities, model registry details and QA evidence remain accessible through labelled advanced disclosures instead of competing with the normal workflow.
Detection defaults to the configured local YOLO asset and automatically selects an available raster and active model asset where possible. The model registry and preflight remain honest when PyTorch, Ultralytics, a local model file or a tile manifest is unavailable. The active building profile is operational but remains review-required: its current coverage-aligned benchmark is approximately precision 0.614, recall 0.606 and F1 0.607 over seven positive AOIs, with zero detections in all three pure-empty controls. A reviewed challenger remains inactive because it produced two detections in empty Postel forest.
Detection defaults to the explicitly configured local YOLO asset and
automatically selects an available raster where possible. In production the
asset catalog exposes only the file matching `YOLO_MODEL_PATH`; training,
partial and smoke checkpoints remain on disk but do not become end-user model
choices. The current building benchmark covers seven Mol/Kempen AOIs and is
shown as local validation, not as proof of national model quality. Every other
Belgian or maritime context requires local reference QA before release.
Map-driven building analysis uses the documented footprint-IoU `0.25` and
distinguishes model candidates from verified buildings. It shows persisted