Rilievo di reti di sottoservizi

Ricostruire la topologia di una rete interrata anche dove il rilievo non arriva

Ruolo

progettazione, sviluppo e test

Alto Trevigiano Servizi è un gestore di servizi idrici del trevigiano. Il progetto riguarda il rilievo sul campo delle sue reti di fognatura nera e mista: un operatore gira i pozzetti di ispezione con un tablet e compila un form per ciascuno, e da quei form il sistema ricostruisce la topologia dell'intera rete. Il software l'ho sviluppato da solo, a Spazio Verde S.r.l., dove allora lavoravo come dipendente.

la dimensione del rilievo

Il rilievo copre 20 comuni e circa 12.000 pozzetti di ispezione, con una densità di circa 25 pozzetti per chilometro di rete. È un volume che rende impraticabile qualunque verifica manuale della coerenza: la topologia deve emergere dal calcolo, non da un controllo a occhio fatto pozzetto per pozzetto.

i nodi che nessuno rileva

Una rete non si ricostruisce sommando i pozzetti rilevati. Capita spesso a un incrocio: una condotta secondaria si unisce a quella principale in un punto dove il gestore non ha mai messo un pozzetto di ispezione. Il punto di unione esiste, sotto terra, ma nessun rilievo lo attraversa da vicino. Il sistema deve stimarlo, dedurlo dalla geometria delle condotte che arrivano da direzioni diverse: senza quel nodo, i due tratti restano due spezzoni scollegati sulla mappa.

Un secondo caso nasce da un motivo diverso: una condotta cambia materiale o diametro a metà tratta, in un punto senza pozzetto da cui guardare. Anche lì serve un nodo, costruito e non rilevato, perché la rete resti coerente da un capo all'altro.

La base di partenza non aiutava. Le planimetrie fornite erano definite indicative, con la possibilità dichiarata di essere mancanti o sbagliate. Il modello doveva quindi colmare dei vuoti e reggere una mappa di partenza che poteva essere imprecisa.

dal campo al database

Ogni pozzetto porta anche una posizione GPS, rilevata in ETRF2000 e convertita in Gauss-Boaga fuso ovest. Il backend è scritto in PHP con Doctrine, su un database con una nomenclatura che ricalca quella di Access. La scelta è arrivata dal committente, che chiedeva la consegna dei dati in formato shape e mdb: il database ha seguito quella nomenclatura fin dall'inizio, invece di tradurla solo in uscita.