Sistema Informativo Geografico

Uno dei cardini informativi su cui basare l’azione di governo della pubblica amministrazione in Toscana, è costituito dalla Cartografia Tecnica Regionale alla scala 1:10.000 (CTR 10K) presente su tutto il territorio regionale, e dalla Cartografia Tecnica Regionale in scala 1:2.000 (CTR 2K) rilevata sulla gran parte dei centri urbani.

progetto iter.net “La rete delle strade in rete” promosso da Regione Toscana, che “vuole realizzare una rete di cooperazione diffusa su tutto il territorio regionale, capace di gestire nel tempo gli strati informativi STRADARIO, GRAFO STRADE, INDIRIZZARIO“.

Partendo dai contenuti topografici presenti nella CTR la Regione Toscana ha già realizzato un archivio specifico per la gestione del reticolo stradale denominato “GRAFO STRADE”. Parallelamente alla creazione dello strato informativo rappresentante il reticolo viario vero e proprio, sono stati costituiti due archivi complementari uno riguardante gli stradari comunali (denominato “STRADARIO”) e l’altro la toponomastica complessiva dei comuni comprendente la numerazione civica (denominato “INDIRIZZARIO ”). Il grado di completezza sul territorio regionale degli archivi suddetti è parziale e differenziato tra le tre tipologie.

Prendendo spunto da tale impostazione è sicuramente strategico porsi
l’obiettivo della realizzazione di un sistema informativo distribuito, che completi le informazioni già presenti, le alimenti e le gestisca nel tempo, garantendo un supporto fondamentale per applicazioni in campo di programmazione economica, sociale ed ambientale (Catasto Strade, Trasporto pubblico locale, Protezione Civile, etc.).

iter.net “La rete delle strade in rete”

Il profilo descrive il protocollo utilizzato dal Proxy iter.net, dettagliando le interfacce, i messaggi e le interazioni tra le componenti applicative.

Gli attori da considerare sono quindi:

Proprietario del dato: è colui che dispone del dato ed effettua le modifiche sullo stesso e, partecipando al progetto iter.net, intende condividere tali aggiornamenti attraverso gli strumenti di Cooperazione Applicativa;

Fruitore del dato: è il soggetto che intende acquisire i dati veicolati dal progetto iter.net attraverso CART;

Regione Toscana: è un particoalre Fruitore che ha anche la possibilità di modificare le tabelle di decodifica presenti nei vari proxy iter.net;

Proxy SIL: è il sistema software residente sul NAL del Proprietario del dato configurato in modo da permettere l’invio delle modifiche;

CART: è l’infrastruttura di Cooperazione Applicativa di Regione Toscana;

Il sistema, nel suo complesso, realizza cinque operazioni differenti, tre per lo scenario di invio modifiche dal Proprietario del dato al Fruitore del dato e due per l’aggiornamento delle tabelle di decodifica. Di queste, solo la trasmissione delle modifiche viene invocata direttamente del Proprietario del dato, e solo questa è veicolata tramite un proxy applicativo che definisce uno specifico web service.

• inviaModifiche
• inoltraModifiche
• riceviModifiche
• inviaDecodifiche
• riceviDecodifiche

iter.net – Locking distribuito

Nel contesto di base si inserisce il progetto della Provincia di Firenze che intende interscambiare i dati del grafo stradale con i propri Comuni, realizzando quindi una distribuzione geografica della banca dati iter.net.

Dall’esigenza di regolamentare le modifiche concorrenti nasce la necessità di stabilisre le modalità con cui gli attori afferenti al progetto della Provincia di Firenze si coordineranno per evitare modifiche concorrenti alla stessa banca dati.

Tale obiettivo viene raggiunto utilizzando un punto unico super partes che effettui l’assegnazione dei lock ai vari attori. Tale gestore dei lock (LockManager d’ora in avanti) dovrà obbligatoriamente essere realizzato utilizzando comunicazioni sincrone che consentiranno, tramite lo scambio di poche essenziali informazioni, la gestione dei lock super partes (detti lock di livello provinciale). Il lock avrà efficacia sull’intera area comunale, visto che la base dati del grafo stradale è segmentata proprio a livello comunale. Il Comune sarà quindi l’estensione spaziale minima a cui sarà applicato il lock provinciale. Il LockManager dovrà quindi ricevere, oltre ai dati di autenticazione, anche l’indentificativo del Comune da sottoporre a lock.

In questo modo le operazioni sulla banca dati del singolo Comune saranno serializzate grazie all’acquisizione del lock provinciale.

Si noti che lo stesso meccanismo può essere applicato in altri contesti, ove un ente sovraccomunale, anche diverso da una Provincia, debba orchestrare le modifiche alle porzioni della banca dati di competenza dei singoli Comuni, il che giustifica ulteriormente la redazione della presente RFC, in modo che il processo sia documentato e riutilizzabile.

1. la presenza della banca dati iter.net (grafo stradale e numerazione civica) sia negli Enti Locali (Comuni) che in Provincia;
2. l’orchestrazione delle modifiche alle porzioni di banca dati di competenza in modo da garantire l’accesso in scrittura ad un singolo utente alla volta, evitando problemi di modifiche concorrenti;
3. la replica dei dati modificati tra Comuni e Provincia, in entrambe le direzioni, in modo da tenere allineate le banche dati ad ogni variazione.

I punti precedenti meritano alcuni approfondimenti:

• relativamente al primo punto, la Provincia ha commissionato una modifica al client Iter.GIS di Regione Toscana atta ad ampliare il set di dati gestito. Tramite tale client esteso, effettuando l’installazione presso ogni Ente, sarà garantita la presenza della banca dati iter.net;
• relativamente al secondo punto, il client Iter.GIS già prevede un meccanismo di gestione del locking a livello di singola installazione, quindi tale client sarà integrato con la presente RFC per fare in modo che il meccanismo di lock sia esteso a livello provinciale. Iter.GIS è infatti un applicativo multiutente che, soprattutto nella configurazione client/server, consente l’accesso al grafo stradale a più utenze profilate e gestisce l’accesso esclusivo in scrittura da parte di un utente alla volta;
• per il terzo ed ultimo punto, il client Iter.GIS implementa già la trasmissione dei dati a Regione Toscana e quindi la personalizzazione per Provincia di Firenze aggiungerà la possibilità di scaricare i dati trasmessi a CART dai corrispondenti, oltre a necessitare una riconfigurazione di CART stesso per consentire l’invio contemporaneo a più corrispondenti (questo perché ogni Comune invierà sempre le proprie modifiche sia alla Provincia che a Regione Toscana e, viceversa, la Provincia invierà le proprie modifiche a tutti i Comuni ed alla Regione Toscana).

• il componente Iter.GIS raffigurato nel precedente diagramma di sequenza rappresenta un possibile applicativo di gestione del grafo stradale;
• l’applicativo di gestione del grafo stradale deve mantenere memoria del protocollo del dato del Comune. Il protocollo identifica una particolare versione ed è un numero intero monotonicamente crescente maggionre di zero. Esso deve essere incremetnato ogniqualvolta venga effettuata una trasmissione di dati su CART tramite il proxy iter.net; il protocollo riveste un’importanza fondamentale nell’orchestrazione dei dati, consentendo ad un applicativo di gestione del grafo di discernere il caso in cui una controparte abbia posto in lock un Comune ed effettuato delle modifiche prima di sbloccarlo oppure abbia solo posto in lock un Comune senza effettaure modifiche e poi l’abbia sbloccato;
• l’accesso ai servizi del LockManager è mediato da CART in modalità proxy trasparente;
• le attività svolte dall’utente, ed in particolare la Verifica e la Pubblicazione, sono attività peculiari di Iter.GIS;
• l’autenticazione al LockManager è eseguita a livello di installazione di Iter.GIS e non a livello di singolo utente (cioè tutti gli utenti di quella installazione Iter.GIS si autenticheranno al LockManager con una stessa utenza/password che sarà configurata su Iter.GIS stesso).

iter.net – Data Pack Accessori

Il presente profilo illustra le specifiche per attuare la trasmissione dei dati relativi al progetto Proxy DPA “DataPack Accessori” promosso da Provincia di Firenze, che vuole espandere la rete del Data Pack Indirizzario con le nuove classi di dati che descrivono MANOVRE, LIMITAZIONI DI ACCESSO, PUNTI DI INTERESSE (POI), INCROCI SEMAFORICI; tali informazioni riguardano l’utilizzo delle applicazioni di supporto alla mobilità e all’infomobilità.

In tale contesto vengono veicolate tramite Cooperazione Applicativa le informazioni descritte nel Datapack Indirizzario secondo quanto dettagliato nel modello dati delle Specifiche Tecniche di Esportazione del Grafo.

iter.net – toponomastica stradale

Lo scopo del servizio è quello di veicolare le modifiche agli stradari comunali, sia a livello di toponomastica stradale che di geometria, inclusi i numeri civici appartenenti ai suddetti toponimi stradali.

Normalizzazione e Georeferenziazione di Indirizzi Civici

Il sistema di normalizzazione e  georeferenziazione si fonda su una procedura che consente di ottenere indirizzi normalizzati da indirizzi non normalizzati, e quindi di associare loro delle coordinate, tramite le quali localizzare sul territorio i siti cui tali indirizzi si riferiscono.

La modalità di interazione è prevalentemente online, utilizzando form di inserimento dati. 

La procedura  utilizza i dati provenienti dal sistema Iternet di Regione Toscana, e si integra nel sistema di pubblicazione mappe denominato Grules alla url “http://mappe.rete.toscana.it” .

I dati Iter.net vengono forniti periodicamente al servizio tramite un unico database Sqlite (il file e’ denominato iternet_normalizzatore.sqlite ) che viene a sua volta trattato con estrazione dei dati alfanumerici dalle tabelle delle strade e dei civici formando cosi’ la base dati del servizio in oggetto; l’output del servizio di normalizzazione e georeferenziazione riporta i dati cartografici estrapolati da Iter.net senza utilizzarne le geometrie, fornendo quindi dati di sola lettura.

I sistemi di riferimento utilizzati sono: per quanto riguarda le coordinate cartografiche Gauss Boaga ed UTM-32, mentre per le coordinate geografiche Latitudine e  Longitudine in WGS84.

L’indirizzo civico, passando attraverso la fase di normalizzazione e’ riscritto cosi’ da essere riconoscibile in modo univoco.

Questo consente poi di assegnargli delle coordinate cartografiche, ovvero di metterlo in corrispondenza biunivoca con esse.

L’indirizzo normalizzato puo’ essere quindi usato anche come chiave di ricerca.

L’obiettivo e’ di fornire uno strumento che a partire dall’indirizzo civico, produca:

– la normalizzazione dello stesso,

– le coordinate cartografiche associate all’indirizzo normalizzato.