-----------------------------------

Acquista i software ArcGIS tramite Studio A&T srl, rivenditore autorizzato dei prodotti Esri.

I migliori software GIS, il miglior supporto tecnico!

I migliori software GIS, il miglior supporto tecnico!
Azienda operante nel settore GIS dal 2001, specializzata nell’utilizzo della tecnologia ArcGIS e aderente ai programmi Esri Italia Business Network ed Esri Partner Network

-----------------------------------



Visualizzazione post con etichetta GIS. Mostra tutti i post
Visualizzazione post con etichetta GIS. Mostra tutti i post

martedì 6 ottobre 2026

ArcGIS Crime Analysis 6.0: dalla mappa dei reati alla Spatio-Temporal Intelligence

Una mappa dei reati non è Crime Analysis.

Visualizzare migliaia di incidenti come punti su una mappa può essere utile, ma il vero problema analitico è molto più profondo: capire se ciò che osserviamo rappresenta un pattern statisticamente significativo, come evolve nel tempo, quanto rapidamente decade il rischio attorno a un evento, se un intervento ha realmente modificato il fenomeno e, soprattutto, quanta incertezza esiste nei dati che stiamo analizzando.

Con Crime Analysis 6.0, rilasciato a settembre 2026, Esri ha aggiornato in modo significativo la propria soluzione per ArcGIS Pro. La nuova release supporta ArcGIS Pro 3.7, introduce un nuovo add-in e due strumenti particolarmente interessanti: Aoristic Analysis e Weighted Displacement Difference.

Ma questi strumenti diventano ancora più interessanti se li inseriamo in un quadro più ampio:

Crime Mapping
      ↓
Spatial Statistics
      ↓
Spatio-Temporal Analysis
      ↓
Crime Pattern Detection
      ↓
Uncertainty Modelling
      ↓
Vector + Graph Representation
      ↓
GeoAI / Agentic Spatial Intelligence

In questo deep dive vediamo quindi Crime Analysis non semplicemente come una toolbar di ArcGIS Pro, ma come il punto di ingresso verso una moderna architettura di spatial intelligence.

1. Il dato criminale è un evento spazio-temporale

Il modello più semplice rappresenta un incidente come:

CrimeEvent = (x, y, t)

dove x,y identificano la posizione e t il tempo.

Nella realtà un evento è molto più ricco:

CrimeEvent =
{
    Geometry,
    OccurFrom,
    OccurTo,
    CrimeType,
    ModusOperandi,
    Target,
    Context,
    Relationships
}

Già qui emerge un problema fondamentale: spesso t non è conosciuto.

Un furto in abitazione può essere scoperto alle 18:00, mentre il proprietario ha lasciato casa alle 08:00. L'unica informazione corretta è quindi:

08:00 ≤ t ≤ 18:00

Attribuire arbitrariamente il crimine alle 08:00, alle 13:00 o alle 18:00 introduce informazione che il dato originale non contiene.

Ed è esattamente qui che entra in gioco una delle novità più interessanti di Crime Analysis 6.0.

2. Aoristic Analysis: modellare il tempo che non conosciamo

L'Aoristic Analysis affronta gli eventi per i quali conosciamo un intervallo temporale ma non l'istante esatto.

Supponiamo che un evento possa essere avvenuto in quattro intervalli temporali:

10:00
11:00
12:00
13:00

In assenza di altra informazione, ciascun intervallo riceve peso:

P(t) = 1 / 4 = 0.25

Più generalmente, per un evento i compatibile con n intervalli:

w(i,t) = 1 / n

quando il time bucket t appartiene alla finestra temporale dell'evento, e zero altrimenti.

Aggregando molti eventi otteniamo:

A(t) = Σ w(i,t)

che rappresenta il peso aoristico complessivo associato a quel periodo.

La differenza concettuale è importante: non stiamo inventando l'orario più probabile del singolo evento. Stiamo propagando esplicitamente la sua incertezza temporale.

3. Implementarlo in C#

Il principio può essere riprodotto facilmente in .NET. Immaginiamo un modello minimale:

public sealed record CrimeIncident(
    long Id,
    DateTime OccurFrom,
    DateTime OccurTo,
    string CrimeType);

Possiamo calcolare quanto un evento contribuisce a un determinato bucket temporale:

static double AoristicWeight(
    DateTime occurFrom,
    DateTime occurTo,
    DateTime bucketFrom,
    DateTime bucketTo)
{
    if (occurTo <= occurFrom)
        return 0;

    var from = occurFrom > bucketFrom
        ? occurFrom
        : bucketFrom;

    var to = occurTo < bucketTo
        ? occurTo
        : bucketTo;

    if (to <= from)
        return 0;

    return (to - from).TotalSeconds /
           (occurTo - occurFrom).TotalSeconds;
}

Questa variante utilizza la frazione effettiva di sovrapposizione dell'intervallo, rendendo esplicito ciò che normalmente viene nascosto dietro una semplice classificazione temporale.

In un add-in ArcGIS Pro potremmo quindi leggere le feature con ArcGIS Pro SDK, estrarre OccurFrom e OccurTo, costruire i bucket e produrre una tabella o una feature class derivata.

Il punto interessante non è riscrivere uno strumento che ArcGIS possiede già. È capire il modello matematico per poterlo integrare in pipeline analitiche più complesse.

4. Kernel Density non significa Hot Spot Analysis

Una delle confusioni più comuni nella spatial analysis è interpretare qualsiasi superficie con zone rosse come un hot spot statisticamente significativo.

Kernel Density Estimation (KDE) costruisce una superficie continua distribuendo attorno agli eventi una funzione kernel. In forma semplificata:

f̂(x) = 1/(nh²) Σ K((x-Xᵢ)/h)

dove h è il bandwidth.

Aumentando il search radius si ottiene una superficie più liscia e generalizzata; riducendolo emergono strutture locali più dettagliate.

Il risultato rimane però una stima di densità, non automaticamente una prova di significatività statistica.

high density ≠ statistically significant hot spot

5. Getis-Ord Gi*: quando il clustering diventa statistico

Per individuare cluster statisticamente significativi ArcGIS Pro mette a disposizione, tra gli altri strumenti, Optimized Hot Spot Analysis, basato sulla statistica Getis-Ord Gi*.

Concettualmente non ci interessa soltanto sapere se una feature ha un valore elevato. Vogliamo sapere se essa è circondata da valori elevati in misura difficilmente compatibile con una distribuzione casuale.

Il risultato comprende:

Gi* z-score
p-value
confidence bin

Questa distinzione dovrebbe essere alla base di qualsiasi sistema serio di crime intelligence:

Visualization
    ≠
Density estimation
    ≠
Spatial clustering
    ≠
Statistical evidence

6. DBSCAN, HDBSCAN e clustering spazio-temporale

Non tutti i pattern hanno forma regolare.

Density-based Clustering in ArcGIS Pro consente di identificare cluster immersi nel rumore utilizzando algoritmi come DBSCAN, HDBSCAN e OPTICS.

Questa proprietà è particolarmente interessante nel crime analysis perché un pattern può essere molto evidente per tre settimane e scomparire completamente nel mese successivo.

Una distanza puramente spaziale:

d(i,j) = √((xᵢ-xⱼ)² + (yᵢ-yⱼ)²)

non cattura questa dinamica.

Possiamo concettualmente introdurre una distanza spazio-temporale:

D(i,j) = αDspace(i,j) + βDtime(i,j)

con scale opportunamente normalizzate.

7. Repeat e Near-Repeat: il rischio non è statico

Uno dei concetti più potenti della crime geography è la repeat/near-repeat victimization.

Dopo un evento, il luogo colpito e le aree vicine possono presentare per un periodo limitato un rischio maggiore di eventi analoghi. Tale influenza tende a diminuire sia con la distanza sia con il tempo.

Crime Analysis contiene strumenti dedicati per classificare eventi come originator, repeat e near-repeat utilizzando bande spaziali e temporali.

Possiamo rappresentare concettualmente il decadimento come:

R(d,t) = R₀ · e-λd · e-μt

dove:

d = distanza dall'incidente
t = tempo trascorso
λ = decadimento spaziale
μ = decadimento temporale

Non è quindi una superficie di rischio permanente.

È una superficie che decade continuamente nello spazio e nel tempo.

8. Prediction Zones: attenzione alla parola "prediction"

Crime Analysis può generare Prediction Zones a partire dai pattern repeat/near-repeat.

È però importante capire cosa significa "prediction".

Non significa:

qui avverrà il prossimo crimine

Significa piuttosto:

date le regolarità spazio-temporali
osservate nel dataset,
quest'area presenta un rischio relativo
più elevato nel breve periodo.

È una differenza enorme, sia statisticamente sia eticamente.

9. Space-Time Cube: quando la mappa 2D non basta più

Un altro salto concettuale consiste nel trattare lo spazio e il tempo come un'unica struttura analitica.

Lo Space-Time Cube suddivide i dati in bin spaziali e temporali:

             TIME
              ↑
              │  ▢
              │  ▢ ▢
              │  ▢ ▢
              │  ▢ ▢ ▢
              │
              └────────────→ SPACE

Emerging Hot Spot Analysis permette di osservare non solo dove sono presenti cluster, ma come essi evolvono nel tempo.

La domanda non è più:

Dove sono gli hot spot?

ma:

Dove stanno nascendo?
Quali persistono?
Quali si stanno intensificando?
Quali stanno scomparendo?

Questa è già spatio-temporal intelligence.

10. Crime series e comportamento spaziale

Crime Analysis include workflow per ordinare cronologicamente gli eventi appartenenti a una serie e rappresentarne le connessioni.

Questo consente di studiare concetti classici del geographic profiling, come la distinzione tra comportamento marauder e commuter.

La sequenza:

P1 → P2 → P3 → P4 → P5

diventa quindi molto più di una polilinea.

Possiamo analizzare:

distance(Pn, Pn+1)
bearing(Pn, Pn+1)
Δt(Pn, Pn+1)
velocity
dispersion
directional persistence

e cercare cambiamenti nella struttura della serie.

11. Weighted Displacement Difference: l'intervento ha funzionato?

Crime Analysis 6.0 introduce anche Weighted Displacement Difference.

Qui la domanda cambia completamente.

Non vogliamo più soltanto descrivere il fenomeno. Vogliamo valutare un intervento.

Response Area
      +
Response Displacement Zone

Control Area
      +
Control Displacement Zone

        ↓

Before vs After
        ↓
Weighted Displacement Difference

La statistica confronta il cambiamento degli incidenti nell'area interessata dall'intervento con quello osservato in un'area di controllo e considera anche le aree circostanti per verificare se il fenomeno sia stato semplicemente spostato.

Questo è un passaggio metodologico importantissimo:

Crime ↓ nell'area A

non implica necessariamente:

Intervento efficace

perché potrebbe essersi verificato:

A ↓
B ↑

ovvero displacement.

12. Da Crime Analysis a un Crime Graph

Fin qui abbiamo considerato principalmente geometrie, attributi e tempo.

Ma un'indagine contiene naturalmente anche relazioni.

Person ── called ── Person
   │                   │
 visited             owns
   │                   │
   ▼                   ▼
Place ── near ── CrimeEvent
                       │
                    similar
                       │
                       ▼
                  CrimeEvent

Crime Analysis contiene già strumenti investigativi per lavorare con call links, settori delle celle telefoniche e corrispondenze spazio-temporali.

La naturale evoluzione architetturale è quindi rappresentare parte del dominio come un spatio-temporal knowledge graph.

13. Il passo successivo: Crime Event Embeddings

Ed è qui che possiamo andare oltre gli strumenti standard.

Un incidente non deve necessariamente essere confrontato con un altro soltanto attraverso la distanza geografica.

Possiamo costruire una rappresentazione multidimensionale:

E = [
    spatial features,
    temporal features,
    modus operandi,
    target characteristics,
    environmental context,
    semantic description,
    graph relationships
]

e trasformarla in un vettore:

z = f(E) ∈ Rⁿ

A quel punto due incidenti possono essere confrontati attraverso una funzione di similarità che combina più domini:

D(i,j) = αDspace + βDtime + γDsemantic + δDMO + εDgraph

La query investigativa cambia radicalmente.

Da:

Find incidents within 500 meters.

a:

Find incidents that are:

geographically compatible
AND temporally compatible
AND behaviorally similar
AND semantically similar
AND connected through relevant entities.

Questo è il punto d'incontro tra GIS, vector search e graph analytics.

14. Un'architettura GeoAI

Una possibile architettura enterprise potrebbe diventare:

                ArcGIS Pro
                    │
             Crime Analysis
                    │
          Spatial Statistics
                    │
             ArcGIS Enterprise
                    │
        ┌───────────┴───────────┐
        │                       │
 Spatial Features         Operational Data
        │                       │
        └───────────┬───────────┘
                    │
               Azure SQL
                    │
       ┌────────────┼────────────┐
       │            │            │
   relational     vector       graph
     data         index      relationships
       │            │            │
       └────────────┼────────────┘
                    │
             Retrieval Layer
                    │
                 GeoAgent
                    │
             ArcGIS Pro / Web

Il GeoAgent potrebbe ricevere una richiesta come:

Analyze residential burglaries from the last six weeks.

Identify statistically significant spatial clusters,
test for repeat/near-repeat behavior,
compare modus-operandi similarity,
and explain which evidence supports each candidate series.

15. L'LLM non deve fare statistica al posto del GIS

Questo è forse il punto architetturale più importante.

Non costruirei un sistema nel quale chiediamo direttamente a un Large Language Model:

Where will the next crime occur?

Un LLM non dovrebbe sostituire Getis-Ord Gi*, KDE, DBSCAN, Space-Time Cube o un modello statistico validato.

Dovrebbe invece funzionare come orchestratore analitico:

User
  │
  ▼
