NicoGIS Tech Weekly · GIS Systems Engineering · 3 novembre 2026
ArcGIS Velocity Deep Dive
Engineering Real-Time Geospatial Systems: IoT Ingestion, Stream Processing, Geofencing, Spatiotemporal Analytics, ArcGIS Enterprise 12.1 e integrazione Azure/.NET.
Un sistema GIS real-time non è semplicemente una mappa che aggiorna dei marker. È una pipeline distribuita che deve acquisire eventi, attribuire loro significato spaziale e temporale, mantenere stato dove necessario, applicare regole e produrre risultati osservabili. La sfida non è visualizzare una posizione: è decidere cosa significa quella posizione, quando è valida e quale azione deve provocare.
1. Che cos'è ArcGIS Velocity e perché il 2026 cambia lo scenario
ArcGIS Velocity è la piattaforma Esri per integrare dati osservazionali, elaborare flussi geospaziali e pubblicare risultati in mappe, layer, dashboard e sistemi esterni. Nata come capacità SaaS di ArcGIS Online, da ArcGIS Enterprise 12.1 è disponibile anche come componente self-hosted su Windows e Linux. Questa distinzione è fondamentale: le due modalità hanno ambiti funzionali e operativi differenti.
| Dimensione | Velocity per ArcGIS Online | Velocity per ArcGIS Enterprise 12.1 |
|---|---|---|
| Gestione | SaaS gestito da Esri | Installazione e operatività nell'infrastruttura del cliente |
| Real-time feeds / analytics | Sì | Sì |
| Big Data Analytics | Sì | No nella prima release Enterprise 12.1 |
| Integrazione organizzativa | ArcGIS Online | Federazione con Portal for ArcGIS e hosting server |
| Topologia di distribuzione iniziale | Gestita dal servizio | Velocity installato su una singola macchina Windows o Linux |
| Responsabilità aggiornamenti | Esri | Organizzazione che gestisce l'installazione |
La disponibilità Enterprise non significa che Velocity sia un ruolo di licenza di ArcGIS Server. È un componente server distinto, con licenza dedicata, federato al portale. Esri lo propone anche come percorso evolutivo per gli utenti di GeoEvent Server; la release finale di GeoEvent Server è attualmente pianificata per ArcGIS Enterprise 12.3. Questo non implica una migrazione automatica dei workflow esistenti.
2. Modello architetturale: dal sensore all'azione
Un feed è la connessione a una sorgente osservazionale. Un real-time analytic è un grafo di elaborazione che applica trasformazioni e analisi mentre arrivano i record. Gli output distribuiscono risultati a layer GIS, archivi, broker o sistemi di notifica. In ArcGIS Online esistono anche i big data analytics per elaborazioni su insiemi di dati, non soltanto sul flusso in ingresso.
Non bisogna confondere il feed con un archivio affidabile degli eventi. La durabilità, il replay, la retention e le garanzie di consegna dipendono dal connettore e dall'infrastruttura sorgente. Se è necessario poter rielaborare un incidente dopo settimane, occorre prevedere un sistema di conservazione indipendente dalla sola visualizzazione live.
3. Feed: polling, streaming e contratti di integrazione
Velocity dispone di connettori per ArcGIS Stream Layer e Feature Layer, Azure Event Hubs, Azure Service Bus, Kafka, MQTT, RabbitMQ, WebSocket, HTTP Receiver, HTTP Poller, gRPC e diversi provider telematici. L'elenco effettivo va sempre verificato per il deployment e la release installata.
| Pattern | Comportamento | Trade-off |
|---|---|---|
| HTTP Poller | Interroga una API a intervalli configurati | Semplice, ma latenza e deduplicazione dipendono dal contratto API |
| HTTP Receiver | Riceve richieste HTTP POST su endpoint creato dal feed | Adatto a producer custom; gestione retry e protezione dell'endpoint necessarie |
| MQTT | Sottoscrizione a messaggi pubblicati dal broker | Adatto a telemetria IoT; semantica QoS da verificare end-to-end |
| Kafka / Event Hubs | Consumo di eventi da piattaforme di messaging | Disaccoppiamento e buffering; occorre definire partizionamento e replay |
| ArcGIS Feature Layer | Acquisizione di osservazioni da un layer | Utile per integrazione GIS; non sostituisce sempre uno stream a bassa latenza |
La documentazione Esri distingue feed polling e streaming. Per i polling, le ricorrenze sono allineate a intervalli di orologio e non necessariamente calcolate a partire dall'istante di avvio del feed. Questo dettaglio incide sui test di latenza. Modificare un feed attivo ne comporta il riavvio; quando è fermo non acquisisce dati.
3.1 Contratto dell'evento
Un evento GPS dovrebbe includere almeno un identificatore univoco, un identificatore stabile del dispositivo, l'istante della misura, coordinate e metadati sulla qualità. Un esempio illustrativo:
{
"eventId": "b4bbac84-6e13-4c51-918a-0b44b70c9919",
"deviceId": "TRUCK-017",
"observedAt": "2026-11-03T10:15:42.170Z",
"longitude": 9.1952,
"latitude": 45.4642,
"speedKmh": 37.4,
"headingDegrees": 118,
"accuracyMeters": 8.2,
"sequence": 5814
}eventId permette di deduplicare, observedAt definisce il tempo di osservazione, sequence aiuta a individuare inversioni nell'ordine degli eventi. Le coordinate sono espresse qui in longitudine/latitudine WGS84, ma la configurazione del feed deve identificare esplicitamente i campi spaziali e il sistema di riferimento.
4. Event time, processing time e dati fuori ordine
La distinzione più importante nell'elaborazione di stream è fra event time, quando il fenomeno è stato osservato, e processing time, quando la pipeline ha elaborato il messaggio. Un dispositivo offline può trasmettere alle 11:00 una misura registrata alle 10:40: il messaggio è nuovo per il broker, non per la realtà rappresentata.
ObservedAt = 10:40:00
ReceivedAt = 11:00:00
Processing delay = 20 minutesLa presenza di strumenti temporali non autorizza a presumere che ogni pipeline Velocity offra automaticamente le stesse semantiche di watermark, late arrival e exactly-once di un motore stream processing generico. Tali proprietà devono essere verificate per tool, connettore e versione. Per applicazioni critiche, il progetto deve esplicitare una politica: accettare eventi tardivi, scartarli, ricalcolare lo stato o inviarli a una pipeline di riconciliazione.
È utile definire metriche distinte: ingestLag = receivedAt - observedAt, processingLag = emittedAt - receivedAt ed endToEndLag = emittedAt - observedAt. Una dashboard può apparire aggiornata mentre sta mostrando eventi molto vecchi: senza queste metriche, la latenza percepita è fuorviante.
5. Geofencing: geometria, stato e transizioni
Un geofence è una geometria che delimita un'area di interesse. Il caso banale consiste nel verificare se un punto ricade nel poligono; quello operativo consiste nel riconoscere una transizione fra stati.
Un motore di incident detection deve rispondere a domande che un semplice spatial join non risolve: che cosa accade quando il dispositivo smette di inviare dati? Una nuova misura sostituisce una precedente più recente? L'attraversamento del bordo in presenza di errore GPS deve generare più allarmi? L'incidente si chiude dopo un timeout o soltanto dopo il prossimo evento?
Un pattern di progettazione robusto prevede un identificatore dispositivo, uno stato corrente, l'istante dell'ultima osservazione valida, una soglia di accuratezza e un meccanismo anti-flapping. Ad esempio si può richiedere una permanenza minima prima di confermare un ingresso; è una regola applicativa, non una garanzia implicita di Velocity.
La patch Velocity Enterprise 12.1 Patch 1 del 16 ottobre 2026 corregge un difetto di Detect Incidents nel quale un incidente non veniva chiuso allo scadere della finestra temporale, ma soltanto all'arrivo di una nuova feature. È un esempio concreto del motivo per cui i test devono includere anche l'assenza di eventi.
6. Stateful processing, replay e idempotenza
Un'analisi stateless valuta ciascun evento in modo indipendente. Una stateful conserva informazioni fra eventi: ultima posizione, stato dell'incidente, contatori, aggregazioni, finestre temporali. Lo stato introduce complessità: recovery, versionamento, ordinamento e riconciliazione.
Per le azioni esterne, il pattern raccomandato è utilizzare un identificatore idempotente derivato dall'evento e dal tipo di azione, ad esempio SHA256(deviceId | eventId | ruleId). Se il sistema esterno riceve due volte lo stesso comando, dovrebbe poter riconoscere che si tratta della stessa operazione logica. Questa è una raccomandazione architetturale, non una caratteristica automaticamente garantita da tutti gli output Velocity.
7. Output: stream layer, feature layer e sistemi esterni
La visualizzazione live e la persistenza storica sono due esigenze distinte. Uno stream layer serve a disseminare aggiornamenti in tempo reale; un feature layer può supportare interrogazioni e analisi su osservazioni persistite. Velocity può anche scrivere su Kafka, RabbitMQ, storage cloud e altri endpoint, in base ai connettori disponibili.
Su ArcGIS Enterprise è particolarmente importante scegliere correttamente lo storage. Esri raccomanda il relational data store per volumi relativamente bassi e lo spatiotemporal big data store per volumi elevati. Nella documentazione, il primo è descritto come adatto a poche decine di record al secondo o poche centinaia ogni alcuni minuti; per centinaia o migliaia di record ogni pochi secondi viene raccomandato il secondo. Sono indicazioni qualitative, non SLA universali.
Scrivere continuamente nel relational data store può aumentare IOPS, incidere sulle query di altre applicazioni Enterprise e provocare perdita di record in scenari di elevata velocità. La decisione deve quindi considerare tasso di ingestione, numero di campi, retention, query concorrenti e comportamento in caso di picchi.
8. Deployment Enterprise 12.1: topologia e dipendenze
Velocity deve essere federato con un portale Enterprise che abbia un hosting server. Per scenari di alta velocità, Esri suggerisce uno spatiotemporal big data store su macchine separate e, per le distribuzioni produttive ad alto volume, più nodi per sfruttare le caratteristiche di resilienza dello storage.
È importante distinguere scalabilità dello storage e scalabilità del server Velocity: la prima release Enterprise 12.1 è presentata da Esri come distribuzione Velocity su singola macchina. La presenza di più nodi spatiotemporal non deve essere interpretata come supporto implicito a un cluster multi-nodo Velocity.
8.1 Operatività e aggiornamenti
La patch Enterprise 12.1 Patch 1 include correzioni per licensing, WebSocket, RabbitMQ, HTTP Poller OAuth, gestione di risorse del broker e sicurezza. Esri raccomanda un backup della configurazione degli item prima dell'installazione e la pulizia della cache del browser dopo l'aggiornamento. La patch non è disinstallabile: un rollback richiede un piano di reinstallazione/ripristino. Le patch e le versioni devono essere validate nell'ambiente effettivo.
9. Integrazione con Azure: tre architetture possibili
Pattern A — HTTP Receiver diretto
È il percorso più semplice per prototipi o carichi moderati. Il producer deve implementare retry controllati, timeout, identificatori evento e telemetria. L'endpoint HTTP Receiver è generato da Velocity; le richieste vanno inviate secondo il formato e la configurazione del feed. La documentazione Esri specifica richieste POST con payload testuale: non bisogna assumere che qualunque endpoint accetti automaticamente application/json o un array JSON senza averne configurato il parsing.
Pattern B — Azure Event Hubs come buffer di ingestione
Event Hubs separa producer e consumer, assorbe picchi e offre una finestra di retention configurabile. Il partizionamento per deviceId può aiutare a preservare l'ordine relativo agli eventi dello stesso dispositivo all'interno della partizione, ma non fornisce ordinamento globale fra dispositivi. Bisogna progettare consumer group, checkpoint, access control, rete e costi; la configurazione supportata dal feed Velocity va verificata sulla versione installata.
Pattern C — Kafka / stream engine specializzato + Velocity
Questo pattern è sensato quando sono necessarie elaborazioni complesse, politiche esplicite per eventi tardivi, replay storico, logiche di correlazione cross-stream o contratti di elaborazione che vanno oltre quelli documentati per Velocity. Non significa che Velocity debba essere sostituito: può rimanere il livello geospaziale e di disseminazione.
10. Laboratorio C#/.NET 10 — Simulatore GPS e producer HTTP
Il laboratorio genera osservazioni GPS sintetiche e le invia a un endpoint HTTP Receiver configurato in Velocity. È un esempio didattico: la URL deve essere quella effettivamente generata dal feed e l'autenticazione deve seguire la configurazione del deployment. Non contiene credenziali reali.
10.1 Creazione progetto
dotnet new console -n VelocityGpsProducer -f net10.0
cd VelocityGpsProducer10.2 Program.cs
using System.Globalization;
using System.Net;
using System.Net.Http.Headers;
using System.Text;
using System.Text.Json;
var endpoint = Environment.GetEnvironmentVariable("VELOCITY_HTTP_ENDPOINT")
?? throw new InvalidOperationException("Set VELOCITY_HTTP_ENDPOINT");
using var client = new HttpClient { Timeout = TimeSpan.FromSeconds(15) };
client.DefaultRequestHeaders.Accept.Add(
new MediaTypeWithQualityHeaderValue("text/plain"));
var random = new Random(42);
var latitude = 45.4642;
var longitude = 9.1900;
for (var sequence = 1; sequence <= 120; sequence++)
{
longitude += 0.00010 + random.NextDouble() * 0.00003;
latitude += (random.NextDouble() - 0.5) * 0.00005;
var observation = new
{
eventId = Guid.NewGuid().ToString("D"),
deviceId = "SIM-001",
observedAt = DateTimeOffset.UtcNow.ToString("O"),
longitude,
latitude,
speedKmh = 25 + random.NextDouble() * 15,
sequence
};
var json = JsonSerializer.Serialize(observation);
using var request = new HttpRequestMessage(HttpMethod.Post, endpoint)
{
// Velocity HTTP Receiver expects a text payload.
Content = new StringContent(json, Encoding.UTF8, "text/plain")
};
using var response = await client.SendAsync(request);
if (!response.IsSuccessStatusCode)
{
Console.Error.WriteLine($"Event {sequence}: HTTP {(int)response.StatusCode}");
// In production, use bounded retry with jitter and durable buffering.
continue;
}
Console.WriteLine($"{sequence}: {json}");
await Task.Delay(TimeSpan.FromSeconds(1));
}Prima di eseguire, creare il feed HTTP Receiver in Velocity, configurare il parsing JSON, riconoscere longitude e latitude come coordinate, assegnare observedAt come timestamp dell'evento e verificare l'autenticazione richiesta. La documentazione Esri consente di recuperare l'endpoint dalla pagina di dettaglio del feed. In ambiente Enterprise non esporre il receiver su Internet senza una revisione del modello di sicurezza.
10.3 Configurazione e avvio
# PowerShell
$env:VELOCITY_HTTP_ENDPOINT = "https://<endpoint-fornito-da-velocity>"
dotnet runQuesto producer è volutamente semplice: non implementa token OAuth, retry durevoli o batching. Tali capacità dipendono dalla destinazione, dai requisiti e dai limiti del feed. Per un'applicazione produttiva è preferibile separare il producer dal trasporto tramite una coda persistente.
11. Laboratorio di analisi: geofence e incidente
Nel model builder creare un real-time analytic che legga il feed GPS, filtri gli eventi validi, applichi un filtro spaziale rispetto a un poligono di interesse e produca un output di visualizzazione. Per la gestione degli incidenti, utilizzare lo strumento dedicato dopo aver definito condizioni di apertura e chiusura coerenti con il processo operativo.
Test minimo riproducibile: inviare una traiettoria esterna al poligono, attraversarne il confine, rimanere all'interno, uscire e infine interrompere l'invio. Verificare separatamente: numero di eventi elaborati, transizioni generate, eventuali incidenti aperti, chiusura temporale e stato finale del layer. Ripetere con eventi duplicati, in ritardo e fuori ordine.
12. Osservabilità: metriche che contano davvero
| Metrica | Perché serve |
|---|---|
| Input events/s | Quantifica il carico in ingresso |
| Output events/s per destinazione | Individua colli di bottiglia e fan-out incompleti |
| End-to-end latency P50/P95/P99 | Misura la tempestività reale, non solo la media |
| Late/out-of-order ratio | Valuta la qualità temporale del flusso |
| Duplicate ratio | Rileva retry e riconsegne |
| Open incident age | Individua incidenti rimasti aperti impropriamente |
| Broker backlog / partition usage | Segnala saturazione delle risorse a monte o interne |
| Feature layer write failures | Individua perdita o mancata persistenza degli output |
Non bisogna considerare una metrica isolata come prova di correttezza. La patch Enterprise 12.1 Patch 1 corregge un caso in cui gli output RabbitMQ pubblicavano messaggi mentre le metriche segnalavano zero feature al secondo. Per flussi critici è opportuno confrontare telemetria del producer, del broker, di Velocity e del sistema di destinazione.
13. Performance engineering e capacity planning
Il throughput nominale in eventi/s non basta. Un evento che contiene due campi e un semplice filtro è diverso da uno che richiede spatial join, calcoli, stato per dispositivo e scrittura verso più destinazioni. La capacità dipende anche dalla cardinalità dei dispositivi, complessità delle geometrie, distribuzione spaziale, dimensione dei payload e velocità dello storage.
Una metodologia sensata comprende quattro prove: baseline a carico costante; ramp-up progressivo; burst temporanei; soak test di durata sufficiente a evidenziare perdite di risorse. Ogni prova deve misurare eventi prodotti, accettati, elaborati, persistiti e visualizzati. Definire un SLO, ad esempio P95 inferiore a 5 secondi, è una scelta progettuale da validare: non un valore promesso da Esri.
Per dimensionare lo storage storico, una stima grezza è eventi/s × byte/evento × secondi di retention, da correggere per indicizzazione, repliche, compressione, metadati e overhead del sistema. Esempio: 1.000 eventi/s da 500 byte per 30 giorni generano circa 1,30 TB di payload grezzo prima degli overhead. Questo calcolo non è una previsione diretta della dimensione del data store ArcGIS.
14. Sicurezza: identità, segmentazione e data governance
Le sorgenti di telemetria non sono necessariamente attendibili. Un evento può contenere coordinate false, timestamp manipolati, identificatori contraffatti o campi testuali malevoli. I controlli dovrebbero comprendere autenticazione del producer, autorizzazione per sorgente, validazione di schema, rate limiting a monte, TLS, separazione fra rete di ingestione e rete amministrativa, e audit delle modifiche ai workflow.
La posizione di persone o mezzi può diventare dato personale quando consente di identificare un individuo. Occorre quindi minimizzare i campi, definire retention, separare identificativi operativi da dati personali e limitare accesso e diffusione delle tracce. Per i flussi che attivano operazioni esterne, la validazione della regola spaziale non sostituisce l'autorizzazione all'azione.
15. Velocity vs GeoEvent Server vs Azure Stream Analytics vs Flink
| Tecnologia | Punto di forza | Attenzione |
|---|---|---|
| ArcGIS Velocity | Integrazione geospaziale e analytics configurabili con output ArcGIS | Distinguere SaaS ed Enterprise; verificare limiti per connettore e tool |
| ArcGIS GeoEvent Server | Workflow real-time Esri esistenti e integrazioni legacy | Deprecazione annunciata; pianificare inventario e migrazione |
| Azure Stream Analytics | Query streaming SQL-like e integrazione con servizi Azure | Funzionalità spaziali e semantiche diverse da Velocity |
| Apache Flink | Stateful stream processing avanzato e controllo esplicito di molte semantiche temporali | Maggiore complessità operativa e necessità di integrazione GIS |
Non esiste un vincitore assoluto. Se l'obiettivo è trasformare dati IoT in mappe e avvisi geospaziali all'interno dell'ecosistema Esri, Velocity offre un'integrazione naturale. Se sono richiesti calcoli distribuiti molto personalizzati, controlli dettagliati su watermark e replay o un motore di elaborazione generalista, un'architettura ibrida può essere più appropriata.
16. Checklist di progettazione e migrazione
- Definire sorgenti, frequenze, dimensioni dei messaggi e picchi.
- Specificare schema, SRID, timestamp di osservazione, ID evento e ID dispositivo.
- Verificare disponibilità dei connettori sulla versione Velocity e sul deployment scelto.
- Separare visualizzazione live, persistenza storica e sistemi di audit.
- Definire politiche per eventi duplicati, tardivi, fuori ordine e mancanti.
- Misurare end-to-end latency e correttezza degli output, non solo throughput.
- Dimensionare ArcGIS Data Store sulla base dei carichi di scrittura e lettura.
- Verificare patch, procedure di backup, ripristino e licenze.
- Per GeoEvent, inventariare ogni input, processor, output, trasformazione e dipendenza prima della migrazione.
- Validare autenticazione, autorizzazioni, segregazione di rete e governance delle posizioni.
17. Conclusioni
ArcGIS Velocity rappresenta un'evoluzione significativa del real-time GIS: porta i flussi osservazionali direttamente nel ciclo di analisi spaziale e disseminazione delle informazioni. L'arrivo della versione self-hosted con ArcGIS Enterprise 12.1 amplia le possibilità di adozione, ma introduce nuove responsabilità operative e non replica tutte le capacità del servizio SaaS.
La progettazione corretta parte dalla semantica degli eventi, non dalla mappa. Occorre sapere quando un dato è stato osservato, come è stato consegnato, quale stato ha modificato, quali azioni ha attivato e come verificarne l'esito. Solo a queste condizioni il GIS real-time diventa un sistema operativo affidabile, anziché una visualizzazione suggestiva.
Fonti ufficiali e documentazione tecnica
- Esri — Introducing ArcGIS Velocity for ArcGIS Enterprise (May 2026)
- Esri — What's New in ArcGIS Velocity
- Esri — Work with Feeds
- Esri — ArcGIS Velocity in ArcGIS Enterprise
- Esri — HTTP Receiver
- Esri — Velocity Enterprise 12.1 Patch 1 (16 October 2026)
- ArcGIS Architecture Center — Real-time data streaming and analytics
- ArcGIS Architecture Center — Real-time integration patterns
Nota editoriale: le architetture proposte, gli SLO esemplificativi, il simulatore C# e i pattern di idempotenza sono raccomandazioni ingegneristiche e non funzionalità automaticamente garantite dal prodotto. Le caratteristiche di Velocity sono riferite alla documentazione disponibile al 3 novembre 2026.
