Regione Toscana. GeoSisma Documentazione tecnica Marzo 2011

Transcript

1 Faunalia piazza Garibaldi Pontedera (PI) info@faunalia.it p. IVA: Regione Toscana GeoSisma Documentazione tecnica Marzo 2011 Indice GeoSisma...1 Documentazione schematica applicazione...2 Tecnologie e framework impiegati...2 Principali componenti...3 Autenticazione e autorizzazione...3 Gestione anagrafica utenti...4 Gestione Eventi e Squadre...5 Gestione schede...6 Richieste...7 Dati geografici consegna-geosisma-architettura.odt Piazza Garibaldi, Pontedera PI

2 Documentazione schematica applicazione L'applicazione Geosisma (da qui applicazione ) è una applicazione web finalizzata alla organizzazione della raccolti dati relativa ai rilievi di danni causati da eventi calamitosi. Tecnologie e framework impiegati L'applicazione è realizzata con il linguaggio di scripting Python, rendendola per altro portabile su diversi sistemi operativi, tra cui Linux ma anche Windows. Per la realizzazione dell'applicazione sono stati impiegati: Turbogears 2 framework Python per applicazioni web, basato su Pylons e quindi anche WSGI compatibile, basato sul design pattern MVC. Genshi motore template. SQLAlchemy - ORM per l'accesso ai dati, rendendo l'applicazione indipendente dal RDBMS utilizzato. È dunque possibile utilizzare l'applicazione con backend database come Postgresql, Mysql, Sqlite e altri. Per lo sviluppo, test e verifica, ma anche per e prove sul campo, è stato impiegato un database Sqlite. Postgresql - il database Postgresql, utilizzato tramite l'orm SqlAlchemy, viene utilizzato per contenere il dati geografici. OpenLayers - componente software Javascript, per l'interazione con MapServer e i relativi dati geografici offerti. 2/7

3 Principali componenti Autenticazione e autorizzazione Le procedure di autenticazione e autorizzazione vengono gestiste tramite il framework Python repoze, che consente l'aggiunta di nuovi criteri di autenticazione diversi (es. LDAP, SmartCard etc). Attualmente il sistema di autenticazione si appoggia, per default, sulla base di dati. Avendo un eventuale archivio centralizzato delle utente di questa tipologia di applicazione, può essere possibile integrarlo successivamente. Per le procedura di autenticazione invece, gestita sempre tramite il framework repoze, è strutturata in duplice modalità RBAC e MAC. Talune operazioni sono consentite dal sistema basandosi sul Ruolo dell'operatore, mentre altre vengono consentite tramite una assegnazione diretta del permesso verso l'utente collegato all'operatore. Non sono previste funzionalità di accesso per utenze anonime, salvo la risorse iniziale con contenuti istituzionali. L'assegnazione del ruolo o dei singoli permessi sono effettuate tramite la modifica del profilo utente nel primo, e tramite controller di gestione dedicato per il secondo. Il modello logico della struttura database relativa alla gestione RBAC è illustrata nel seguente diagramma: Gestione anagrafica utenti L'applicazione permette una gestione completa dell'anagrafica degli operatori impegnati nelle attività, che mantengono la propria utenza nel tempo, indipendentemente dalla partecipazione o meno ad eventi. L'anagrafica include anche le abilitazioni conseguite, in modo da suggerire la 3/7

4 creazione di squadre di utenti in base alle competenze personali, e l'agenzia a cui l'operatore è associato (ente pubblico o altro). La struttura dati relativa all'anagrafica utenti è illustrata nel seguente diagramma: 4/7

5 Gestione Eventi e Squadre L'applicazione permette di creare una attività a seguito di un evento sismico o altro evento che necessita l'attività di sopralluogo e valutazione. Un evento è caratterizzato da una descrizione e un intervallo temporale che rappresenta il periodo di attività relativa ai rilievi (altra informazione che può essere utilizzata per limitare l'accesso o meno al materiale relativo all'evento). All'interno di un evento si possono creare le squadre attive, ognuna con una o più persone all'interno. Le squadre sono sempre associate all'evento, e non vengono riutilizzate in eventi successivi. Il modello logico della struttura dati è rappresentato dal seguente diagramma: 5/7

6 Gestione schede Per ogni evento, ciascuna squadra compila una o più scheda relativa al sopralluogo effettuato. Attualmente sono previste schede di agibilità e vulnerabilità degli edifici. La struttura modulare consente l'aggiunta futuro di altri tipi di schede rilievo. Le schede contengono un blob serializzato JSON che rappresentano i dati presenti nel form. Altri dati sono invece parte integrante della tabella. Questa soluzione è stata adottata per evitare di avere tabelle di dimensioni eccessive, permettere una flessibilità sulla quantità tipologia di campi, e avere al tempo stesso la possibilità di applicare indici sulle colonne dove vengono effettuate ricerche. Le schede di agibilità possono avere uno o più file allegati, presenti in apposita struttura dati. Il seguente diaramma illustra la struttura dati delle schede di agibilità (report) e vulnerabilità (vuln_report) e relativi file allegati. Richieste Il sistema permette l'inserimento, tramite apposita maschera, delle richieste di sopralluogo pervenute. Queste, associate alle varie squadre, permettono di assegnare direttamente l'attività da svolgere, permettendo anche la precompilazione di alcuni aspetti delle schede di rilievo (indirizzo, città, etc) 6/7

7 Dati geografici Il database geografico contiene dati relativi a confini, comuni, province, numeri civici e sopralluoghi effettuati. Oltre a questi, sono presenti dati catastali ISTAT, per permette all'operatore di rilevare in modo automatico dati relativi alla scheda di agibilità, secondo la logica del 'search as you type' e autocompletamento, a partire dai dati indicativi di edificio. Questi dati vengono caricati da sorgenti esterne, e non hanno relazioni. Vengono utilizzati esclusivamente ai fini di ricerca e autocompletamento. Fanno eccezione i dati relativi ai sopralluoghi, che vengono inseriti tramite un'applicazione esterna (QuantumGIS) direttamente in database. 7/7