GeoAgent
  │
  ├──► ArcGIS Spatial Statistics
  │
  ├──► Space-Time Analysis
  │
  ├──► Vector Search
  │
  ├──► Graph Query
  │
  └──► Operational Database
          │
          ▼
      Evidence
          │
          ▼
   LLM explanation

In altre parole:

LLM ≠ analytical truth

LLM = reasoning + orchestration + explanation

mentre il risultato quantitativo deve continuare a provenire da strumenti deterministici, modelli statistici o algoritmi esplicitamente validati.

16. Explainability prima della prediction

Un sistema di crime intelligence dovrebbe poter rispondere non soltanto:

Risk = HIGH

ma anche:

WHY?

• 7 recent related incidents
• statistically significant Gi* cluster
• 5 incidents inside the near-repeat temporal window
• high spatial proximity
• strong modus-operandi similarity
• pattern intensifying over the last 3 weeks

La spiegabilità non è un accessorio dell'AI.

In domini ad alto impatto è parte dell'architettura.

17. Il problema più difficile: i dati non sono la realtà

Esiste infine un limite che nessun algoritmo può eliminare automaticamente.

Un database criminale non rappresenta necessariamente:

all crimes that happened

ma più precisamente qualcosa di simile a:

events reported
+
events detected
+
events recorded
+
events classified
+
effects of enforcement activity

Questa distinzione è fondamentale.

Una maggiore concentrazione di osservazioni in una zona può derivare da un maggior numero di eventi, ma può anche essere influenzata da maggiore presenza operativa, differenti livelli di denuncia, procedure amministrative o qualità diversa del dato.

Se utilizziamo questi dati senza comprenderne il processo generativo, rischiamo di creare un feedback loop:

more observations
      ↓
higher estimated risk
      ↓
more attention
      ↓
more detected events
      ↓
even higher estimated risk

La precisione matematica del modello non elimina il bias del processo che ha prodotto i dati.

18. Dal GIS descrittivo alla Spatial Intelligence

Crime Analysis 6.0 mostra bene quanto il GIS moderno si stia allontanando dalla semplice rappresentazione cartografica.

Il percorso ormai è:

Where did it happen?
        ↓
Where is it concentrated?
        ↓
Is the concentration statistically significant?
        ↓
How is the pattern evolving?
        ↓
How does risk decay in space and time?
        ↓
Are apparently separate events related?
        ↓
Did an intervention change the pattern?
        ↓
What evidence supports the conclusion?

E il prossimo passo potrebbe essere:

Can an intelligent spatial agent
autonomously assemble the right analyses,
test competing hypotheses,
retrieve supporting evidence
and explain its conclusions?

Conclusione

Crime Analysis 6.0 è interessante non tanto perché aggiunge nuovi pulsanti ad ArcGIS Pro, ma perché rende evidente una trasformazione più ampia.

La geografia del crimine sta diventando sempre più una disciplina spazio-temporale, probabilistica e relazionale.

Aoristic Analysis ci ricorda che anche il tempo può essere incerto. Repeat/Near-Repeat Analysis introduce il decadimento spazio-temporale del rischio. Space-Time Cube permette di osservare l'evoluzione dei cluster. Weighted Displacement Difference porta l'analisi verso la valutazione degli interventi.

Embeddings, vector search, graph analytics e GeoAI possono costituire il livello successivo, purché non sostituiscano la statistica con un modello linguistico.

Il GIS del futuro non dovrà semplicemente mostrare dove si trova qualcosa.

Dovrà essere in grado di spiegare:

what happened
where
when
how it is connected
how certain we are
how the pattern is changing
and which evidence supports the hypothesis.

È in quel momento che una mappa smette di essere soltanto una rappresentazione dello spazio e diventa un vero sistema di Spatial Intelligence.

venerdì 2 ottobre 2026

Geospatial Video in ArcGIS: dal pixel alla conoscenza spaziale

Geospatial Video in ArcGIS: dal pixel alla conoscenza spaziale

Drone, dashcam, action camera e video 360° non sono semplicemente sorgenti video con una posizione GPS associata.

Se disponiamo delle informazioni corrette sulla posizione e sull'orientamento del sensore, una camera può diventare un vero e proprio sensore geospaziale mobile: ogni frame può essere collegato allo spazio geografico, gli oggetti osservati possono essere trasformati in feature GIS e una sequenza video può diventare una sorgente continua di osservazioni spazio-temporali.

È questo uno degli aspetti più interessanti del recente articolo Esri Working with geospatial video in ArcGIS, pubblicato il 29 settembre 2026.

Esri cita esplicitamente non soltanto sistemi video aerei e droni, ma anche dashcam e action camera 360°, osservando che un video dotato di metadata relativi a posizione e orientamento della camera può essere utilizzato all'interno di un contesto GIS.

Ma dietro questa frase apparentemente semplice c'è un mondo che tocca contemporaneamente GIS, fotogrammetria, computer vision, sensor fusion, GeoAI e digital twin.


Il video diventa un nuovo tipo di dato GIS

Un normale video è essenzialmente una sequenza di immagini:

Frame(t0)
Frame(t1)
Frame(t2)
...
Frame(tn)

Un geospatial video aggiunge una seconda dimensione informativa:

Frame + Time + Sensor Position + Sensor Orientation + Camera Model

Il timestamp diventa quindi la chiave che collega due stream:

VIDEO STREAM
Frame(t)
   |
   | timestamp
   v
TELEMETRY STREAM
Position(t)
Orientation(t)
Sensor parameters(t)

Da questo momento il frame non rappresenta più semplicemente "ciò che la camera vede".

Possiamo iniziare a determinare:

  • dove si trovava il sensore;
  • in quale direzione stava guardando;
  • quale porzione del territorio era potenzialmente visibile;
  • dove potrebbe trovarsi nello spazio un oggetto rilevato nel video;
  • quali feature GIS erano presenti nel campo visivo;
  • come la scena è cambiata rispetto a osservazioni precedenti.

Ed è qui che il video smette di essere soltanto un media e diventa dato geospaziale.


La prima distinzione fondamentale: posizione della camera ≠ posizione dell'oggetto

Una delle semplificazioni più pericolose quando si parla di dashcam o action camera con GPS consiste nell'assumere che una posizione GNSS renda automaticamente georeferenziato tutto ciò che appare nel video.

Non è così.

Il GPS può dirci, per esempio:

Camera position:
45.612345 N
9.276543 E

Questo significa soltanto:

la camera si trovava approssimativamente qui.

Non significa:

il cartello visibile nel pixel (1320, 742) si trova qui.

Per arrivare alla seconda informazione dobbiamo conoscere molto di più.


Dal pixel al mondo reale

Il problema fondamentale può essere espresso concettualmente come:

Pworld = f(u, v, K, R, t, terrain)

dove:

  • (u,v) è la coordinata del pixel nel frame;
  • K descrive i parametri intrinseci della camera;
  • R rappresenta la rotazione della camera;
  • t rappresenta la sua posizione;
  • terrain può essere un DEM, DSM o un'altra rappresentazione geometrica della scena.

Nella computer vision, la relazione tra un punto tridimensionale e la sua proiezione sul piano immagine viene spesso rappresentata nella forma:

λ [u v 1]T = K [R | t] [X Y Z 1]T

È una formula estremamente interessante per chi lavora nel GIS, perché rappresenta praticamente il ponte matematico tra computer vision e mondo geospaziale.

Il GIS lavora tipicamente con:

X, Y, Z

La computer vision lavora spesso con:

u, v

Il camera model permette di mettere in relazione questi due mondi.


Il problema inverso: da un pixel a un raggio nello spazio

Supponiamo che un algoritmo di object detection individui un segnale stradale nel frame.

Conosciamo la posizione del bounding box nell'immagine:

x = 1372
y = 684
width = 98
height = 142

Il centro del bounding box diventa un punto nel sistema di coordinate dell'immagine.

Utilizzando i parametri della camera possiamo trasformarlo in un raggio tridimensionale che parte dal sensore:

Pixel
  |
  v
Camera coordinates
  |
  v
World coordinates
  |
  v
Ray
  |
  v
Intersection with terrain / DSM / object
  |
  v
Geographic coordinate

Il punto GIS non deriva quindi dal GPS della camera.

Deriva dall'intersezione geometrica tra la linea di osservazione e il mondo reale.


Camera pose: dove sono e dove sto guardando?

Per trasformare seriamente un video in dato geospaziale dobbiamo conoscere la camera pose.

Una rappresentazione semplificata comprende sei gradi di libertà:

X
Y
Z

Roll
Pitch
Yaw

In altri contesti troveremo termini come:

Heading
Pitch
Roll

oppure:

Platform orientation
Sensor orientation

Questa distinzione diventa particolarmente importante quando la camera è installata su un gimbal.

Il drone può infatti avere un certo orientamento mentre il sensore guarda in una direzione completamente differente.

World
  |
Platform pose
  |
Gimbal orientation
  |
Camera orientation
  |
Optical axis

La posizione da sola non basta.


GNSS + IMU: nasce il sensor fusion

Nei sistemi più evoluti la posizione e l'orientamento vengono ottenuti combinando diversi sensori.

GNSS
  +
Accelerometer
  +
Gyroscope
  +
Magnetometer
  +
Camera
  ↓
Sensor Fusion
  ↓
Estimated Pose

Il GNSS fornisce una buona stima della posizione assoluta, ma può essere disturbato da multipath, edifici, vegetazione o perdita temporanea del segnale.

L'IMU reagisce molto rapidamente ai movimenti ma accumula progressivamente drift.

La combinazione dei sensori consente quindi di ottenere una stima della traiettoria migliore di quella ottenibile considerando ogni sensore separatamente.

Qui entrano in gioco tecniche come:

  • Kalman filtering;
  • Extended Kalman Filter;
  • RTK;
  • PPK;
  • Visual Odometry;
  • Visual-Inertial Odometry;
  • SLAM.

La dashcam come piattaforma di Mobile Mapping

Ed è qui che il discorso diventa particolarmente interessante.

Una dashcam moderna può essere vista come una versione estremamente economica di una piattaforma di mobile mapping.

Immaginiamo un veicolo che percorre quotidianamente una rete stradale.

La pipeline potrebbe essere:

Dashcam
  +
GNSS / IMU
  ↓
Video georeferenziato
  ↓
Computer Vision
  ↓
Object Detection
  ↓
Geolocation
  ↓
ArcGIS Feature Layer

Un modello potrebbe individuare:

  • segnaletica verticale;
  • buche;
  • guardrail;
  • lampioni;
  • idranti;
  • caditoie;
  • cantieri;
  • vegetazione invasiva;
  • barriere;
  • asset tecnologici;
  • anomalie del manto stradale.

La cosa più interessante, però, arriva dopo.


Detection non significa ancora conoscenza

Supponiamo che il modello trovi un cartello.

Object:
traffic_sign

AI confidence:
0.982

Possiamo proiettarlo nello spazio e ottenere:

Geometry:
POINT(...)

Estimated positional uncertainty:
± 2.8 m

A questo punto ArcGIS può eseguire uno spatial matching contro l'inventario esistente.

DETECTED OBJECT
       |
       +---- Existing feature found
       |          |
       |          +---- VERIFIED
       |
       +---- No existing feature
                  |
                  +---- POSSIBLE NEW ASSET

Ma possiamo anche invertire il controllo:

EXPECTED GIS ASSET
       |
       +---- detected in video
       |          |
       |          +---- OK
       |
       +---- not detected
                  |
                  +---- possible missing/damaged asset

A quel punto non stiamo più semplicemente analizzando immagini.

Stiamo facendo change detection tra realtà osservata e digital twin GIS.


Action camera: molto più di un video sportivo

Lo stesso principio può essere utilizzato con action camera montate su:

  • operatori;
  • biciclette;
  • mezzi di manutenzione;
  • treni;
  • imbarcazioni;
  • quad;
  • mezzi agricoli;
  • robot;
  • mezzi industriali.

Una squadra di manutenzione che percorre una pipeline potrebbe registrare continuamente il territorio.

Un algoritmo potrebbe successivamente associare ogni osservazione:

Asset ID
Timestamp
Position
Image evidence
Detected condition
AI confidence
Spatial confidence

L'action camera diventerebbe quindi parte di un sistema di field observation automatizzato.


Il caso speciale delle camere 360°

Le camere 360° sono ancora più interessanti.

Esri mostra esplicitamente nell'articolo un esempio di video 360° utilizzato tramite Oriented Imagery in Experience Builder.

Una camera panoramica non cattura semplicemente una scena davanti a sé.

Cattura un ambiente sferico attorno al sensore.

Molti video 360 vengono memorizzati usando una proiezione equirettangolare.

Sphere
  ↓
Longitude / Latitude around camera
  ↓
Equirectangular projection
  ↓
2D video frame

In modo molto semplificato:

pixel X → azimuth
pixel Y → elevation

Quindi un punto dell'immagine può essere trasformato in una direzione tridimensionale.

Se conosciamo la posa della camera possiamo trasformare quella direzione da camera-space a world-space.


Una strada ripresa a 360° diventa un dataset interrogabile

Immaginiamo una camera 360° montata sul tetto di un veicolo.

Ogni pochi metri otteniamo una nuova osservazione completa dell'ambiente circostante.

Potremmo costruire qualcosa concettualmente simile a:

Road trajectory
      |
      +---- Observation t1
      |        +---- panorama
      |
      +---- Observation t2
      |        +---- panorama
      |
      +---- Observation t3
               +---- panorama

Ma a quel punto possiamo fare molto di più che navigare le immagini.

Possiamo chiedere:

Quali asset sono visibili da questa posizione?

Oppure:

Quali oggetti rilevati nel panorama non esistono ancora nel GIS?

Oppure ancora:

Mostrami come appariva questo edificio sei mesi fa.

Il 360° diventa così una possibile interfaccia tra spazio fisico, tempo e sistema GIS.


