Dati congruenti - ex Smart City: al via la consultazione pubblica telematica

[Andrea Peri]

(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.


--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------


_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

[a.furieri]

On Sun, 15 Jul 2012 15:39:26 +0200, Andrea Peri wrote:

> 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).
>

e questa e' la vera "maledizione" intrinseca nei dati geo-spatial
altamente strutturati.
in pratica ciascun dataset complesso ed articolato deve essere
totalmente
auto-consistente dalla A fino alla Z; e spesso deve essere consistente
anche con datasets distinti ma strettamente correlati.
se introduci una falla / smagliatura da qualche parte, poi diviene
quasi
impossibile tornare ad una situazione di perfetta coerenza.
a meno di non impiegare un sacco di "olio di gomito", che ovviamente
costa un sacco di tempo e di soldi.


> 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.
>

per mia esperienza personale e diretta, direi che forse e' ancora piu'
complicato.
se tutte le modifiche, aggiunte, correzioni etc non vengono apportate
direttamente sul medesimo unico sistema di storage unificato
(possibilmente
un unico spatial DBMS condiviso da tutti gli attori, e che implementi
in
modo "forte" tutti i controlli di coerenza e di consistenza) e'
praticamente
inevitabile arrivare velocemente a modifiche contrastanti che non
possono
poi essere facilmente ri-acquisite a ritroso senza provocare danni
gravi
cha invalidano completamente la coerenza globale.

esempio classico: i grafi stradali, dove una assoluta auto-consistenza
e' tassativamente indispensabile.
se molti attori operano indipendentemente (e magari con sistemi
eterogenei)
per correggere il grafo, alla fine del processo non si ottiene affatto
un
grafo "migliorato".
si ottiene semplicemente una lunga catena di fork, che portano ad avere
enne versioni distinte del grafo di partenza (una per ciascun attore)
che
non sono piu' reciprocamente compatibili.
... a meno di non sobbarcarsi di un mostruoso lavoro manuale per
riaggregarle tutte quante in un contesto unitario.

N.B.: questo stato di cose IMHO andrebbe valutato accuratamente quando
si parla di license CC-BY-SA per i dati geo-spatial.
lo "share alike" garantisce si che tutte le modifiche apportate debbano
essere condivise, ma di per se non e' affatto condizione sufficiente
per
garantire che esse potranno essere facilmente incorporate nel dataset
originario di partenza (almeno, affrontando costi ragionevoli).

> 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.
>

a meno di non adottare un approccio come quello supportato p.es. da
Open Street Map: un unico repository / database centralizzato ed
"ufficiale", uso tassativo di pochi strumenti "fatti apposta";
allora si che diventa possibile fare cartografia "cooperativa"

probabilmente un impiego piu' esteso di protocolli come il WFS-T
potrebbe dare una mano utile in questo settore, perche' consentirebbe
effettivamente a molti attori "community" di operare indipendentemente
ed autonomamente, ma pur sempre nei confronti di un unico DBMS
centralizzato.

ciao Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012