(chiedo scusa, la prima email mi è partita inavvertitamente prima che fosse terminata)
>Quindi Gfoss è una di quelle comunità che mediante la partecipazione
>nazionale di professionisti può creare/dare linee guida per creare un
>sistema di pianificazione territoriale, tramite l'utilizzo di software GIS,
>geodatabase, WebApp tutto OpenSource??? è possibile realizzare per qualche
>Comune pilota, il Piano territoriale comunale Smart City? perchè se solo si
>rendono congruenti tutti i dati relativi alle decine di piani e studi che
>ogni Comune già possiede, sarebbe un successo!
In Regione Toscana ormai da anni disponiamo di una coperture dei confini comunali topologica e multiscala.
La cui realizzazione è stata guidata da un mio collega.
Poi sempre lui, a partire da essa ha guidato la realizzazione di una serie di archivi tra loro congruenti.
A partire dagli ambiti di programmazione, spingendo poi vari enti locali a realizzare i vari piani comunali e provinciali sempre congruenti con essa.
E visto che la cosa aveva un senso ha pure reso congruente con i nostri confini comunali multiscala anche le sezioni di censimento dell’istat del 2001 (oltre che farle topologicamente corrette).
Le sezioni di censimento topologicamente corrette e congruenti con i confini comunali multiscala è una gran cosa, permette di fare calcoli esatti su tantissime questioni.
La ha anche offerta all’ Istat per il successivo censimento.
L’Istat non la ha usata per varie ragioni tecniche, e quindi il nuovo censimento 2011 e’ arrivato con la solita copertura di sezioni di censimento ne’ topologiche ne’ congruenti con i nostri confini comunali, ma bensi’ congruente con i confini comunali dell’istat che ovviamente è una altra cosa.
Il punto è che noi avevamo molti archivi congruenti tra di loro e in seguito ci siamo trovati di fronte al problema di mantenerli, ovvero continuare ad evolverli aggiornandoli e mantenendo sempre questa congruenza. Per cui abbiamo toccato con mano le problematiche anche organizzative di tale questione .
rendere dei dati congruenti tra di loro è una bella cosa, ma poi va manutenuta e li’ cominciano i dolori.
Io stesso ho speso settimane e anche notti a scrivermi codice per cercare di sviluppare delle procedure che permettessero di rendere congruenti nuovi archivi sulla nostra copertura dei confini comunali multiscala.
Tante’ che ho pure scoperto (non sapevo) i limiti delle procedure di snap della Geos (mannaggia a lei).
Comunque sia alla fine ho dovuto rinunciare.
Se due archivi non sono congruenti tra di loro , diviene molto difficile ricondurre uno dei due a essere congruente con l’altro senza doverci spendere giorni uomo di un operatore a fare copia/incolla di singoli tratti.
Diviene quindi ovvio dire che un nuovo archivio dovrebbe nascere gia’ congruente con l’archivio di riferimento.
Questa affermazione sembra ovvia e banale. E invece non lo e’ per niente (sigh).
Purtroppo l’ìimpiego di determinati strumenti altera inevitabilmente il dato originale e di conseguenza si perde la congruenza.
Dietro questa frase sibillina si nasconde una realta’ complicata.
Se te mandi dei dati congruenti a giro per farli editare da altri soggetti e questi soggetti impiegano determinati softwares,
se non vengono usati con ASSOLUTA COMPETENZA e con una chiara percezione di quello che fanno.
Si ha il risultato che quasi tutti i vertici subisco degli impercettibili spostamenti (pochi millimetri), roba di per se’ risibile, ma che fanno perdere la proprieta’ assoluta della congruenza.
Per cui a mio parere la congruenza al momento è una bella cosa, ma finisce per essere un costo abnorme.