Full Motion Video e Oriented Imagery non sono la stessa cosa

Nel mondo ArcGIS è importante distinguere due approcci principali.

Full Motion Video

Il Full Motion Video utilizza tipicamente metadata geospaziali integrati nel flusso video.

Esri utilizza metadata KLV — Key-Length-Value e workflow compatibili con gli standard MISB per collegare video e informazioni sul sensore.

Concettualmente:

VIDEO
+
KLV METADATA
+
TIME SYNCHRONIZATION
=
GEOSPATIAL VIDEO STREAM

Uno dei grandi vantaggi di questo modello consiste nella possibilità di lavorare anche con stream live.

Il client riceve contemporaneamente:

video frame
sensor position
orientation
field of view
timestamp
...

e può aggiornare dinamicamente la posizione e il footprint del sensore.

Oriented Imagery

Oriented Imagery segue un modello differente.

Le informazioni spaziali possono essere gestite separatamente dal video e associate tramite dataset GIS.

Questo modello è particolarmente interessante per:

  • dashcam;
  • video terrestri;
  • panorami 360°;
  • viste oblique;
  • immagini che puntano sopra l'orizzonte.

Esri sottolinea infatti che molte funzionalità FMV assumono implicitamente che il footprint della camera possa essere proiettato sul terreno.

Questo funziona bene per una camera aerea rivolta verso il basso.

Molto meno per una dashcam che guarda verso l'orizzonte.


KLV: quando video e telemetry viaggiano insieme

KLV significa:

KEY
LENGTH
VALUE

È un modo strutturato di rappresentare informazioni all'interno di uno stream.

Nel caso geospaziale possono essere trasportate informazioni come:

Timestamp
Sensor Latitude
Sensor Longitude
Sensor Altitude
Platform Heading
Platform Pitch
Platform Roll
Sensor Azimuth
Sensor Elevation
Horizontal FOV
Vertical FOV
Frame center
Corner coordinates
...

Il vantaggio è enorme:

video + telemetry

restano sincronizzati all'interno dello stesso stream.

È uno dei motivi per cui questo modello è particolarmente adatto al live Full Motion Video.


Video Multiplexer: quando i metadata sono esterni

Molti dispositivi consumer non producono nativamente uno stream FMV con metadata KLV.

Potrebbero invece generare qualcosa come:

video.mp4
track.gpx

oppure:

video.mp4
telemetry.csv

In questi casi il problema diventa sincronizzare i due dataset.

MP4
  +
CSV / telemetry
  ↓
Video Multiplexer
  ↓
Geospatial video

ArcGIS Pro dispone di strumenti dedicati a questo tipo di workflow.

Ma il punto realmente critico non è il multiplexing.

È la qualità dei metadata iniziali.


Il vero problema è il tempo

Potremmo avere una camera perfettamente calibrata e una posizione GNSS estremamente precisa e ottenere comunque una geolocalizzazione errata.

È sufficiente che video e telemetry siano leggermente fuori sincronizzazione.

Consideriamo un'automobile che procede a 90 km/h:

90 km/h ≈ 25 m/s

Un errore temporale di:

100 ms

significa già circa:

2.5 metri

di spostamento del veicolo.

Con:

500 ms

diventano:

12.5 metri

prima ancora di considerare qualsiasi altro errore.

Nel geospatial video il timestamp non è un semplice attributo.

È parte integrante del modello geometrico.


AI confidence non significa spatial confidence

Questa distinzione diventerà fondamentale nei sistemi GeoAI.

Un modello potrebbe dire:

Object: Fire Hydrant
Confidence: 99.4%

Ma la sua posizione potrebbe essere:

Spatial accuracy: ±8 m

Le due misure descrivono fenomeni completamente diversi.

AI confidence:

quanto sono sicuro di aver riconosciuto correttamente l'oggetto?

Spatial confidence:

quanto sono sicuro della sua posizione geografica?

Un sistema GIS serio dovrebbe conservare entrambe.

Una feature potrebbe quindi diventare:

{
  "class": "FireHydrant",
  "geometry": "...",
  "detectionConfidence": 0.994,
  "horizontalAccuracy": 2.7,
  "observedAt": "2026-10-02T08:15:32Z",
  "source": "vehicle-17-camera-2",
  "frame": 182932,
  "modelVersion": "asset-detector-4.2"
}

La provenance diventa parte del dato.


Propagazione degli errori

La precisione finale è influenzata da molte componenti:

GNSS error
+
IMU error
+
orientation error
+
camera calibration error
+
lens distortion
+
timestamp error
+
terrain/model error
+
object localization error

Un piccolo errore angolare può diventare significativo aumentando la distanza dell'oggetto.

In prima approssimazione:

e ≈ d · tan(θ)

Con un errore angolare di appena 1° e un oggetto distante 100 metri:

100 × tan(1°) ≈ 1,75 m

A 500 metri:

≈ 8,7 m

Questo senza ancora considerare l'errore GNSS.

Ecco perché una soluzione professionale dovrebbe produrre non soltanto una coordinata, ma possibilmente anche una misura di uncertainty.


Lens distortion e camera calibration

Un altro problema spesso ignorato riguarda l'ottica.

Le camere reali non sono pinhole camera perfette.

Soprattutto action camera e obiettivi grandangolari possono avere importanti distorsioni:

  • radial distortion;
  • tangential distortion;
  • fisheye distortion.

Prima di utilizzare seriamente le coordinate pixel per una proiezione geometrica potrebbe quindi essere necessario applicare una correzione:

distorted pixel
       ↓
camera calibration
       ↓
undistorted pixel
       ↓
ray projection

Un altro piccolo dettaglio che separa il semplice "video con GPS" da un vero sistema geospaziale.


Lever-arm offset: anche il GPS non si trova dove si trova la camera

In una configurazione professionale esiste poi un'altra sottigliezza.

L'antenna GNSS potrebbe trovarsi sul tetto del veicolo mentre la camera è montata mezzo metro più avanti e lateralmente.

Quindi:

GNSS position ≠ optical center position

La distanza tra questi componenti viene spesso descritta attraverso il concetto di lever arm.

Se vogliamo ottenere precisioni elevate dobbiamo trasformare la posizione misurata dal GNSS nella posizione effettiva del centro ottico della camera.

Su un drone piccolo potrebbe sembrare irrilevante.

Su un mezzo mobile mapping con più sensori può diventare fondamentale.


GeoAI: trasformare il video in feature

Ed ecco il salto successivo.

Possiamo integrare geospatial video e deep learning:

Video
   ↓
Frame extraction
   ↓
Object Detection
   ↓
Segmentation
   ↓
Object Tracking
   ↓
Image coordinates
   ↓
Camera model
   ↓
Geolocation
   ↓
GIS Feature

A questo punto ArcGIS può applicare:

  • spatial join;
  • proximity analysis;
  • network analysis;
  • change detection;
  • temporal analysis;
  • asset matching;
  • quality control.

Computer vision e GIS svolgono quindi ruoli complementari.

Computer Vision:
WHAT is visible?

Geometry:
WHERE is it?

GIS:
WHAT does that location mean?

VLM: quando il video acquista anche una semantica

L'arrivo dei Vision-Language Model rende lo scenario ancora più interessante.

Un VLM non deve necessariamente limitarsi a classificare oggetti.

Può interpretare semanticamente una scena:

“A fallen tree partially obstructs the right lane approximately 40 meters ahead.”

Ma una frase del genere, da sola, non è ancora dato GIS.

Possiamo immaginare una pipeline:

VLM
 ↓
WHAT is happening?

Computer Vision
 ↓
WHERE in the image?

Sensor Geometry
 ↓
WHERE on Earth?

GIS
 ↓
WHAT exists around it?

Spatial Knowledge
 ↓
WHAT does it mean operationally?

Questa combinazione è estremamente potente.


Dal video al Spatial Knowledge Graph

Potremmo spingerci ancora più avanti.

Invece di generare semplicemente:

Point
Line
Polygon

potremmo trasformare ogni osservazione in conoscenza spazio-temporale:

Asset A
 |
 +-- observed at T1
 |       |
 |       +-- condition = GOOD
 |
 +-- observed at T2
 |       |
 |       +-- condition = DAMAGED
 |
 +-- observed at T3
         |
         +-- condition = REPAIRED

Il video diventa così uno stream di eventi.

Potremmo rappresentare relazioni come:

Camera OBSERVED Asset

Asset LOCATED_AT Position

Observation OCCURRED_AT Time

Observation GENERATED_BY Sensor

Observation CLASSIFIED_BY Model

Asset PART_OF RoadSegment

A questo punto iniziamo ad avvicinarci a un vero spatial knowledge graph temporale.


Il GIS diventa memoria della realtà

Questa prospettiva cambia anche la funzione del GIS.

Tradizionalmente possiamo pensarlo come:

GIS = representation of reality

Con sensori video continuamente attivi possiamo iniziare a pensarlo come:

GIS = continuously observed model of reality

Ogni passaggio di un mezzo può produrre nuove osservazioni.

Ogni osservazione può confermare, modificare o mettere in dubbio lo stato corrente del digital twin.


Edge AI: perché inviare tutto il video?

Un'altra evoluzione naturale riguarda l'elaborazione edge.

L'approccio tradizionale sarebbe:

Camera
  ↓
Upload entire video
  ↓
Cloud
  ↓
AI processing
  ↓
GIS

Ma un veicolo che registra continuamente video ad alta risoluzione può produrre enormi quantità di dati.

Potremmo invece eseguire l'inferenza direttamente sul veicolo:

Camera
  ↓
Edge AI
  ↓
Interesting event detected
  ↓
Geometry
Timestamp
Class
Confidence
Small evidence image
  ↓
ArcGIS

Invece di trasferire terabyte di video trasferiamo soltanto informazione geospaziale significativa.


Video-centric contro event-centric architecture

Possiamo distinguere due architetture.

Video-centric

Capture everything
      ↓
Store everything
      ↓
Process later

Event-centric

Observe continuously
      ↓
Understand locally
      ↓
Transmit meaningful events

La seconda potrebbe diventare particolarmente interessante per:

  • Smart City;
  • road management;
  • utility;
  • railways;
  • pipeline;
  • environmental monitoring;
  • emergency management;
  • autonomous inspection.

Una possibile architettura ArcGIS

Possiamo immaginare un sistema completo:

             ┌──────────────────────┐
             │ Camera / 360 / Drone │
             └──────────┬───────────┘
                        │
                 Video + Telemetry
                        │
                        ▼
             ┌──────────────────────┐
             │   Sensor Fusion      │
             │ GNSS + IMU + Camera  │
             └──────────┬───────────┘
                        │
                     Pose(t)
                        │
                        ▼
             ┌──────────────────────┐
             │ Computer Vision / AI │
             └──────────┬───────────┘
                        │
                detections(u,v)
                        │
                        ▼
             ┌──────────────────────┐
             │ Geometric Projection│
             │ Camera + DEM / DSM   │
             └──────────┬───────────┘
                        │
                   X,Y,Z + error
                        │
                        ▼
             ┌──────────────────────┐
             │       ArcGIS         │
             │ Feature / Imagery    │
             │ Temporal / Network   │
             └──────────┬───────────┘
                        │
                        ▼
             ┌──────────────────────┐
             │ Spatial Knowledge    │
             │ Digital Twin / GeoAI │
             └──────────────────────┘

ArcGIS come elemento di grounding

Uno degli aspetti più interessanti dell'integrazione GIS + AI è il concetto di grounding.

Un modello AI può riconoscere:

“questo sembra un armadio elettrico”.

ArcGIS può aggiungere:

“è probabilmente l'asset CAB-172, appartenente alla rete XYZ, installato nel 2017, situato 1,8 metri dalla posizione stimata della detection”.

Ed è una differenza enorme.

L'AI interpreta ciò che vede.

Il GIS fornisce il contesto spaziale e operativo.


Un possibile workflow da sviluppatore

Immaginiamo una semplice struttura applicativa:

foreach (var frame in video)
{
    var telemetry = GetTelemetry(frame.Timestamp);

    var cameraPose = SensorFusion.EstimatePose(telemetry);

    var detections = model.Detect(frame.Image);

    foreach (var detection in detections)
    {
        var ray = cameraModel.PixelToWorldRay(
            detection.Center,
            cameraPose);

        var position = terrain.Intersect(ray);

        var feature = new Observation
        {
            Geometry = position,
            Class = detection.Class,
            DetectionConfidence = detection.Score,
            Timestamp = frame.Timestamp,
            SourceFrame = frame.Id
        };

        arcgisLayer.Add(feature);
    }
}

Naturalmente un sistema reale sarebbe molto più complesso.

Ma questo pseudo-codice mostra perfettamente il principio:

FRAME
→ DETECTION
→ RAY
→ WORLD
→ GIS

E se avessimo depth estimation?

Un'altra frontiera interessante arriva dai modelli monoculari di depth estimation.

Se un modello riesce a stimare la profondità relativa della scena possiamo aggiungere un'ulteriore sorgente informativa alla geometria.

RGB frame
   ↓
Depth model
   ↓
Estimated depth
   +
Camera pose
   ↓
Approximate 3D reconstruction

Naturalmente la profondità monoculare presenta problemi di scala e precisione e non sostituisce automaticamente LiDAR o stereo vision.

Ma combinata con GNSS, IMU e altri vincoli potrebbe contribuire a sistemi ibridi molto interessanti.


SLAM + GIS: localizzazione relativa e assoluta

Un'altra combinazione affascinante è:

SLAM
+
GNSS
+
GIS

Lo SLAM permette di ricostruire simultaneamente movimento del sensore e struttura relativa dell'ambiente.

Il GNSS introduce il riferimento geografico assoluto.

Il GIS fornisce il contesto semantico e cartografico.

In alcuni scenari potremmo addirittura utilizzare il GIS stesso come sorgente di vincoli:

