Giuseppe Pelagatti Milano, 6 aprile 2011 Aggiornamento Data Base Topografico Armonizzazione e Interscambio tra CST e Regione

© Pelagatti Giuseppe INDICE 1.Richiamo dell’impostazione generale 2.Definizione dei contenuti e formato di interscambio 3.Lotti di aggiornamento 4.Controlli di integrità e produzione di metadati di istanza 5.Aggiornamenti al confine tra diversi gestori 6.Allineamento iniziale tra DBTL e DBTR e realizzazione dell’estrattore 7.Proposta di un modo di procedere 2

© Pelagatti Giuseppe 1. Impostazione generale Capitolo 5 e Approfondimento tecnico N. 4Capitolo 5 e Approfondimento tecnico N. 4 – Architettura di riferimento –Il Database Topografico della Regione (DBTR) contiene una rappresentazione dell’intero territorio regionale –il territorio regionale è suddiviso in porzioni disgiunte –Il DBTR può essere concettualmente suddiviso in altrettante porzioni, senza violare la continuità della rappresentazione territoriale –Ogni porzione è gestita da un «Gestore» (possibilmente un CST) –Ogni Gestore possiede un proprio database locale (DBTL) –Il Gestore organizza il proprio DBTL autonomamente, sia come tecnologia che come strutturazione –Il DBTL deve contenere i dati che, opportunamente ristrutturati, costituiscono la porzione di DBTR di riferimento del Gestore

© Pelagatti Giuseppe Il DBT locale (DBTL) L’insieme degli shapefile di produzione NON costituisce un DBT locale Per ottenere un DBT locale è necessario caricare gli shapefile in un sistema di gestione dei database, ad esempio: –ESRI SDE + DB relazionale –Oracle Spatial –Postgis –ecc…. La creazione di un DBT richiede di progettarne e definirne lo schema (schema fisico locale) e poi di caricarvi i dati La progettazione dello schema fisico locale normalmente è guidata dagli scopi applicativi del DBT Le applicazioni si basano sulla conoscenza di tale schema, quindi non è semplice cambiare lo schema di un sistema utilizzato da molte applicazioni I dati che vengono condivisi nella IIT dovranno essere presenti nel DBTL, ma in generale il DBTL conterrà altri dati Molti sistemi permettono di caricare un insieme di shapefile ottenendo automaticamente uno schema

© Pelagatti Giuseppe Funzionamento della IIT DBTL di un gestore Gx ESTRATTORE DBTL di un gestore Gy ESTRATTORE DbTR Formato di interscambio Aggiornamenti locali Aggiornamenti locali porzione x porzione y Lotto di Aggiornamento Interfaccia Dati Regolata (si appoggia sui protocolli di comunicazione) tecnologia locale (diversa da quella regionale) contenuti locali (includono quelli condivisi)

© Pelagatti Giuseppe «Inizializzazione» dei DBTL Al momento della Adesione di un Gestore alla IIT deve essere creato uno stato iniziale corretto Lo stato iniziale deve garantire l’allineamento tra i dati del Gestore e la corrispondente porzione di DBTR La «porzione di DBTR» possiederà le seguenti caratteristiche: –Dati armonizzati geometricamente ai confini con altre porzioni, gestite da Gestori che hanno aderito precedentemente –Dati armonizzati con dati di CT10, con individuazione degli «Oggetti Globali» (ad esempio, strade extraurbane, grandi laghi, ecc…) –Eventuali altre correzioni apportate nella fase di caricamento dei dati in DBTR Se queste caratteristiche sono state introdotte da Regione sul DBTR, è necessario che le modifiche vengano riportate sui dati locali, cioè nei DBTL 6

© Pelagatti Giuseppe 7 2. Definizione dei contenuti e formato di interscambio Per questo problema è stata utilizzata la metodologia e gli strumenti definiti congiuntamente dal CISIS e dal Polimi con un progetto al quale partecipa anche RL: GeoUML Methodology I principi fondamentali della GeoUML methodology sono: 1.separare la definizione più astratta (concettuale) dei contenuti dalle strutture fisiche utilizzate per rappresentarli 2.definizione di proprietà dell’informazione tramite vincoli sullo schema concettuale Gli strumenti della GeoUML Methodology sono 2: –GeoUML Catalogue –GeoUML Validator

© Pelagatti Giuseppe 8 GeoUML catalogue e DBTR della RL Schema Concettuale del DBTR (definisce i contenuti condivisi della IIT) GeoUML catalogue

© Pelagatti Giuseppe Schema Concettuale nella IIT DBTL di un gestore Gx DbTR Lotto di Aggiornamento Schema Concettuale (definizione dei contenuti condivisi)

© Pelagatti Giuseppe 10 Passaggio dalle Specifiche concettuali ai dati: Modello Implementativo Schema Fisico (SF): definisce la struttura fisica; esempi: –XSD per un file GML –Create Table per Georelazionale SQL –Struttura degli Shapefile Modello Implementativo (MI): è un insieme di Regole che permettono di generare uno SF da uno SC

© Pelagatti Giuseppe 11 Generazione dello schema fisico dal Catalogue GeoUML Catalogue SC del DBTR Mapping Generator MI Shape Lotto di Aggiornamento : contenuto: SC del DBTR formato: struttura Shape altri Mapping Generator

