Claudio Mazzi. Le buone pratiche per la strutturazione dei dati

Transcript

1 Claudio Mazzi Le buone pratiche per la strutturazione dei dati

2 La realizzazione di un DBGT secondo le Specifiche previste dal DM 10/11/2011, come conseguenza dell'aumento di importanza dei contenuti informativi, richiedono sia alle Amministrazioni che lo progettano, sia ai soggetti incaricati di realizzarlo, una particolare attenzione alla strutturazione delle operazioni di "editing". Si vogliono qui evidenziare alcune delle "buone pratiche" messe a punto nel corso delle diverse attività di produzione di DBGT seguite dal Gruppo di Supporto del CISIS-CPSG, sia come attività sperimentali che come produzione di dati regionali.

3 La lettura della Specifica Fondamentale per la realizzazione del DBGT conforme al DM 10/11/201, è la comprensione della struttura della Specifica, che va intesa non come un semplice "catalogo di oggetti", ma come un vero e proprio schema concettuale del DB da realizzare.

4 La comprensione delle Classi Dalla lettura analitica della Specifica bisogna arrivare alla comprensione che le classi di oggetti definite sono tra loro interlacciate, sia come oggetti derivati gli uni dagli altri (p.es. le aree di circolazione compongono le aree stradali, che a loro volta compongono le geometrie delle estese amministrative), sia come oggetti vincolati gli uni agli altri, sia logicamente che geometricamente.

5 La comprensione dei vincoli (necessità di analisi tramite il catalogue) I vincoli che legano tra di loro le varie Classi non sempre sono immediatamente comprensibili dalla lettura della Specifica in linguaggio naturale; la lettura della stessa attraverso il GeoUML Catalogue consente una più approfondita comprensione della definizione e della strutturazione dei vincoli e dei ruoli che interconnettono tra loro le diverse Classi.

6 La scelta del MI di produzione e di quello di gestione Il MI di produzione dipende in larga misura dalla mole di informazioni da inserire nel DBGT, nonché dalle tecnologie utilizzate per la produzione dei dati in fase di editing. I MI gestiti attualmente dagli strumenti della GeoUML Methodology sono: MI shapefile MI Oracle MI PostGIS

7 L utilizzo del MI shapefile è stato pensato per la produzione, in modo da consentire di poter produrre e gestire le informazioni rilevate attraverso pressoché ogni piattaforma software (essendo lo shapefile uno standard de facto). L utilizzo del MI shapefile prevede che, per la fase di editing, i produttori realizzino nel loro ambiente software dei progetti di lavoro che ricostruiscano al loro interno le relazioni e i vincoli logici tra i vari shapefile. Naturalmente, per la produzione dei dati a scala minore può essere preferibile avvalersi di MI basati su DBMS, la cui scelta dipende in massima parte dagli Enti Appaltanti (sistemi già di proprietà dell Ente, personale interno già formato sull uso di specifiche piattaforme, volontà strategica di migrazione su tecnologie open-source).

8 Utilizzo dei DBMS in produzione Nel caso in cui si scelga di non utilizzare il MI shapefile, un opzione è di produrre dati direttamente su DBMS. Naturalmente, è necessario disporre di componenti software in grado di interfacciarsi direttamente, in scrittura, con l ambiente DBMS utilizzato. Tale scelta ha come lati positivi diversi aspetti: Ovviamente la possibilità di inserire un numero di oggetti pressoché illimitato La possibilità di operare in editing da parte di più operatori simultaneamente I sistemi di indicizzazione delle informazioni inserite consentono visualizzazioni e modifiche più rapidi Se il DB è stato generato direttamente dagli strumenti GeoUML, tutte le relazioni (chiavi esterne, tabelle di decodifica degli attributi, ecc.) sono già implementate, quindi si avrà una sostanziale riduzione della possibilità di errori di codifica Inoltre, anche in quest ultimo caso è possibile utilizzare il GeoUML Validator direttamente sul DB di produzione

9 Un altro vantaggio di utilizzare in produzione tecnologie DBMS è quello di poter tenere costantemente sotto controllo la validità delle strutture geometriche, utilizzando le normali funzioni spaziali integrate nelle stesse piattaforme. Possono così essere evitate o identificate e corrette rapidamente geometrie non valide, geometrie a lunghezza o area nulla, geometrie sotto soglia, vertici ridondanti, ecc.

10 È bene ricordare che, per i sistemi DBMS spaziali, valgono le regole del SFDM. Quindi, geometrie poligonali come in figura, devono essere costruite come un poligono ed un buco, e non come un poligono il cui confine si autointerseca. Nello shapefile (e per i sistemi ESRI), entrambe le soluzioni sono valide, mentre il GeoUML Validator richiede che siano conformi al SFDM. POLYGON (( , , , , , , , , , )) POLYGON (( , , , , , ), ( , , , , ))