Detected road
+
Known road centerline
→ trajectory correction

oppure:

Detected building facade
+
Known 3D building
→ pose refinement

A quel punto il GIS non è più soltanto destinazione dei dati.

Diventa parte del processo di localizzazione.


Dal Digital Twin al Observed Digital Twin

Il termine digital twin viene utilizzato moltissimo.

Ma spesso descrive un modello relativamente statico:

Physical World
     ↓
Digital Twin

Con geospatial video, IoT e GeoAI potremmo evolvere verso:

Physical World
     ↓
Continuous Observation
     ↓
AI Interpretation
     ↓
Spatial Validation
     ↓
Digital Twin Update
     ↓
Physical World

Non soltanto un Digital Twin.

Ma un Observed Digital Twin: un modello che viene continuamente confrontato con nuove osservazioni del mondo fisico.


Il video potrebbe non essere il dato finale

Arriviamo quindi alla domanda più interessante.

E se in futuro il video non fosse più il dato realmente importante?

Potrebbe essere semplicemente il raw sensor stream necessario per produrre qualcosa di più utile.

Oggi possiamo pensare:

Video
→ human watches video

Domani potremmo pensare:

Video
→ machines understand observations
→ observations become spatial events
→ events update knowledge
→ humans interrogate the knowledge

Non cercheremo necessariamente il minuto 32:18 di un filmato.

Potremmo chiedere:

Quali segnali stradali sono cambiati nell'ultima settimana?

oppure:

Mostrami tutti gli asset osservati almeno tre volte la cui condizione sta peggiorando.

oppure:

Dove sono state osservate anomalie che non trovano corrispondenza nel mio GIS?

E soltanto a quel punto il sistema recupererebbe il frame originale come evidence.


La vera evoluzione: dal Geospatial Video al Geospatial Knowledge

La direzione potrebbe quindi essere questa:

VIDEO
  ↓
GEOSPATIAL VIDEO
  ↓
GEOSPATIAL OBSERVATIONS
  ↓
SPATIAL EVENTS
  ↓
SPATIAL KNOWLEDGE
  ↓
CONTINUOUSLY UPDATED DIGITAL TWIN

Il passaggio concettuale è enorme.

Il video non è più semplicemente qualcosa da visualizzare sopra una mappa.

Diventa uno dei sensori attraverso cui il GIS osserva il mondo.


Privacy, governance e provenance

Più questi sistemi diventano potenti, più diventano importanti governance e privacy.

Una piattaforma mobile può inevitabilmente raccogliere:

  • volti;
  • targhe;
  • persone;
  • abitazioni;
  • attività private;
  • informazioni potenzialmente sensibili.

Diventano quindi importanti tecniche come:

face detection → anonymization
license plate detection → anonymization
retention policy
access control
audit trail
data lineage
model provenance

In alcune architetture l'edge processing può diventare interessante anche da questo punto di vista.

La camera potrebbe anonimizzare o scartare informazioni prima che lascino il dispositivo.


Conclusione

L'articolo Esri sul geospatial video può sembrare, a prima vista, una panoramica delle possibilità offerte da ArcGIS Pro, Full Motion Video e Oriented Imagery.

In realtà apre una porta molto più grande.

Drone, dashcam, smartphone, action camera e sistemi 360° stanno rapidamente diventando sensori geospaziali economici e onnipresenti.

Quando combiniamo:

Camera
+
GNSS
+
IMU
+
Camera Geometry
+
Computer Vision
+
GeoAI
+
GIS

otteniamo qualcosa di profondamente diverso dal semplice video georeferenziato.

Otteniamo una piattaforma capace di osservare il territorio, riconoscere oggetti, localizzarli, confrontarli con ciò che il GIS già conosce e produrre nuove informazioni.

E con VLM, edge AI, SLAM e digital twin continuamente aggiornati, il passo successivo potrebbe essere ancora più radicale:

passare da sistemi GIS che descrivono il mondo a sistemi GIS che lo osservano continuamente.

Forse il futuro del geospatial video non sarà quindi guardare un filmato sopra una mappa.

Il futuro potrebbe essere utilizzare milioni di frame come una gigantesca rete di sensori capace di trasformare automaticamente ciò che accade nel mondo fisico in spatial knowledge.


Riferimenti

mercoledì 30 settembre 2026

DiskANN in Azure SQL: Vector Search, RAG e GeoAI direttamente nel database relazionale

La ricerca vettoriale sta progressivamente entrando nel cuore dei database relazionali. Non si tratta semplicemente di aggiungere una nuova funzione SQL: significa poter interrogare gli stessi dati contemporaneamente nello spazio relazionale, nello spazio geografico e nello spazio semantico degli embedding.

Con DiskANN, Azure SQL può memorizzare embedding e utilizzare un indice Approximate Nearest Neighbor direttamente accanto a tabelle, chiavi, transazioni, metadati, filtri di sicurezza e, potenzialmente, dati spaziali.

Per un architect questo apre una domanda interessante: abbiamo davvero bisogno di introdurre un vector database separato per ogni applicazione RAG?

In molti scenari la risposta potrebbe essere no.

Cos'è DiskANN

DiskANN significa Disk-based Approximate Nearest Neighbor. È una famiglia di tecniche sviluppate per eseguire rapidamente ricerche di similarità su collezioni vettoriali di grandi dimensioni.

Non genera embedding, non interpreta documenti e non è un Large Language Model. DiskANN interviene dopo che i dati sono già stati trasformati in vettori.

Document
    ↓
Text extraction
    ↓
Chunking
    ↓
Embedding model
    ↓
Vector
    ↓
Azure SQL
    ↓
DiskANN
    ↓
Nearest neighbors

Il problema che risolve è apparentemente semplice: dato un vettore q, trovare i vettori del database che gli sono più vicini.

Dallo spazio semantico allo spazio vettoriale

Un embedding model trasforma un oggetto, ad esempio una frase:

ArcGIS Enterprise supports federated GIS servers.

in una sequenza numerica:

[0.0182, -0.0317, 0.0041, ..., 0.0227]

Formalmente possiamo pensare all'embedding come a una funzione:

f : X → ℝᵈ

dove X è lo spazio degli oggetti originali e d è la dimensionalità del vettore.

La singola coordinata non ha generalmente un significato interpretabile isolatamente. È la posizione complessiva del vettore nello spazio multidimensionale a rappresentare le caratteristiche apprese dal modello.

Se due contenuti hanno significato simile, il modello tende a collocarli in regioni vicine dello spazio vettoriale.

Exact Nearest Neighbor: perché non basta

Il modo più semplice di trovare i vettori più vicini consiste nel confrontare la query con ogni vettore presente nella tabella.

query
  │
  ├── distance(vector 1)
  ├── distance(vector 2)
  ├── distance(vector 3)
  ├── ...
  └── distance(vector N)

Con N vettori e dimensionalità D, il lavoro cresce approssimativamente come:

O(N × D)

Con poche migliaia di record può essere perfettamente accettabile.

Con:

10.000.000 vectors
×
1.536 dimensions

la scansione esaustiva diventa invece molto più costosa.

È qui che entra in gioco l'Approximate Nearest Neighbor Search.

ANN: sacrificare un po' di perfezione per molta velocità

Un algoritmo ANN non garantisce necessariamente di restituire sempre gli stessi vicini che otterremmo esaminando esaustivamente l'intero dataset.

Accetta un compromesso:

Exactness
    ↓ leggermente

Search space
    ↓ drasticamente

Latency
    ↓ drasticamente

Supponiamo che i veri dieci nearest neighbors siano:

A B C D E F G H I J

e che ANN restituisca:

A B C D E F G H I K

Il recall@10 sarebbe:

9 / 10 = 0.90

Per molte pipeline RAG questo trade-off è estremamente conveniente: non abbiamo bisogno di dimostrare matematicamente quale chunk sia il più vicino, ma di recuperare molto rapidamente un insieme di candidati altamente rilevanti.

DiskANN e grafi di prossimità

DiskANN utilizza un approccio graph-based. Possiamo immaginare ogni embedding come un nodo collegato ad altri nodi utili per navigare nello spazio vettoriale.

              ●──────●
             /        \
        ●───●          ●
        │    \        /
        ●─────●──────●
               \
                ●────●

La ricerca non deve quindi fare:

query → confronta tutti i vettori

ma può procedere concettualmente attraverso il grafo:

query
  ↓
entry point
  ↓
candidate neighbors
  ↓
better neighbors
  ↓
better neighbors
  ↓
Top-K

Il grafo consente di raggiungere rapidamente regioni promettenti dello spazio senza valutare ogni riga.

Perché si chiama DiskANN

Uno degli elementi caratteristici del progetto DiskANN è l'attenzione alla possibilità di lavorare con collezioni vettoriali molto grandi senza dipendere esclusivamente dalla RAM.

              RAM
       ┌────────────────┐
       │ search state   │
       │ cache          │
       │ graph metadata │
       └───────┬────────┘
               │
               │ selective access
               ▼
       ┌────────────────┐
       │ SSD / storage  │
       │ vector data    │
       └────────────────┘

Naturalmente, quando utilizziamo DiskANN tramite Azure SQL non dobbiamo confondere il principio algoritmico con l'implementazione interna del servizio managed: cache, storage engine, I/O scheduling, quantizzazione e query optimization sono responsabilità del database engine.

DiskANN è ora production-ready su Azure SQL

Il 29 settembre 2026 Microsoft ha annunciato la General Availability di DiskANN Vector Index & Search su Azure SQL Database, su Azure SQL Managed Instance configurato con la policy di aggiornamento always-up-to-date e su SQL database in Microsoft Fabric.

La versione GA include elementi particolarmente importanti per workload reali:

  • Approximate Nearest Neighbor Search basata su DiskANN;
  • supporto a INSERT, UPDATE e DELETE;
  • manutenzione asincrona dell'indice vettoriale;
  • iterative filtering;
  • integrazione con il query optimizer;
  • possibilità di combinare vector search e predicati relazionali.

Il tipo VECTOR di SQL

Il database può memorizzare direttamente un embedding in una colonna vettoriale.

Un modello dati orientato a RAG potrebbe essere:

CREATE TABLE dbo.Documents
(
    Id          BIGINT IDENTITY PRIMARY KEY,
    TenantId    INT NOT NULL,
    FileName    NVARCHAR(500) NOT NULL,
    Title       NVARCHAR(500) NULL,
    MimeType    NVARCHAR(100) NULL,
    CreatedAt   DATETIME2 NOT NULL
        DEFAULT SYSUTCDATETIME()
);

I chunk possono invece essere mantenuti separatamente:

CREATE TABLE dbo.DocumentChunks
(
    Id               BIGINT IDENTITY PRIMARY KEY,
    DocumentId       BIGINT NOT NULL,
    TenantId         INT NOT NULL,

    PageNumber       INT NULL,
    ChunkNumber      INT NOT NULL,

    Content          NVARCHAR(MAX) NOT NULL,

    EmbeddingModel   NVARCHAR(100) NOT NULL,
    ChunkingVersion  INT NOT NULL,

    Embedding        VECTOR(1536) NOT NULL,

    CONSTRAINT FK_DocumentChunks_Documents
        FOREIGN KEY (DocumentId)
        REFERENCES dbo.Documents(Id)
);

1536 è solamente un esempio. La dimensionalità deve essere coerente con il modello che genera gli embedding.

Versionare embedding e pipeline

Un embedding dovrebbe essere trattato come dato derivato, non come sorgente primaria.

Conviene quindi conservare almeno:

Original document
Extracted content
Chunk
ChunkingVersion
Embedding
EmbeddingModel
EmbeddingVersion
CreatedAt

Questa informazione diventa fondamentale quando cambiamo modello.

Due modelli differenti possono produrre spazi vettoriali differenti: non possiamo semplicemente mischiare embedding generati da modelli diversi e aspettarci che le distanze rimangano semanticamente confrontabili.

Creazione dell'indice DiskANN

Sulla colonna vettoriale possiamo creare un indice:

CREATE VECTOR INDEX IX_DocumentChunks_Embedding
ON dbo.DocumentChunks(Embedding)
WITH
(
    METRIC = 'cosine',
    TYPE = 'diskann'
);

Le metriche supportate dalla vector search SQL comprendono:

  • cosine;
  • dot;
  • euclidean.

La metrica non va scelta arbitrariamente: deve essere coerente con il modello di embedding e con il modo in cui è stato addestrato.

Exact search con VECTOR_DISTANCE

Possiamo eseguire una ricerca esatta calcolando la distanza:

DECLARE @query VECTOR(1536) = @QueryEmbedding;

SELECT TOP (10)
    Id,
    DocumentId,
    Content,
    VECTOR_DISTANCE(
        'cosine',
        @query,
        Embedding
    ) AS Distance
FROM dbo.DocumentChunks
ORDER BY Distance;

Questa strategia è utile anche come baseline per misurare la qualità dell'indice ANN.

Possiamo infatti confrontare:

Exact Top-K
     vs
DiskANN Top-K

e misurare il recall effettivo sul nostro dataset.

Approximate search con VECTOR_SEARCH

Con gli indici vettoriali di nuova generazione la sintassi corrente utilizza VECTOR_SEARCH insieme a:

TOP (N) WITH APPROXIMATE

Ad esempio:

DECLARE @query VECTOR(1536) = @QueryEmbedding;

SELECT TOP (10) WITH APPROXIMATE
    c.Id,
    c.DocumentId,
    c.Content,
    r.distance
FROM VECTOR_SEARCH(
    TABLE = dbo.DocumentChunks AS c,
    COLUMN = Embedding,
    SIMILAR_TO = @query,
    METRIC = 'cosine'
) AS r
ORDER BY r.distance;

La precedente forma basata sul parametro:

TOP_N = 10

appartiene alla generazione precedente dell'indice ed è deprecata per i nuovi indici.

WITH APPROXIMATE non è solo sintassi

