Skip to content

QGIS 4.2, Qt 6. Fibre network operator.

VTT

Technical surveys on the QGIS canvas.

Preparing a fibre survey goes through PostgreSQL, spreadsheets, KML and tablets. Several people plan at the same time. VTT groups that cycle in a QGIS plugin.

v1.0.0 on 21 Oct 2026, status experimental. Field acceptance is still open.

Verified from the repository.

  • 1 Oct to 21 Oct

    Repository created, then v1.0.0

  • 18

    Git commits

  • 81

    Tickets with exit criteria

Synthetic geometry

Loading the scene

Two lines for one multi-SRO segment. The duplicate is visible.

  • Feeder
  • Distribution
  • Shared segment
  • Duplicate
  • Tour
  • Anomaly

01

Scattered inputs

On an FTTH rollout, each study segment is visited, documented, then reconciled with the database. The study stock is in PostGIS. The plan is in files. Returns arrive by email or USB stick. Manager contacts are checked by hand.

A duplicate segment is handled by hand, and so is a scheduling conflict. A return can be lost. On the scene, one multi-SRO segment is drawn twice. After deduplication, one geometry remains.

Synthetic feeder. The marker follows the line.

02

Cycle on the canvas

The plugin runs monitoring, preparation, returns and the next zone. The selected step updates the scene.

Steps
Three fields commit together. If one fails, nothing is written.
  1. Monitoring

    Filters by SRO, state, type and date. Virtualised lists. A segment tied to several SROs is deduplicated. The form holds history, contacts and notes. A batch edit is all or nothing.

  2. Preparation

    Automatic tour names, a calendar shared by planners, and a sector forecast from 08:00 to 18:00. The plugin builds the departure sheet, the contacts, the KML and an offline QField project. IGN roads and railways that cross the zones are packed in. USB transfer falls back to a checked ZIP archive.

  3. Field returns

    The import is simulated before any write. A staging area takes the QField returns, with a coverage statement. An anomaly is settled with an author and a justification.

  4. Recommendations

    The plugin suggests the next zone. Local routing works offline. Six charts track progress. The team journal sends the notifications.

03

Calculation rules

Business decisions are written before the code. A register, DECISIONS.md, records each provisional choice: how the specification is read, the eligibility rules.

Uncertified history does not produce a fictitious curve. An unapproved population does not produce a rate presented as validated.

“A figure on screen, a figure in an export, and a figure checked in acceptance come from the same function.”

Architecture rule.
Two drawings of one shared segment. The copy drops. One geometry remains.

Switch to an uncertified history. Display, export and acceptance stay on the same result.

Displayed

Exported

Tested

The bars are a diagram. Display, export and acceptance read the same series.

04

Module split

compat.py is the only module that calls Qt 6.

  1. domaine/Business rules, no Qt
  2. donnees/PostGIS, imports, staging
  3. services/Use cases, exports, QField
  4. controleurs/Orchestration
  5. modeles/Models shown to the interface
  6. taches/Background tasks
  7. QMLInterface drawn on the map
  8. compat.pyOnly call into Qt 6
  • Versioned SQL migrations.
  • Five PostgreSQL roles, with no login of their own.
  • Reads in REPEATABLE READ READ ONLY. Pagination by value.
  • No secret written by the plugin. No external telemetry.
  • The local diagnostic keeps only codes and measurements.

05

What is verified

The figures below come from the repository. The other points are named, with no value attached.

  • 1 Oct to 21 Oct

    Repository created, then v1.0.0

    2026. Three calendar weeks between repository creation and the release.

  • 18

    Git commits

    The initial import, v0.3.1, is dated 5 Oct 2026.

  • 81

    Tickets with exit criteria

    A batch closes on its exit criteria.

  • 50

    Mount, render, unmount cycles

    Checked in the native QGIS 4 engine.

  • 6

    Monitoring charts

  • experimental

    Status of v1.0.0

    Field acceptance is still open: target QField device, Kizeo form, operator report.

  • Isolated bench

    PostgreSQL

    Transactions, privileges, concurrency, re-imports, restore.

Not published

No figure is shown for these points until they are confirmed.

  • Pending confirmation

    Volumes loaded on the operator database

    Volumes are in the repository. They are not quoted here until publication is approved.

  • Pending confirmation

    Measured gains, adoption, user feedback

    No saved time, headcount or quantified feedback is published in the repository.

  • Pending confirmation

    Award

    No award is documented.

  • Pending confirmation

    A user’s words

    No approved quotation, even an anonymous one.

  • Pending confirmation

    Production deployment

    v1.0.0 is marked experimental. No production rollout is documented.

  • Pending confirmation

    A prototype before 1 Oct 2026

    Git starts on 1 Oct, with a v0.3.1 import on 5 Oct. The absence of an earlier prototype is not confirmed.

Construction log

  1. 1 Oct 2026

    Repository created, first decisions

  2. 5 Oct 2026

    Import v0.3.1

  3. 12 Oct 2026

    Migrations 140/150 on the operator database

  4. 21 Oct 2026

    v1.0.0

Dated milestones from the construction log. The 18 Git commits are not listed one by one.

Between 1 Oct 2026 and v1.0.0, the domain objects were already named: SRO, GC, CCTP, QField returns. Decisions are written before the code.

The same kind of cycle on another network.

The decision diagnostic sets a closed scope. Contact is by email.

The other study: RecoverLand