luca
Una delle principali modalità di ricerca di Formaromae se non la principale è quella geografica.
Parlo di motore geografico perché non sarà un semplice webgis per due motivi fondamentali, il primo è che dovrà fare una deduplica geografica che non è una funzione standard per un webgis e l’altro è che dovrà essere configurato come un microservizio a disposizione di altre applicazioni di terze parti.
Il suo cuore è il container geoserver che però lavorerà in federazione col geoserver della NIC e con quello del SITAR.
Per immaginarlo dobbiamo drasticamente dividere in due categorie le centinaia di coperture cartografiche disponibili, potremmo per comodità chiamarle sfondi e target.
Gli sfondi comprenderanno tutti le cartografie raster e tutte quelle cartografie vettoriali i cui oggetti non sono beni culturali immobili e ricadono quindi fuori dal campo di ricerca di Formaromae. Dovranno essere offerte a catalogo dal nostro geoserver avere i propri metadati ed essere richiamabili dal frame webgis del mockup formaromae. Il lavoro sugli sfondi compete quasi esclusivamente ad Almaviva e non ha nulla di innovativo, possiamo pensarlo come un webgis senza altre funzioni se non quelle standard. L’ unica complessità è quella di studiare un sistema di caricamento che consenta all’ utente finale di districarsi tra qualche centinaio di sfondi possibili (e non sempre tra loro sovrapponibili). La AI potrebbe, sulla base delle scelte degli utenti e di modelli precaricati, suggerire dei pacchetti di sfondi, ma è una funzione che si può aggiungere e non essendo tassativa non dovrà limitare le scelte.
Quello che più ci interessa e ci impegna è invece la categoria dei target. Le coperture target saranno in numero molto più limitato rispetto agli sfondi, probabilmente poche decine, ma sono quelle che il motore dovrà interrogare. A titolo di esempio includerei gli oggetti del SITAR, quelli di SIMART georiferiti, quelli della carta dell’ agro e della carta per la qualità, quelli dei geodb di monitoraggio ecc. (si può fare un elenco in poco tempo pescando nel censimento fatto da Aldo Riggio) La loro caratteristica è di essere punti, linee e poligoni, ma a queste 3 tipologie vanno aggiunte le nuvole di punti che essendo georiferite possono ben rientrare tra i risultati della ricerca geografica magari con un simbolismo a parte.
Su questi la ricerca sarà geografica e quindi per inclusione in poligoni disegnati dall’ utente, ma il risultato dovrà, come per i dati testuali, essere sottoposto a deduplica , che quindi genererà rating, feedback verso l’ owner dei dati e possibilità per gli utenti di risalire alla fonte.
La ricerca quindi genererà una copertura (semi persistente) che includa tutti gli oggetti target e su questa si andrà ad operare la deduplica.
Le regole di deduplica le abbiamo abbozzate già con Daniele Graziano, il poligono prevale sui punti e sulle linee in esso contenuti, la linea sui punti contenuti. Una volta esaurito questo primo step sarà necessario un secondo vaglio simile allo snap di un cad. Fissato un valore di buffer e verificato che 2 oggetti geografici sono la rappresentazione dello stesso bene, in basi dati diverse, sarà il numero dei vertici o la distanza dai centroidi o in ultima analisi il rating a stabilire quale sia l’ oggetto da presentare e quali invece quelli da elencare per approfondimenti opzionali.
La deduplica geografica avrà effetto anche su tutti gli altri dati presentati nel senso che verranno presentati quelli della geometria vincente integrati dagli altri solo in assenza di valorizzazione e seguendo la classifica di rating.
Attenzione, questo comporta che una ricerca geografica potrebbe avere un risultato complessivo diverso rispetto ad una testuale, ma di questo basta avvertire l’ utente. Spiego meglio: se la ricerca è nel testo e cerco Colosseo otterrò i valori in base alla deduplica testuale e la geografia dalla base dati che ha la migliore corrispondenza testuale; se invece traccio un cerchio intorno al colosseo otterrò i valori dalla base dati che ha migliore rappresentazione geografica. I meccanismi sono compensabili dall' utente esaminando le diverse fonti….
I set di oggetti geografici verranno poi passati al frame webgis, se l’ interrogazione è arrivata tramite portale, se invece proviene da API la risposta verrà indirizzata con lo stesso mezzo come risposta alla transazione.