Con:

SELECT TOP (10) WITH APPROXIMATE

stiamo dicendo esplicitamente al motore che accettiamo risultati ANN.

Senza WITH APPROXIMATE, VECTOR_SEARCH può eseguire una ricerca kNN esatta.

VECTOR_SEARCH
      │
      ├── exact kNN
      │
      └── approximate ANN / DiskANN

La distinzione è molto importante quando facciamo benchmarking.

Il query optimizer entra nella vector search

Uno degli aspetti architetturalmente più interessanti è che la ricerca vettoriale non viene trattata come una scatola completamente separata dal motore SQL.

Azure SQL può valutare se utilizzare la strategia ANN oppure altre strategie in funzione della query e della selettività.

Supponiamo di avere:

100.000.000 chunks

ma di applicare:

WHERE TenantId = 42

e che il tenant 42 contenga soltanto 5.000 chunk. In determinate condizioni un piano differente potrebbe risultare più conveniente rispetto all'attraversamento del grafo ANN globale.

FORCE_ANN_ONLY

Quando vogliamo imporre l'utilizzo dell'indice Approximate Nearest Neighbor, Azure SQL mette a disposizione anche l'hint:

FORCE_ANN_ONLY

Concettualmente:

SELECT TOP (10) WITH APPROXIMATE
    ...
FROM VECTOR_SEARCH(
    TABLE = dbo.DocumentChunks AS c,
    COLUMN = Embedding,
    SIMILAR_TO = @query,
    METRIC = 'cosine'
) AS r WITH (FORCE_ANN_ONLY)
ORDER BY r.distance;

È utile soprattutto per test, benchmark o casi in cui sappiamo esattamente quale strategia vogliamo utilizzare.

Come ogni hint SQL, non dovrebbe diventare automaticamente la scelta predefinita.

Iterative filtering: fondamentale per sistemi reali

Immaginiamo una piattaforma SaaS multi-tenant.

Il retrieval deve rispettare:

TenantId = 42

Una implementazione ANN ingenua potrebbe fare:

DiskANN
   ↓
10 nearest vectors
   ↓
WHERE TenantId = 42
   ↓
2 risultati validi

Gli altri otto vettori potrebbero appartenere ad altri tenant.

Con l'iterative filtering la ricerca può continuare nel grafo finché non vengono trovati abbastanza risultati che soddisfano il predicato:

DiskANN
   ↓
candidate set
   ↓
relational filter
   ↓
enough results?
   │
   ├── yes → return Top-K
   │
   └── no
        ↓
   continue graph traversal
        ↓
   more candidates
        ↓
   relational filter

Questa caratteristica è importantissima per:

  • multi-tenancy;
  • ACL;
  • categorie;
  • stati applicativi;
  • vincoli temporali;
  • filtri geografici o amministrativi;
  • security policies.

Vector search e security boundary

In un'applicazione RAG enterprise la sicurezza non deve essere applicata dopo il retrieval.

Il flusso corretto deve essere progettato come:

User
 ↓
Identity
 ↓
Tenant / ACL / Security Policy
 ↓
Vector retrieval
 ↓
Permitted chunks
 ↓
LLM

In altre parole: il retrieval fa parte del security boundary dell'applicazione.

Il vero RAG inizia prima di DiskANN

Una delle semplificazioni più pericolose è pensare che una pipeline RAG sia:

PDF → embedding → vector database

Una pipeline seria assomiglia molto di più a:

                   PDF
                    │
          ┌─────────┴──────────┐
          │                    │
     Native text          Scanned PDF
          │                    │
   Text extraction            OCR
          │                    │
          └─────────┬──────────┘
                    ↓
             normalization
                    ↓
          structure analysis
                    ↓
               chunking
                    ↓
               embedding
                    ↓
               Azure SQL
                    ↓
                DiskANN

PDF nativi e PDF scansionati

Un PDF può contenere un vero text layer. In questo caso è possibile estrarre direttamente:

Page
 ├── Heading
 ├── Paragraph
 ├── Paragraph
 └── Table

Un PDF scansionato può invece contenere essenzialmente immagini:

PDF
 ├── page-001 image
 ├── page-002 image
 └── page-003 image

In questo caso serve OCR.

In ambiente Azure una pipeline possibile è:

Azure Blob Storage
        ↓
Document ingestion service
        ↓
Azure AI Document Intelligence
        ↓
OCR + Layout + Tables + Structure
        ↓
Semantic chunking
        ↓
Embedding model
        ↓
Azure SQL
        ↓
DiskANN

Il punto importante è che non basta recuperare caratteri: serve preservare il più possibile la struttura semantica del documento.

Chunking: spesso più importante del vector database

Consideriamo un manuale tecnico di 500 pagine.

Creare:

manual.pdf → one embedding

è generalmente poco utile.

È molto più efficace ottenere:

manual.pdf
   │
   ├── chunk 001 → embedding
   ├── chunk 002 → embedding
   ├── chunk 003 → embedding
   ├── ...
   └── chunk 850 → embedding

Fixed-size chunking

L'approccio più semplice consiste nel suddividere il testo per numero di token:

chunk 1 → tokens   0 - 499
chunk 2 → tokens 450 - 949
chunk 3 → tokens 900 - 1399

L'overlap aiuta a evitare che un concetto venga spezzato esattamente sul confine tra due chunk.

Semantic chunking

Per documentazione tecnica possiamo però fare di meglio.

Section
 ├── paragraph
 ├── paragraph
 ├── code sample
 ├── table
 └── note

L'obiettivo è costruire unità informative semanticamente coerenti, non semplicemente blocchi di lunghezza costante.

Hierarchical chunking

Possiamo mantenere una gerarchia:

Document
   ↓
Chapter
   ↓
Section
   ↓
Chunk

Se DiskANN recupera il chunk 37 possiamo, ad esempio, recuperare anche:

chunk 36
chunk 37
chunk 38

oppure la sezione padre.

Per questo conviene conservare:

DocumentId
SectionId
ParentChunkId
PageNumber
ChunkNumber

Embedding generation lato applicazione

Una pipeline .NET può essere concettualmente molto semplice:

var chunks = chunker.Split(document);

foreach (var chunk in chunks)
{
    var embedding =
        await embeddingService.GenerateAsync(chunk.Text);

    db.DocumentChunks.Add(
        new DocumentChunk
        {
            DocumentId = documentId,
            TenantId = tenantId,
            PageNumber = chunk.Page,
            ChunkNumber = chunk.Index,
            Content = chunk.Text,
            EmbeddingModel = embedding.Model,
            ChunkingVersion = 1,
            Embedding = embedding.Vector
        });
}

await db.SaveChangesAsync();

Dal punto di vista architetturale terrei ben separati:

Extraction
Chunking
Embedding
Persistence
Indexing
Retrieval
Generation

Questo rende la pipeline versionabile, osservabile e riprocessabile.

Azure SQL può generare embedding direttamente

Lo stack SQL moderno consente anche di registrare modelli esterni e invocarli dal database.

Un external model può essere definito concettualmente così:

CREATE EXTERNAL MODEL MyEmbeddingModel
WITH
(
    LOCATION = '...',
    API_FORMAT = 'Azure OpenAI',
    MODEL_TYPE = EMBEDDINGS,
    MODEL = '...',
    CREDENTIAL = ...
);

e successivamente:

AI_GENERATE_EMBEDDINGS(
    N'ArcGIS Server federation'
    USE MODEL MyEmbeddingModel
)

Microsoft supporta inoltre scenari in cui AI_GENERATE_CHUNKS e AI_GENERATE_EMBEDDINGS vengono combinati direttamente da T-SQL.

Questo rende possibile una pipeline:

SQL row
   ↓
AI_GENERATE_CHUNKS
   ↓
AI_GENERATE_EMBEDDINGS
   ↓
VECTOR
   ↓
DiskANN

Embedding nel database o nell'applicazione?

Il fatto che qualcosa sia possibile in SQL non significa che debba necessariamente essere eseguito lì.

Generare embedding nell'application layer offre generalmente maggiore controllo su:

  • retry;
  • rate limiting;
  • batching;
  • fallback;
  • observability;
  • model routing;
  • versioning della pipeline.

Generarli direttamente nel database può invece semplificare alcune pipeline data-centric.

È quindi una decisione architetturale, non semplicemente sintattica.

RAG: Retrieve Wide, Rank Narrow

DiskANN non deve necessariamente restituire direttamente i chunk che finiranno nel prompt.

Una pipeline più sofisticata può essere:

10.000.000 chunks
       │
       │ DiskANN
       ↓
      50
       │
       │ reranker
       ↓
       8
       │
       │ context builder
       ↓
      LLM

Questo pattern viene spesso sintetizzato come:

Retrieve wide
     ↓
Rank narrow

Reranking

La prima fase privilegia throughput e recall.

Una seconda fase può utilizzare un modello più costoso per stimare meglio la rilevanza rispetto alla domanda originale:

Question
   +
50 candidate chunks
        ↓
     Reranker
        ↓
   Best 5 - 10

DiskANN e reranker risolvono quindi problemi differenti:

DiskANN:
find plausible candidates quickly

Reranker:
order those candidates accurately

Hybrid Search

Gli embedding non sostituiscono necessariamente la ricerca lessicale.

Una query come:

KB5034123 ArcGIS Server TLS

contiene token precisi, codici e identificativi che possono essere estremamente significativi.

Una strategia moderna può combinare:

Vector similarity
       +
Keyword search
       +
Relational filters
       +
Reranking

La vector search è quindi un ulteriore retrieval signal, non necessariamente l'unico.

.NET ed Entity Framework Core

Per chi sviluppa applicazioni .NET è importante distinguere le versioni.

In EF Core 10 Microsoft ha introdotto il supporto alla traduzione di VectorDistance(), quindi alla distanza vettoriale esatta.

In EF Core 11 Microsoft documenta inoltre le API dedicate a vector index e VECTOR_SEARCH.

Ad esempio:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<DocumentChunk>()
        .HasVectorIndex(
            x => x.Embedding,
            "cosine");
}

La ricerca ANN può essere espressa concettualmente come:

var results = await db.DocumentChunks
    .VectorSearch(
        x => x.Embedding,
        queryEmbedding,
        "cosine")
    .OrderBy(x => x.Distance)
    .Take(10)
    .WithApproximate()
    .ToListAsync();

WithApproximate() corrisponde semanticamente alla richiesta:

TOP (...) WITH APPROXIMATE

È però importante notare che Microsoft documenta attualmente queste API di EF Core 11 come funzionalità ancora soggette a evoluzione.

Per chi oggi usa .NET 10

In un'applicazione .NET 10 / EF Core 10 possiamo comunque utilizzare pienamente Azure SQL Vector Search attraverso T-SQL, stored procedure, raw SQL o VectorDistance() dove appropriato.

Non è quindi necessario aspettare EF Core 11 per costruire una soluzione DiskANN.

.NET 10
   ↓
EF Core / ADO.NET
   ↓
VECTOR_SEARCH T-SQL
   ↓
Azure SQL
   ↓
DiskANN

Architettura RAG completa su Azure

                 ┌────────────────────┐
                 │ Azure Blob Storage │
                 └─────────┬──────────┘
                           │
                           ▼
                 ┌────────────────────┐
                 │ .NET Ingestion     │
                 │ Worker / Service   │
                 └─────────┬──────────┘
                           │
            ┌──────────────┴──────────────┐
            │                             │
            ▼                             ▼
     Text extraction          Document Intelligence
                                     OCR/Layout
            │                             │
            └──────────────┬──────────────┘
                           ▼
                    Semantic Chunking
                           │
                           ▼
                     Embedding Model
                           │
                           ▼
                   ┌────────────────┐
                   │   Azure SQL    │
                   │                │
                   │ relational     │
                   │ metadata       │
                   │ security       │
                   │ chunks         │
                   │ vectors        │
                   │ DiskANN        │
                   └───────┬────────┘
                           │
                           ▼
                       Retrieval
                           │
                           ▼
                        Reranker
                           │
                           ▼
                    Context Builder
                           │
                           ▼
                          LLM
                           │
                           ▼
                       Response

Vector database dedicato o Azure SQL?

Non esiste una risposta universale.

Un vector database specializzato può essere preferibile quando:

  • la vector search domina completamente il workload;
  • la scala è estremamente elevata;
  • servono feature vector-native molto specializzate;
  • l'architettura richiede distribuzione specificamente progettata per ANN.

Azure SQL è invece particolarmente interessante quando:

  • i dati applicativi sono già relazionali;
  • servono transazioni;
  • la sicurezza dipende dal modello relazionale;
  • i filtri sui metadati sono importanti;
  • vogliamo evitare sincronizzazione tra database;
  • vector search integra, ma non sostituisce, il workload applicativo.

La domanda corretta diventa quindi:

Which vector database should I add?

oppure:

Do I actually need another database?

Sono due domande architetturalmente molto diverse.

DiskANN + Spatial SQL: il collegamento con il GIS

Per chi lavora con GIS la parte più interessante inizia probabilmente qui.

Una feature geografica potrebbe avere contemporaneamente:

Feature
 ├── Id
 ├── Geometry
 ├── Attributes
 ├── Description
 ├── Category
 ├── Temporal information
 └── Embedding

La stessa entità appartiene quindi a tre spazi differenti.

Relational space
Geographic space
Semantic vector space

Tre tipi diversi di distanza

Consideriamo due aree territoriali.

La distanza geografica può essere:

180 km

ma la loro distanza nello spazio degli embedding può indicare una fortissima similarità:

Semantic similarity = very high

Due territori possono essere lontani fisicamente ma molto simili rispetto a:

  • demografia;
  • uso del suolo;
  • mobilità;
  • densità commerciale;
  • accessibilità;
  • servizi;
  • indicatori economici;
  • caratteristiche ambientali.

GeoAI: da distanza geometrica a similarità funzionale