11 La copertura topologica Il DM 10/11/2011 richiede espressamente che sia garantita la copertura topologica continua e completa. Il GeoUML Validator, nel verificare la continuità e la completezza della copertura, prevede tolleranza zero nella coincidenza dei vertici degli oggetti adiacenti. Se da un lato il completamento del popolamento degli attributi, in produzione, può essere rimandato ad una fase successiva, con l utilizzo di informazioni provenienti da altre fonti, la copertura geometrica del DBGT dovrà comunque essere topologicamente corretta.

12 Allo stesso modo, dovranno essere garantite le coincidenze tra gli elementi lineari ed i confini dei poligoni, ove questo sia previsto dalla Specifica

13 La terza dimensione Il DM 10/11/2011 richiede che i dati geografici prodotti siano rilevati anche altimetricamente. È quindi di fondamentale importanza la costruzione e l utilizzo di un modello 3D, sia esso realizzato da dati fotogrammetrici, LiDAR, ecc., sul quale "poggiare" le geometrie. Il GeoUML Validator verifica la congruenza 3D tra gli oggetti delle Classi vincolate e quelle vincolanti.

14 Gli edifici È bene accennare ad uno dei problemi maggiori che si incontrano in fase di produzione dei dati, a prescindere dai MI e dalle tecnologie utilizzate, ovvero la definizione spaziale degli oggetti delle Classi "Edificio" ed "Edificio minore". In restituzione si ottengono le unità volumetriche ed i cassoni edilizi.

15 Vi è dunque la necessità di individuare dei criteri che consentano di raggruppare le unità volumetriche, o di suddividere i cassoni edilizi, in edifici, per rispettare la Specifica che definisce: è individuato tramite dividenti di tipo architettonico riconoscibili o da evidente "variazione architettonica" o, in strutture omogenee, da evidenti elementi della facciata (differente colore, etc.). Ad oggi, la strada più seguita è di effettuare l'individuazione degli edifici in base alla ricognizione sul campo, con un notevole impiego di risorse a fronte di risultati non sempre validi, spesso per la difficoltà di accesso alle aree interne dei fabbricati.

16 Tra le varie strade percorribili, si può fare ricorso ad informazioni esterne: Sono a disposizione delle Regioni le ortofoto AGEA, che vengono aggiornate ogni tre anni. Già dalla fotointerpretazione delle caratteristiche dei tetti è possibile distinguere caratteristiche costruttive o cromatiche differenti.

17 È da ricordare che, in base all'accordo quadro di collaborazione tra il CISIS ed AGEA, quest'ultima mette a disposizione delle Regioni le varie coperture ortofotografiche, per tutte le esigenze delle Amministrazioni, compresa la possibilità di poter effettuare aggiornamenti speditivi di aree o di Strati del DBGT.

18 Possono essere utilizzate foto oblique che, permettendo di visualizzare l'insieme delle strutture, permettono di individuare le facciate degli edifici e di associarle alle strutture lontane dal fronte stradale; se non sono disponibili foto oblique realizzate ad hoc, risultano molto utili anche le visualizzazioni panoramiche di Google Maps e di Bing Maps.

19 Un'altra strada, che ha già fornito buoni risultati, consiste nell'utilizzo dei fabbricati catastali, che specie in ambito urbano consente di raggruppare le unità volumetriche in maniera agevole.

20 Qualità intrinseca Infine, è da ricordare che, sebbene spesso non siano specificate nei capitolati, le distanze minime tra i vertici, le dimensioni delle unità minime cartografabili, il numero massimo di vertici delle singole geometrie sono fattori da tenere sotto controllo costante da parte dei produttori di dati cartografici, quanto meno a livello di "buon senso" in relazione alla scala di restituzione. È infatti inammissibile, allo stato attuale delle tecnologie di restituzione e di digitalizzazione, la produzione (e la consegna) di dati geometricamente "sporchi" e sovraccarichi; tali dati, infatti, oltre ad avere alte probabilità di essere rifiutati dalle Stazioni Appaltanti, appesantiscono enormemente le operazioni di controllo della qualità, sia da parte dei collaudatori che delgli stessi produttori. Sono inoltre di difficile utilizzo applicativo, in quanto la loro "pesantezza" si riflette sia sulle elaborazioni successive, venendo replicata su tutte le informazioni derivate, sia sui servizi, con il rallentamento delle operazioni lato server, come i servizi WMS e WFS.