© Pelagatti Giuseppe Schema Concettuale e MI nella IIT LDbT di un gestore Gx DbTR Lotto di Aggiornamento Schema Concettuale (definizione dei contenuti condivisi) MI shape (formato di trasferimento)

© Pelagatti Giuseppe Controlli sul LA potranno essere adattate le attuali procedure di controllo per applicarle sui LA inoltre si potrà utilizzare il GeoUML Validator per controllare proprietà dichiarate a livello dello schema concettuale

© Pelagatti Giuseppe Lotti di Aggiornamento (minimi) E’ un’area la cui frontiera deve rimanere inalterata nell’aggiornamento Ottenibile come inviluppo di tutti gli oggetti che circondano gli oggetti esplicitamente aggiornati Nell’ambito dell’area del LA nel DBTR verrà sostituito tutto il contenuto, riconoscendo e «storicizzando»: –oggetti preesistenti (importanza di gestire l’identificatore) –oggetti che vengono eliminati –oggetti nuovi che vengono creati

© Pelagatti Giuseppe Problemi di precisione -1 differenza tra Accuratezza e Risoluzione (interna) Accuratezza: –riguarda la precisione del rilievo –è tipicamente dell’ordine di Risoluzione interna: –riguarda la precisione della rappresentazione interna delle coordinate –con dati rappresentati in FP64 può arrivare a su tutto l’extent nazionale 15

© Pelagatti Giuseppe Problemi di precisione -2 E’ importante che la Frontiera dei LA resti immutata per permettere un inserimento topologicamente corretto nel DBTR è impossibile evitare (in un sistema eterogeneo) che nelle trasformazioni tra DBTL, formato di interscambio e DBTR le coordinate subiscano delle variazioni E’ necessario garantire che tali variazioni siano sufficientemente piccole da poter riconoscere la corrispondenza con i vertici preesistenti A questo scopo devono essere definiti dei valori di precisione dei DBT e dei formati di interscambio (sembra ragionevole un valore intorno a ) 16

© Pelagatti Giuseppe 4. Controlli di integrità e produzione di metadati di istanza E’ stata definita una struttura di «Metadati di Istanza» Un metadato di istanza caratterizza analiticamente il singolo oggetto del DB (a differenza dei metadati di prodotto) Alcuni Metadati di Istanza devono essere esplicitamente indicati dal produttore (ad esempio, l’accuratezza del rilievo) Altri Metadati di Istanza possono essere prodotti automaticamente da procedure di controllo (ad esempio, la corretta copertura del suolo) La completezza dei contenuti del LA permette di eseguirvi sopra dei controlli automatici e di produrre la metainformazione di istanza 17

© Pelagatti Giuseppe Riassumendo La definizione dell’interfaccia dati regolata della IIT è costituita da: 1.Schema concettuale dei contenuti condivisi (DBTR) 2.Modello implementativo Shape 3.Regole di delimitazione del lotto di aggiornamento 4.Regole relative alla precisione 5.Metadati di istanza che devono essere trasferiti dal livello locale a quello regionale

© Pelagatti Giuseppe 5. Aggiornamenti al confine tra diversi gestori Il problema può essere trattato in diversi modi, anche in base ai rapporti di collaborazione che potranno essere istituiti tra diversi gestori due casi limite (a titolo di esempio, perché il problema è da studiare): –i 2 gestori si fanno carico di produrre un LA integrato, la cui area è a cavallo dei due territori gestiti (gli oggetti di questo LA avranno diverse ownership, ma il LA integrato ha le «autorizzazioni sufficienti) –l’aggiornamento della linea di separazione del LA in due sottolotti viene certificata opportunamente, e i due sottolotti sono caricati separatamente nel DBTR 19

© Pelagatti Giuseppe 6. Allineamento iniziale tra DBTL e DBTR e realizzazione dell’estrattore Questo problema deve essere affrontato in maniera differenziata in base alla situazione dei gestori, distinguendo in particolare i seguenti casi: Gestori che hanno già un DBTL – i problemi di allineamento devono essere studiati caso per caso, distinguendo i seguenti sottocasi: –DBTL già utilizzato con procedure applicative –DBTL creato come caricamento di shape di produzione, ma non ancora utilizzato da procedure applicative Gestori che devono ancora creare il DBTL e quindi possono partire dai dati corretti a livello regionale 20

© Pelagatti Giuseppe 7. Proposta di un modo di procedere Riunione del 27 aprile: –presentazione dei contenuti del DBTR –presentazione del formato di interscambio –presentazione della struttura dei metadati di istanza –proposta e discussione delle regole di precisione –raccolta delle osservazioni, proposte, ecc…(estesa alle settimane successive) Incontri singoli per l’allineamento e l’estrattore dei DBTL già creati e operativi Riunione del 18 maggio: –opzioni per la creazione dei nuovi DBTL –discussione delle osservazioni e tentativo di consolidamento 21

© Pelagatti Giuseppe Scheda relativa alla situazione dei DBTL Esiste DBTL con procedure applicative Esiste DBTL, non ancora utilizzato –DBTL è un puro caricamento degli shape di produzione –DBTL è stato progettato appositamente Non esiste ancora il DBTL - Si hanno preferenze tecnologiche