Una possibile query concettuale potrebbe essere:

Find areas

within 50 km

AND

land_use = 'industrial'

AND

area > 50000 m²

AND

semantically similar to:

"areas suitable for logistics,
close to major transport infrastructure,
with low residential pressure"

Qui stiamo combinando:

Spatial predicate
       +
Relational predicate
       +
Vector similarity

Spatial Index e Vector Index sono concetti differenti

Uno spatial index indicizza oggetti come:

POINT
LINESTRING
POLYGON

Un vector index indicizza invece:

[0.018, -0.032, 0.004, ..., 0.071]

Il fatto che entrambi utilizzino la parola "vector" in alcuni contesti non deve creare confusione.

Sono strutture pensate per risolvere problemi completamente differenti.

Ma possono lavorare insieme.

Un possibile modello GeoAI

CREATE TABLE GeoAssets
(
    Id           BIGINT PRIMARY KEY,
    TenantId     INT NOT NULL,

    Name         NVARCHAR(250),
    Category     NVARCHAR(100),

    Geometry     GEOGRAPHY,

    Description  NVARCHAR(MAX),

    Embedding    VECTOR(1536)
);

Concettualmente potremmo eseguire:

Relational filtering
        ↓
Spatial filtering
        ↓
Vector retrieval
        ↓
Reranking
        ↓
GeoAI result

Embedding territoriali

Possiamo andare ancora oltre e generare un embedding non da un semplice testo, ma da una rappresentazione complessa del territorio.

Territory
   │
   ├── Population
   ├── Income
   ├── Land use
   ├── Mobility
   ├── POIs
   ├── Accessibility
   ├── Satellite features
   └── Demographics
             │
             ▼
          Encoder
             │
             ▼
       Territory embedding

A quel punto possiamo chiedere:

Find areas similar to this area

senza limitarci a una distanza euclidea o geografica.

Passiamo dalla prossimità geometrica alla similarità funzionale appresa.

Osservabilità

Una pipeline RAG production-grade va misurata end-to-end.

Almeno:

Document extraction latency
OCR latency
Chunking throughput
Embedding latency
Embedding failures
Indexing throughput
ANN latency
Exact KNN latency
Recall@K
Reranking latency
Context size
LLM latency
Token usage
End-to-end latency

Possiamo modellare la latenza totale come:

Ttotal =
    Textract
  + Tembed
  + Tretrieve
  + Trerank
  + Tcontext
  + Tllm

Ottimizzare DiskANN di 10 ms ha poco senso se la generazione dell'LLM richiede diversi secondi.

Valutare scientificamente il retrieval

Un buon sistema RAG non dovrebbe essere valutato soltanto chiedendo:

La risposta sembra buona?

Dobbiamo costruire un dataset di valutazione:

Question
Expected relevant chunks
Expected source documents

e misurare:

  • Recall@K;
  • Precision@K;
  • MRR;
  • NDCG;
  • latency;
  • cost per query.

Possiamo così confrontare in modo ripetibile:

Embedding Model A vs B

Chunk size 300 vs 800

Overlap 50 vs 150

Exact KNN vs DiskANN

Top-10 vs Top-50

With reranker vs without reranker

Vector-only vs Hybrid Search

DiskANN non sostituisce il database design

La presenza di embedding non rende improvvisamente irrilevanti:

  • primary key;
  • foreign key;
  • indici B-tree;
  • statistics;
  • query plans;
  • partitioning;
  • security;
  • transactions;
  • data lifecycle;
  • backup e disaster recovery.

La vector search è un'altra modalità di accesso al dato, non un sostituto del modello relazionale.

La vera convergenza

L'aspetto più interessante di Azure SQL + DiskANN non è poter eseguire una query con cosine distance.

È poter mantenere nello stesso dominio dati:

Transactions
Business entities
Users
Security
Documents
Metadata
Spatial objects
Embeddings

e interrogarli utilizzando:

Relational Search
Full-Text Search
Spatial Search
Vector Search

L'AI non deve necessariamente possedere una copia parallela del database aziendale.

Può diventare un'altra modalità con cui l'applicazione interroga gli stessi dati operativi.

Conclusione

DiskANN è interessante dal punto di vista algoritmico perché rende possibile una Approximate Nearest Neighbor Search efficiente su collezioni vettoriali di grandi dimensioni.

Ma il cambiamento più importante è probabilmente architetturale.

Azure SQL
   │
   ├── Relational data
   ├── Transactions
   ├── Security
   ├── Documents
   ├── Spatial data
   ├── Vectors
   └── DiskANN

In una moderna applicazione AI questo può ridurre la necessità di introdurre un'infrastruttura dati parallela esclusivamente per il retrieval vettoriale.

E nel GIS il concetto diventa ancora più interessante.

Relational space
      +
Geographic space
      +
Semantic vector space
      ↓
     GeoAI

La domanda GIS tradizionale:

What is near this location?

può evolvere verso:

What is geographically, semantically and functionally similar to this location?

È qui che DiskANN smette di essere semplicemente una tecnologia per "fare RAG sui PDF" e diventa qualcosa di più generale: un nuovo strumento per interrogare dati, conoscenza e territorio.

Riferimenti tecnici

martedì 29 settembre 2026

Embedding nel GIS: quando una posizione geografica diventa un vettore

Negli ultimi anni il concetto di embedding è diventato centrale nel mondo dell'intelligenza artificiale. Nei Large Language Model una frase, un documento o un concetto vengono trasformati in un vettore numerico che ne rappresenta, in modo distribuito, il significato.

Lo stesso paradigma sta entrando nel GIS.

Una posizione geografica, un quartiere, una cella territoriale, un'immagine satellitare o una feature GIS possono essere rappresentati non soltanto attraverso coordinate, geometrie e attributi, ma attraverso un vettore ad alta dimensionalità appreso da un modello.

Il risultato è un cambiamento concettuale importante:

da "dove si trova questa feature?" e "quali attributi possiede?" a "che tipo di luogo rappresenta e quali altri luoghi le assomigliano?"

ArcGIS sta integrando questo paradigma direttamente nei propri workflow GeoAI. Gli USA Geodemographic Embeddings 2026 ne sono un esempio particolarmente interessante: migliaia di variabili demografiche, socioeconomiche, abitative e ambientali vengono trasformate in un vettore compatto di 256 dimensioni per ogni area geografica.

Ma il concetto va molto oltre quel dataset specifico. Gli embedding possono diventare una nuova primitiva dell'informazione geografica, insieme a geometria, attributi, topologia e coordinate.

1. Un embedding è prima di tutto algebra lineare

Formalmente possiamo descrivere un encoder come una funzione:

f : X → R^d

dove X rappresenta lo spazio originale dei dati e R^d uno spazio vettoriale di dimensione d.

Un oggetto complesso:

x ∈ X

viene trasformato in:

e = f(x)

e = [e₀, e₁, e₂, ..., e₍d-1₎]

Il vettore e viene chiamato embedding.

Nel caso di un modello linguistico:

"spatial database for urban analysis"
                │
                ▼
             Encoder
                │
                ▼
[0.18, -0.42, 0.71, ..., -0.09]

Nel caso GIS potremmo invece avere:

Location / Area / Raster / Feature
                │
                ▼
       Geospatial Encoder
                │
                ▼
[0.31, 0.08, -0.67, ..., 0.22]

La caratteristica fondamentale è che le singole componenti del vettore normalmente non hanno un significato interpretabile isolatamente.

Non possiamo quindi dire:

embedding[17] = reddito
embedding[42] = densità
embedding[103] = urbanizzazione

Il significato è distribuito nell'intero spazio latente.

È il pattern complessivo delle componenti a rappresentare il fenomeno.

2. Coordinate ed embedding non sono la stessa cosa

Nel GIS siamo già abituati a rappresentare un punto attraverso numeri:

P = (x, y)

oppure:

P = (longitude, latitude)

Ma queste coordinate descrivono esclusivamente la posizione geometrica.

Un location embedding risponde a una domanda differente.

Coordinate:
45.46, 9.19

Embedding:
[0.31, -0.12, 0.77, ..., -0.22]

Le coordinate dicono:

Dove si trova questo luogo?

L'embedding cerca invece di codificare:

Che tipo di luogo è?

A seconda del modello utilizzato, il vettore può rappresentare informazioni relative a:

  • urbanizzazione;
  • demografia;
  • uso del suolo;
  • morfologia urbana;
  • vegetazione;
  • infrastrutture;
  • caratteristiche ambientali;
  • immagini satellitari;
  • POI;
  • mobilità;
  • testi associati alla feature;
  • relazioni spaziali con altre entità.

Quindi:

geometry ≠ embedding

Sono due rappresentazioni complementari dello stesso oggetto geografico.

3. Due spazi differenti: geographic space ed embedding space

Questa distinzione porta a uno dei concetti più interessanti del GeoAI.

Nel normale spazio geografico possiamo avere:

A ●--------------------------------● B
              500 km

La distanza viene calcolata utilizzando coordinate, sistemi di riferimento e metriche spaziali.

Nello spazio degli embedding, gli stessi oggetti potrebbero invece essere:

A ●----● B

perché, nonostante siano geograficamente lontani, presentano caratteristiche estremamente simili.

Oppure due aree fisicamente vicine:

Geographic space

A ●---● B

Embedding space

A ●-------------------------------● B

potrebbero risultare molto differenti dal punto di vista socioeconomico, urbanistico o ambientale.

Possiamo quindi distinguere due funzioni:

SpatialDistance(A, B)

e:

EmbeddingDistance(E(A), E(B))

La prima misura una relazione nello spazio geografico. La seconda misura una relazione nello spazio latente appreso dal modello.

4. La cosine similarity

Uno dei modi più comuni per confrontare embedding è la cosine similarity.

Dati due vettori A e B:

               A · B
cos(A,B) = -----------------
             ||A|| ||B||

Il prodotto scalare è:

A · B = Σ AᵢBᵢ

mentre la norma euclidea è:

||A|| = √Σ Aᵢ²

La cosine similarity misura essenzialmente l'angolo fra due vettori.

Se i vettori normalizzati puntano nella stessa direzione:

similarity → 1

sono molto simili secondo lo spazio semantico costruito dal modello.

Attenzione però a un errore interpretativo frequente:

una cosine similarity di 0.90 non significa che due luoghi siano "uguali al 90%".

È una misura geometrica nello spazio degli embedding, il cui significato dipende dal modello, dal training e dalla distribuzione dei dati.

5. Calcolare la similarity con NumPy

Il calcolo è estremamente semplice.

import numpy as np

a = np.array([0.21, 0.74, -0.32, 0.61], dtype=np.float32)
b = np.array([0.19, 0.70, -0.29, 0.58], dtype=np.float32)

similarity = np.dot(a, b) / (
    np.linalg.norm(a) *
    np.linalg.norm(b)
)

print(similarity)

Dietro una parte importante della cosiddetta "semantic search" c'è quindi algebra lineare relativamente semplice.

La parte complessa non è il confronto fra i vettori.

La vera complessità consiste nel costruire uno spazio vettoriale nel quale la distanza abbia un significato utile per il dominio applicativo.

6. Che cosa possiamo trasformare in embedding nel GIS?

Praticamente qualsiasi sorgente informativa associata allo spazio.

                         GIS Feature
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                   │
          ▼                   ▼                   ▼
       Geometry             Imagery           Attributes
          │                   │                   │
          ▼                   ▼                   ▼
    Geo Encoder          Vision Encoder      Tabular/Text
          │                   │                   │
          └───────────────────┼───────────────────┘
                              │
                              ▼
                         Embedding
                     [e₀ ... eₙ]

Location embeddings

Rappresentano il contesto associato a una posizione geografica.

Image embeddings

Un modello visuale o geospatial foundation model trasforma chip di immagini satellitari o aeree in vettori.

Text embeddings

Descrizioni, metadata, documenti, toponimi e altri campi testuali collegati a feature GIS possono essere trasformati in vettori semantici.

Geodemographic embeddings

Comprimono centinaia o migliaia di indicatori territoriali in una rappresentazione numerica compatta.

Multimodal embeddings

È probabilmente la direzione più interessante:

Satellite imagery ──► Vision encoder ──────┐
                                           │
Demography ─────────► Tabular encoder ─────┤
                                           │
POI ─────────────────► POI encoder ────────┼──► PLACE EMBEDDING
                                           │
Text ────────────────► Text encoder ───────┤
                                           │
Road network ────────► Graph encoder ──────┘

Il risultato sarebbe una sorta di fingerprint digitale del luogo.

7. Gli USA Geodemographic Embeddings di Esri

Un'implementazione concreta di questo paradigma è rappresentata dagli USA Geodemographic Embeddings 2026 disponibili nell'ecosistema ArcGIS.

Gli embedding vengono costruiti attraverso il Geodemographic Foundation Model (GDFM) di Esri.

Il modello utilizza quattro grandi viste informative.

Dataset Informazione Variabili
Age & Race Census Struttura demografica e variazioni nel tempo 2.049
American Community Survey Istruzione, lavoro, reddito, commuting, household 1.617
Housing & Household Housing units, occupancy, tenure, composizione familiare 1.521
Environment Temperatura, precipitazioni, land cover e indicatori fisici 113

Parliamo quindi di oltre 5.000 variabili originarie.

Dopo preprocessing, pulizia, imputazione e scaling, queste informazioni vengono elaborate da un'architettura multiview autoencoder.

8. Multiview autoencoder: come nasce il vettore

Un autoencoder classico contiene due parti:

Input
  │
  ▼
Encoder
  │
  ▼
Latent representation
  │
  ▼
Decoder
  │
  ▼
Reconstructed input

L'obiettivo del training è ricostruire il più fedelmente possibile l'input dopo averlo compresso attraverso uno spazio latente più piccolo.

Nel modello geodemografico Esri il concetto viene esteso utilizzando viste informative differenti:

Census ─────────► Encoder 1 ──┐
                              │
ACS ────────────► Encoder 2 ──┤
                              │
Housing ────────► Encoder 3 ──┼──► Latent vector
                              │      256 dimensions
Environment ────► Encoder 4 ──┘
                                      │
                    ┌─────────────────┼─────────────────┐
                    ▼                 ▼                 ▼
                 Decoder          Decoder           Decoder
                    │                 │                 │
                    ▼                 ▼                 ▼
              reconstruct         reconstruct       reconstruct

Il modello viene addestrato minimizzando l'errore di ricostruzione delle differenti viste.

Il vettore latente finale ha:

D = 256

dimensioni.

Un intero territorio viene quindi trasformato da migliaia di variabili esplicite a:

E(location) ∈ R²⁵⁶

senza che ciascuna dimensione debba corrispondere direttamente a una singola variabile originale.

9. H3 come unità spaziale

Gli USA Geodemographic Embeddings vengono distribuiti utilizzando celle Uber H3 resolution 7.

Concettualmente:

territory
    │
    ▼
H3 tessellation
    │
    ├── hex 1 ──► embedding[256]
    ├── hex 2 ──► embedding[256]
    ├── hex 3 ──► embedding[256]
    │
    └── ...

Questa scelta è importante perché l'embedding diventa associato a un'unità spaziale uniforme e interrogabile come una normale feature GIS.

10. ArcGIS Pro: gli embedding diventano un tipo di informazione GIS

ArcGIS Pro dispone oggi di un toolset dedicato alla Embeddings Based Analysis.

Tra gli strumenti principali troviamo:

  • Generate Embeddings Using AI Models;
  • Find Similar Features Using Embeddings;
  • Merge Embeddings;
  • Extract Embeddings To Fields.

Questo è rilevante architetturalmente.

L'embedding non viene più considerato soltanto un artefatto interno a una pipeline di machine learning, ma diventa un elemento persistente del dataset GIS.

11. Come ArcGIS memorizza realmente un embedding

ArcGIS Pro persiste gli embedding in un campo geodatabase di tipo BLOB chiamato normalmente Embedding.

La rappresentazione è particolarmente interessante per uno sviluppatore.

Ogni componente viene serializzata come:

IEEE-754 32-bit floating point
little-endian

Il payload è costituito semplicemente dalla sequenza dei valori:

[e₀][e₁][e₂]...[e₍D-1₎]

senza header, delimitatori o metadata aggiuntivi.

Ogni componente occupa:

4 bytes

perciò:

payload_size = D × 4

Per un embedding da 256 dimensioni:

256 × 4 = 1024 bytes

ovvero circa 1 KB per feature, senza considerare l'overhead del database.

12. Leggere direttamente il BLOB con Python

import arcpy
import numpy as np

feature_class = r"C:\GIS\Data.gdb\Embeddings"
dimension = 256

with arcpy.da.SearchCursor(
    feature_class,
    ["OBJECTID", "Embedding"]
) as cursor:

    for object_id, blob in cursor:

        if blob is None:
            continue

        expected_size = dimension * 4

        if len(blob) != expected_size:
            raise ValueError(
                f"Embedding non valido per OID {object_id}: "
                f"{len(blob)} bytes invece di {expected_size}"
            )

        vector = np.frombuffer(
            blob,
            dtype="<f4"
        )

        print(object_id, vector.shape)

Il dtype:

<f4

significa:

  • < = little-endian;
  • f = floating point;
  • 4 = quattro byte.

13. Scrivere un embedding in una Feature Class

È possibile effettuare anche l'operazione opposta.

import arcpy
import numpy as np

embedding = np.array(
    [0.12, -0.98, 1.42, 0.33],
    dtype="<f4"
)

embedding_bytes = np.asarray(
    embedding,
    dtype="<f4",
    order="C"
).tobytes()

with arcpy.da.InsertCursor(
    feature_class_path,
    ["SHAPE@", "Name", "Embedding"]
) as cursor:

    cursor.insertRow([
        geometry,
        "Sample Feature",
        embedding_bytes
    ])

Questo apre una possibilità interessante: gli embedding non devono necessariamente essere generati da ArcGIS.

Possiamo produrli attraverso un modello esterno, serializzarli nel formato previsto e inserirli in una feature class per utilizzarli nei workflow GIS.

14. Base64 e Feature Service

Quando il BLOB deve transitare attraverso un canale testuale, ad esempio JSON o REST, il payload binario viene normalmente rappresentato attraverso Base64.

Float32[]
   │
   ▼
binary payload
   │
   ▼
Base64
   │
   ▼
JSON / REST

La rappresentazione logica del vettore non cambia.

15. Similarity Search in ArcGIS Pro

Supponiamo di voler trovare negli Stati Uniti aree con caratteristiche analoghe a una determinata zona universitaria.

Il workflow concettuale è:

Query polygon
      │
      ▼
intersect embedding cells
      │
      ▼
E₁, E₂, ..., Eₙ
      │
      ▼
mean embedding
      │
      ▼
       Q
      │
      ▼
cosine similarity
      │
      ▼
all embeddings
      │
      ▼
SIMILARITY ≥ threshold
      │
      ▼
output Feature Class

Se la query interessa più feature, ArcGIS costruisce un unico query embedding attraverso la media:

        1
Q = -------- Σ Eᵢ
        n

Il vettore risultante viene quindi confrontato con gli embedding dello spazio di ricerca utilizzando la cosine similarity.

16. ArcPy: Find Similar Features Using Embeddings

L'operazione può essere automatizzata direttamente in Python:

import arcpy

embedding_features = (
    r"C:\GIS\GeoAI.gdb\LocationEmbeddings"
)

query_features = (
    r"C:\GIS\GeoAI.gdb\QueryArea"
)

output_features = (
    r"C:\GIS\GeoAI.gdb\SimilarAreas"
)

threshold = 0.85

arcpy.geoai.FindSimilarFeaturesUsingEmbeddings(
    embedding_features,
    query_features,
    output_features,
    threshold
)

Il risultato è una nuova feature class contenente le feature che superano la soglia di similarità.

Questa query:

Find areas similar to this area

è profondamente diversa da:

Find areas within 50 km

oppure:

population > 100000
AND income BETWEEN ...
AND age BETWEEN ...
AND ...

Nel primo caso non stiamo definendo manualmente le caratteristiche che rendono due aree simili.

Utilizziamo invece la struttura dello spazio latente appresa dal modello.

17. Implementare la stessa ricerca senza il tool ArcGIS

Possiamo riprodurre il concetto direttamente con NumPy.

import numpy as np

# N feature × D dimensioni
embeddings = np.asarray(embeddings, dtype=np.float32)

# D dimensioni
query = np.asarray(query, dtype=np.float32)

# normalizzazione
embeddings_norm = embeddings / np.linalg.norm(
    embeddings,
    axis=1,
    keepdims=True
)

query_norm = query / np.linalg.norm(query)

# similarity di tutte le feature in una singola operazione matriciale
scores = embeddings_norm @ query_norm

threshold = 0.85

matching_indices = np.where(
    scores >= threshold
)[0]

for index in matching_indices:
    print(index, scores[index])

Questa riga:

scores = embeddings_norm @ query_norm

è particolarmente significativa.

Con una singola moltiplicazione matrice-vettore otteniamo la similarità fra la query e tutte le feature.

18. Il problema della scala: brute force e ANN

Su qualche migliaio di feature un confronto esaustivo è perfettamente gestibile.

Se però abbiamo:

10 milioni di feature
×
768 dimensioni

la ricerca lineare diventa più costosa.

È qui che entrano in gioco gli algoritmi di Approximate Nearest Neighbor, o ANN.

Tra le strutture più utilizzate troviamo:

  • HNSW;
  • IVF;
  • IVF-PQ;
  • product quantization;
  • graph-based vector indexes.

Il concetto è analogo a ciò che da decenni facciamo nei database spaziali.

GIS

Geometry
   │
   ▼
Spatial Index
R-tree / grid / other
   │
   ▼
candidate pruning
   │
   ▼
exact geometry operation

nel mondo vettoriale:

Embedding
   │
   ▼
Vector Index
HNSW / IVF / ...
   │
   ▼
candidate pruning
   │
   ▼
vector similarity

19. Spatial Index + Vector Index

La combinazione delle due tecnologie è probabilmente una delle architetture GIS più interessanti dei prossimi anni.

Feature
   │
   ├── Geometry
   │      │
   │      └── Spatial Index
   │
   ├── Attributes
   │      │
   │      └── B-tree / column index
   │
   └── Embedding
          │
          └── Vector Index

La stessa entità può essere interrogata secondo tre dimensioni differenti:

  • dove si trova;
  • quali proprietà possiede;
  • a cosa assomiglia.

20. La query GIS del futuro

Una query concettuale potrebbe diventare:

SELECT *
FROM Places
WHERE ST_Distance(
        Geometry,
        @SearchPoint
      ) < 50000
ORDER BY VectorDistance(
        Embedding,
        @QueryEmbedding
      )
LIMIT 20;

Prima applichiamo un vincolo geografico:

entro 50 km

e successivamente ordiniamo i candidati in base alla similarità semantica:

più simili al luogo di riferimento

Spatial query e vector search non sono quindi tecnologie concorrenti.

Risolvono dimensioni differenti dello stesso problema.

21. Aggregare gli embedding nello spazio

Un problema molto GIS riguarda il cambio di scala.

Supponiamo di avere embedding a livello H3 ma di voler effettuare un'analisi a livello di contea:

H3 embeddings
     │
     ▼
spatial overlay
     │
     ▼
County
     │
     ▼
aggregated embedding

ArcGIS Pro mette a disposizione Merge Embeddings.

Quando le sorgenti sono poligonali, l'aggregazione considera l'area di sovrapposizione con il poligono target.

In termini concettuali:

                 Σ wᵢ Eᵢ
E_target = -----------------------
                    Σ wᵢ

dove il peso può dipendere dall'area di overlap.

Questo introduce un problema affascinante:

che cosa significa aggregare semanticamente lo spazio?

Nella statistica tradizionale sappiamo aggregare popolazione, reddito, superficie o densità.

Con gli embedding stiamo aggregando invece rappresentazioni latenti apprese.

22. Merge Embeddings con ArcPy

import arcpy

target_features = r"C:\GIS\Data.gdb\Counties"

embedding_features = (
    r"C:\GIS\Data.gdb\H3_Embeddings"
)

output = (
    r"C:\GIS\Data.gdb\CountyEmbeddings"
)

arcpy.geoai.MergeEmbeddings(
    target_features,
    embedding_features,
    output
)

23. Da BLOB a variabili esplicative

Molti algoritmi tradizionali di machine learning si aspettano una matrice tabulare:

X =
[
  [x₁₁, x₁₂, ..., x₁d],
  [x₂₁, x₂₂, ..., x₂d],
  ...
]

Per questo ArcGIS permette di estrarre le componenti dell'embedding dal BLOB creando campi come:

emb_0
emb_1
emb_2
...
emb_255

Il dataset diventa quindi:

OBJECTID
SHAPE
Population
Income
...
emb_0
emb_1
...
emb_255

e può essere utilizzato come input di modelli di regressione, classificazione, clustering o AutoML.

24. Embedding come feature engineering automatizzato

Tradizionalmente un data scientist GIS potrebbe costruire manualmente decine o centinaia di variabili:

population_density
median_income
road_density
distance_to_station
green_area_percentage
building_density
average_age
employment_rate
...

Questa attività viene chiamata feature engineering.

Un embedding può essere visto, con le dovute cautele, come una forma di:

learned feature engineering.

Il modello apprende automaticamente una rappresentazione compatta delle relazioni presenti nei dati.

Questo non significa che gli attributi originali diventino inutili.

Al contrario, una delle strategie più potenti consiste nel combinare:

domain variables
      +
spatial variables
      +
embedding dimensions
      │
      ▼
ML model

25. Un embedding non è una spiegazione

Questa distinzione è fondamentale.

Se un modello utilizza:

median_income = 42,000

la variabile è interpretabile.

Se utilizza:

emb_147 = -0.2738

quel numero, da solo, normalmente non ha alcun significato leggibile.

Gli embedding introducono quindi un trade-off:

feature engineering manuale
        │
        ├── maggiore interpretabilità
        └── maggiore lavoro

embedding
        │
        ├── rappresentazione ricca
        ├── maggiore riusabilità
        └── minore interpretabilità diretta

26. Image embeddings e Earth Observation

Il concetto diventa ancora più potente nel remote sensing.

Invece di classificare immediatamente un'immagine:

Satellite image
      │
      ▼
Classifier
      │
      ▼
urban / forest / water / ...

possiamo produrre prima una rappresentazione generale:

Satellite image
      │
      ▼
Foundation model
      │
      ▼
Embedding
      │
      ├── similarity search
      ├── clustering
      ├── anomaly detection
      ├── classification
      ├── segmentation
      └── downstream fine tuning

Questo è uno dei motivi per cui i geospatial foundation model sono così interessanti.

La rappresentazione può essere riutilizzata in task differenti senza ricominciare ogni volta dal dato grezzo.

27. Location embeddings con ArcGIS API for Python

L'ArcGIS API for Python espone anche una classe Embeddings nel modulo arcgis.learn.

Fra i tipi supportati troviamo:

image
text
location

Concettualmente:

from arcgis.learn import Embeddings

model = Embeddings(
    dataset_type="location"
)

result = model.get(
    input_path,
    return_embeddings=True
)

Per i location embedding la documentazione ArcGIS API for Python indica come backbone predefinito una variante di SatCLIP addestrata su Sentinel-2.

Qui il concetto è differente dal geodemographic embedding.

Non stiamo comprimendo migliaia di variabili Census, ma stiamo costruendo una rappresentazione geografica utilizzando un modello addestrato a catturare struttura e contesto spaziale.

