Mario Marino

progettista e sviluppatore di applicativi gestionali e sistemi basati su LLM

Rilievo di reti di sottoservizi

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

Periodo
2016 – 2018
Ruolo
progettazione, sviluppo e test
Ambito
rilievo sul campo e ricostruzione di reti interrate
Tecnologie
PHP · Doctrine · MySQL · JavaScript · GPS ETRF2000

a cosa serve

Chi gestisce una rete di fognatura deve sapere dov'è. Sembra ovvio e non lo è: la rete è sottoterra, è stata costruita in decenni diversi da imprese diverse, e le planimetrie che il gestore possiede sono spesso una ricostruzione a posteriori. Finché non serve intervenire, la differenza fra la mappa e il terreno non si vede.

Si vede quando qualcuno deve scavare. Allora la domanda diventa dove passa la condotta, che diametro ha, in che verso scorre e dove finisce — e una planimetria dichiarata indicativa non risponde a nessuna delle quattro.

cosa fa

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.

La parte che conta non è il form: è il passaggio da un elenco di punti a una rete. Un pozzetto rilevato dice cosa si vede da quel pozzetto — le condotte che vi entrano e ne escono, con diametro, materiale e quota. La rete è quello che sta in mezzo, e in mezzo nessuno è sceso.

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.

Il numero cambia anche la natura degli errori accettabili. Su cento pozzetti un caso strano lo si guarda e si decide; su dodicimila, ogni caso strano deve avere una regola, perché nessuno li aprirà uno per uno.

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.

pozzetti di ispezione, rilevati uno per uno cambio di materiale nodo dedotto dalla geometria: nessun pozzetto lo attraversa i punti pieni sono rilevati, i cerchi tratteggiati sono calcolati. Senza questi ultimi la rete resta un insieme di spezzoni scollegati
La rete che si consegna contiene nodi che nessuno ha visto. È la ragione per cui ciascuno porta scritto come è stato ottenuto: chi la userà deve poter distinguere un dato rilevato da un dato dedotto.

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.

È la ragione per cui il sistema non prova a correggere la planimetria con il rilievo, né il contrario: le tiene come due strati distinti. Sovrapporli in un dato solo avrebbe prodotto una mappa più bella e meno vera, dove nessuno avrebbe più saputo quale delle due fonti stesse guardando.

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.

Vista da fuori è una scelta discutibile, e va spiegata perché è deliberata. Un database con nomi propri e una traduzione in fase di export è più pulito, ed è quello che si farebbe normalmente. Qui il prodotto della commessa non era il database: era il file consegnato, e il file lo apriva qualcun altro con i suoi strumenti. Tenere due vocabolari avrebbe messo un passaggio di traduzione fra ciò che si controlla durante il rilievo e ciò che il committente verifica alla consegna — e quel passaggio è esattamente il posto dove un campo si perde senza che nessuno se ne accorga fino al collaudo.

limiti dichiarati