28. "Embedding GIS" non identifica quindi una sola tecnologia

È importante evitare di utilizzare il termine embedding come se identificasse un'unica rappresentazione universale.

Possiamo avere:

Text embedding
Image embedding
Location embedding
Geodemographic embedding
POI embedding
Network embedding
Trajectory embedding
Graph embedding
Multimodal embedding

Due vettori della stessa dimensione prodotti da modelli differenti non appartengono necessariamente allo stesso spazio semantico e non sono automaticamente confrontabili.

Se:

E₁(x) ∈ R²⁵⁶
E₂(x) ∈ R²⁵⁶

non significa:

cos(E₁(x), E₂(y))

abbia un significato valido.

La compatibilità dipende dallo spazio latente costruito durante il training.

29. Model versioning diventa data governance

Da sviluppatore questo porta immediatamente a un problema architetturale.

Se memorizziamo embedding persistentemente, dobbiamo sapere quale modello li ha generati.

Un dataset production-ready dovrebbe quindi conservare informazioni come:

Embedding
EmbeddingModel
EmbeddingModelVersion
EmbeddingDimension
EmbeddingGeneratedAt
EmbeddingSourceVersion

Perché:

model v1 embedding
        ≠
model v2 embedding

anche quando la dimensione è identica.

Aggiornare un modello può richiedere il ricalcolo dell'intero indice vettoriale.

30. Un esempio C#

La cosine similarity non richiede necessariamente Python.

Una semplice implementazione C# potrebbe essere:

static float CosineSimilarity(
    ReadOnlySpan<float> a,
    ReadOnlySpan<float> b)
{
    if (a.Length != b.Length)
        throw new ArgumentException(
            "Vectors must have the same dimension.");

    double dot = 0;
    double normA = 0;
    double normB = 0;

    for (int i = 0; i < a.Length; i++)
    {
        dot += a[i] * b[i];
        normA += a[i] * a[i];
        normB += b[i] * b[i];
    }

    if (normA == 0 || normB == 0)
        return 0;

    return (float)(
        dot /
        (Math.Sqrt(normA) * Math.Sqrt(normB))
    );
}

Un'applicazione .NET potrebbe quindi leggere gli embedding provenienti da ArcGIS, da un database vettoriale o da un modello AI ed effettuare direttamente ranking e filtering.

31. Decodificare il formato Float32 ArcGIS in C#

Dal momento che il BLOB ArcGIS contiene float32 little-endian contigui, il concetto lato .NET è:

static float[] DecodeEmbedding(
    byte[] bytes,
    int expectedDimension)
{
    if (bytes.Length != expectedDimension * sizeof(float))
        throw new InvalidOperationException(
            "Unexpected embedding payload size.");

    var result = new float[expectedDimension];

    for (int i = 0; i < expectedDimension; i++)
    {
        result[i] = BitConverter.ToSingle(
            bytes,
            i * sizeof(float)
        );
    }

    return result;
}

Su una piattaforma little-endian come l'architettura Windows/x64 normalmente utilizzata da ArcGIS Pro, il mapping è diretto; in codice interoperabile è comunque opportuno trattare esplicitamente l'endianness prevista dal formato.

32. Vector database e GIS

Un database vettoriale memorizza oggetti del tipo:

ID
metadata
embedding

Un database GIS tradizionale memorizza:

ID
geometry
attributes

L'evoluzione naturale è:

ID
geometry
attributes
embedding

con:

spatial index
+
attribute indexes
+
vector index

Questo modello rende possibili query ibride estremamente potenti.

33. Hybrid Spatial-Vector Search

Consideriamo una richiesta:

Trova entro 30 km da questa posizione aree che assomigliano a questo distretto commerciale.

La pipeline potrebbe essere:

                         Query
                           │
             ┌─────────────┴─────────────┐
             │                           │
             ▼                           ▼
       Geographic filter           Query embedding
             │                           │
             ▼                           ▼
       Spatial Index               Vector Index
             │                           │
             └─────────────┬─────────────┘
                           ▼
                    Candidate set
                           │
                           ▼
                    similarity rank
                           │
                           ▼
                        Results

Questo tipo di ricerca combina contemporaneamente:

  • geografia;
  • semantica;
  • attributi;
  • AI.

34. GeoRAG: Retrieval Augmented Generation geografico

Il passaggio successivo è collegare questo sistema a un LLM.

In un normale RAG:

User question
     │
     ▼
Text embedding
     │
     ▼
Vector search
     │
     ▼
Documents
     │
     ▼
LLM

In un possibile GeoRAG:

User
 │
 │ "Trova aree industriali simili a questa
 │  entro 50 km e spiegami le differenze"
 │
 ▼
LLM / Agent
 │
 ├────────► intent extraction
 │
 ├────────► spatial query
 │
 ├────────► vector similarity
 │
 ├────────► feature attributes
 │
 ├────────► imagery embeddings
 │
 └────────► external/context data
                │
                ▼
          ArcGIS / Spatial DB
                │
                ▼
           Feature collection
                │
                ▼
               LLM
                │
                ▼
      explanation + map results

L'LLM non deve inventare il risultato geografico.

Il GIS rimane il motore deterministico per geometria, coordinate, overlay, network analysis e spatial constraints.

Il motore vettoriale aggiunge invece il retrieval semantico.

L'LLM orchestra e interpreta i risultati.

35. Geometry, semantics e language reasoning

Possiamo vedere l'architettura come tre livelli.

┌────────────────────────────────────┐
│        LANGUAGE / REASONING        │
│              LLM                   │
├────────────────────────────────────┤
│        SEMANTIC RETRIEVAL          │
│ Embeddings / Vector Search / ANN   │
├────────────────────────────────────┤
│         SPATIAL COMPUTATION        │
│ Geometry / Topology / CRS / GIS    │
└────────────────────────────────────┘

Ognuno risolve un problema differente.

Il GIS calcola.

Gli embedding rappresentano e recuperano similarità.

L'LLM ragiona sull'intento e costruisce una risposta comprensibile.

36. Embedding e Tobler's First Law

Nel GIS è quasi inevitabile collegare questo argomento alla nota prima legge della geografia di Waldo Tobler:

Things that are near tend to be more related than things that are far apart.

Gli embedding introducono però una nuova dimensione.

Due fenomeni possono essere:

far in geographic space
but
near in embedding space

La prossimità geografica rimane fondamentale, ma non è più l'unico concetto di vicinanza disponibile.

Possiamo parlare di:

  • prossimità geografica;
  • prossimità topologica;
  • prossimità temporale;
  • prossimità semantica.

37. Attenzione alla spatial autocorrelation

Gli embedding geografici introducono anche problemi statistici specifici.

Se il training set viene suddiviso casualmente:

80% train
20% test

feature geograficamente vicine possono finire nei due insiemi.

A causa della spatial autocorrelation, questo può produrre valutazioni eccessivamente ottimistiche.

In molti problemi GeoAI è preferibile valutare anche strategie come:

  • spatial block cross-validation;
  • geographic holdout;
  • leave-one-region-out;
  • temporal-spatial split.

Un embedding sofisticato non elimina le regole fondamentali della statistica spaziale.

38. Similarità non significa causalità

Un altro punto essenziale:

embedding similarity
        ≠
causal relationship

Due territori possono avere embedding simili perché condividono numerosi pattern statistici senza che esista alcuna relazione causale diretta.

Gli embedding sono eccellenti strumenti per:

  • retrieval;
  • clustering;
  • feature enrichment;
  • anomaly detection;
  • candidate generation;
  • prediction.

Non costituiscono automaticamente una spiegazione causale.

39. Distribution shift

Un modello di embedding apprende dalla distribuzione osservata durante il training.

Se viene applicato a:

  • un'altra nazione;
  • un altro periodo storico;
  • sensori differenti;
  • urbanizzazioni radicalmente differenti;
  • dati con diversa qualità;

potrebbe verificarsi distribution shift.

Questo è particolarmente importante in ambito geospaziale, dove le distribuzioni cambiano nello spazio e nel tempo.

40. Un embedding USA non è automaticamente un embedding europeo

Gli USA Geodemographic Embeddings sono stati progettati utilizzando dataset e geografie statunitensi.

Il principio è generale, ma il modello non deve essere interpretato come rappresentazione universale di qualsiasi territorio.

Per costruire un equivalente europeo o italiano sarebbe necessario definire un insieme coerente di sorgenti, ad esempio:

ISTAT
Copernicus
Sentinel
OpenStreetMap
land cover
meteorological data
mobility
POI
cadastral/urban information
socioeconomic indicators
...

e addestrare una rappresentazione coerente con il dominio geografico di interesse.

41. Un possibile "Italian Place Embedding"

Immaginiamo, puramente a livello architetturale:

ISTAT ──────────────────────┐
                            │
Sentinel / Copernicus ──────┤
                            │
OpenStreetMap ───────────────┤
                            ├──► Multi-view encoder
POI ────────────────────────┤
                            │
Mobility ───────────────────┤
                            │
Climate / Environment ──────┘
                                   │
                                   ▼
                             PLACE VECTOR
                                 R^d

Ogni cella territoriale italiana avrebbe una rappresentazione numerica general-purpose.

A quel punto potremmo eseguire query come:

Quali aree italiane presentano un profilo urbano, infrastrutturale e socioeconomico simile a questo quartiere?

senza costruire manualmente decine di filtri.

42. Verso il "place foundation model"

Il passo successivo rispetto al semplice embedding è un modello capace di comprendere in maniera multimodale il concetto di luogo.

                 PLACE FOUNDATION MODEL

       ┌──────────────┬──────────────┬──────────────┐
       │              │              │              │
       ▼              ▼              ▼              ▼
    Imagery        Geometry       Network         Text
       │              │              │              │
       └──────────────┼──────────────┼──────────────┘
                      │
                      ▼
              Shared latent space
                      │
       ┌──────────────┼──────────────┐
       ▼              ▼              ▼
   Retrieval      Prediction      Reasoning

In prospettiva potremmo non avere soltanto:

text → vector

ma:

place → vector

e magari:

text ↔ place ↔ image

all'interno di uno spazio multimodale condiviso.

43. Dal GIS basato sugli attributi al GIS basato sulle rappresentazioni

Per decenni una feature GIS è stata concettualmente:

Feature =
Geometry
+
Attributes

Con il GeoAI possiamo iniziare a pensare:

Feature =
Geometry
+
Attributes
+
Learned Representation

Il cambiamento può sembrare piccolo, ma è architetturalmente profondo.

La geometria rappresenta dove.

Gli attributi rappresentano ciò che sappiamo esplicitamente.

L'embedding rappresenta una sintesi latente di ciò che il modello ha appreso.

44. Gli embedding non sostituiranno il GIS classico

Gli embedding non eliminano:

  • buffer;
  • overlay;
  • spatial join;
  • network analysis;
  • coordinate systems;
  • geocoding;
  • topologia;
  • spatial statistics.

Se devo sapere se due poligoni si intersecano:

ST_Intersects(A, B)

rimane la soluzione corretta.

Non avrebbe senso chiedere a un embedding di approssimare un predicato geometrico deterministico.

Ma se la domanda è:

quali territori presentano un contesto simile a questo?

allora entriamo esattamente nel dominio degli embedding.

45. La vera evoluzione è l'integrazione

Il GIS futuro probabilmente non sarà:

GIS
oppure
AI

ma:

             GIS PLATFORM

Geometry ─────── Spatial Engine
                     │
Attributes ───── Data Engine
                     │
Embeddings ───── Vector Engine
                     │
Models ───────── GeoAI Engine
                     │
LLM ──────────── Agent / Reasoning
                     │
                     ▼
              Geographic Intelligence

Ed è probabilmente qui che il concetto di GeoAI diventa realmente interessante per chi sviluppa sistemi GIS.

Conclusioni

Gli embedding stanno introducendo nel GIS un nuovo modo di rappresentare l'informazione geografica.

Non descrivono semplicemente dove si trova un oggetto e non sostituiscono gli attributi tradizionali.

Costruiscono invece uno spazio latente nel quale luoghi, immagini e feature possono essere confrontati in funzione delle caratteristiche apprese da un modello.

La distinzione fondamentale è:

Geographic distance
        ≠
Semantic distance

e le due possono essere utilizzate contemporaneamente.

Spatial Index
     +
Vector Index
     +
GIS Attributes
     +
Foundation Models
     +
LLM / Agents

aprono la strada a sistemi capaci non soltanto di rispondere:

Dove si trova?

ma anche:

A quali luoghi assomiglia?

e, in prospettiva:

Quali caratteristiche rendono questo luogo simile ad altri, quali differenze sono geograficamente rilevanti e come posso utilizzarle per prendere una decisione?

Per chi lavora nel GIS questo è probabilmente uno dei passaggi più interessanti dell'attuale evoluzione GeoAI: la feature geografica non è più soltanto una geometria con attributi. Può diventare una rappresentazione appresa.


Riferimenti tecnici

  • Esri — Concepts of USA Geodemographic Embeddings
  • Esri — Use the USA Geodemographic Embeddings
  • ArcGIS Pro — Embeddings Based Analysis toolset
  • ArcGIS Pro — Find Similar Features Using Embeddings
  • ArcGIS Pro — How Find Similar Features Using Embeddings works
  • ArcGIS Pro — Merge Embeddings
  • ArcGIS Pro — Embeddings in BLOB fields
  • ArcGIS API for Python — arcgis.learn.Embeddings

Nota: gli USA Geodemographic Embeddings 2026 citati nell'articolo sono un modello/dataset specifico dell'ecosistema ArcGIS e, al momento della stesura, Esri li indica come Beta. Gli esempi architetturali relativi a place embeddings, GeoRAG e sistemi multimodali descrivono invece pattern generali e possibili evoluzioni tecnologiche, non uno specifico prodotto ArcGIS.