Geospatial ETL: Why 80% of GIS Work
Is Data PreparationETL geospaziale: perché l'80% del lavoro GIS
è preparazione dei dati
Ask any GIS professional where their week went and the answer is rarely “analysis”. It went into converting formats, fixing projections, repairing geometries and reconciling vocabularies — the extract-transform-load work that nobody budgets for and everybody pays. Understanding geospatial ETL is understanding why some organisations ship maps in hours while others take weeks.
Chiedi a un professionista GIS dove sia finita la sua settimana e la risposta raramente è «analisi». È finita nel convertire formati, sistemare proiezioni, riparare geometrie e riconciliare vocabolari — il lavoro di extract-transform-load che nessuno mette a budget e tutti pagano. Capire l'ETL geospaziale è capire perché alcune organizzazioni pubblicano mappe in ore e altre in settimane.
The Invisible 80%L'80% invisibile
Geospatial data has every problem ordinary data has — missing values, inconsistent encodings, duplicates — plus a layer of its own: coordinates that mean nothing without their reference system, geometries that can be individually invalid (self-intersecting polygons, unclosed rings), topologies that must hold across features, and a dozen container formats with different limits and dialects. The industry folklore says preparation is 80% of the work. The folklore is optimistic on bad days. The point of an ETL pipeline is to pay that cost once, encode it as a repeatable process, and never pay it again for the same source.
Il dato geospaziale ha tutti i problemi del dato ordinario — valori mancanti, encoding incoerenti, duplicati — più uno strato tutto suo: coordinate che non significano nulla senza il loro sistema di riferimento, geometrie che possono essere singolarmente invalide (poligoni auto-intersecanti, anelli non chiusi), topologie che devono reggere fra feature, e una dozzina di formati contenitore con limiti e dialetti diversi. Il folklore del settore dice che la preparazione è l'80% del lavoro. Nei giorni storti il folklore è ottimista. Il senso di una pipeline ETL è pagare quel costo una volta, codificarlo come processo ripetibile, e non pagarlo mai più per la stessa sorgente.
Extract: the Format JungleExtract: la giungla dei formati
Data arrives as Shapefile (a 1990s format with 10-character column names and no single-file integrity), GeoPackage, GeoJSON, KML/KMZ, CSV with coordinates hidden in text columns, CAD exports, raster GeoTIFFs, and increasingly API feeds. Each has quirks: Shapefiles truncate attribute names silently; KML mixes styling with data; CSVs never declare their CRS. A serious pipeline normalises all of this at the door — one internal representation, whatever came in — and records provenance: which file, which version, which day. When a regulator asks where a number came from, “from the March delivery of source X, transformation log attached” is an answer; “from a file someone had” is not.
I dati arrivano come Shapefile (un formato anni '90 con nomi colonna da 10 caratteri e nessuna integrità mono-file), GeoPackage, GeoJSON, KML/KMZ, CSV con le coordinate nascoste in colonne di testo, export CAD, raster GeoTIFF, e sempre più spesso feed API. Ognuno ha le sue stranezze: gli Shapefile troncano i nomi degli attributi in silenzio; il KML mescola stile e dati; i CSV non dichiarano mai il CRS. Una pipeline seria normalizza tutto all'ingresso — una rappresentazione interna, qualunque cosa sia entrata — e registra la provenienza: quale file, quale versione, quale giorno. Quando un ente chiede da dove viene un numero, «dalla consegna di marzo della sorgente X, log di trasformazione allegato» è una risposta; «da un file che qualcuno aveva» no.
Transform: Where Data BreaksTransform: dove i dati si rompono
Three transformations cause most of the pain. Reprojection: mixing WGS84 with a national grid shifts everything by hundreds of metres — the classic “my points are in the sea” bug. Geometry repair: analysis functions fail or lie on invalid geometries, so validation must be systematic, not an afterthought when a query crashes. Vocabulary harmonisation: the same real-world thing arrives spelled three ways from three sources. A join that silently matches nothing is worse than an error — it produces an empty map that looks like “no data here”.
One principle sorts good pipelines from dangerous ones: no silent fallbacks. A missing value must be declared or fail loudly — never silently replaced by a default that turns into a wrong map three steps later.
Tre trasformazioni causano la maggior parte del dolore. Riproiezione: mescolare WGS84 con un sistema nazionale sposta tutto di centinaia di metri — il classico bug «i miei punti sono in mare». Riparazione delle geometrie: le funzioni di analisi falliscono o mentono sulle geometrie invalide, quindi la validazione deve essere sistematica, non un ripiego quando una query esplode. Armonizzazione dei vocabolari: la stessa cosa reale arriva scritta in tre modi da tre sorgenti. Un join che silenziosamente non aggancia nulla è peggio di un errore — produce una mappa vuota che sembra «qui non ci sono dati».
Un principio separa le pipeline buone da quelle pericolose: niente fallback muti. Un valore mancante va dichiarato o deve fallire rumorosamente — mai sostituito in silenzio da un default che tre passi dopo diventa una mappa sbagliata.
Load: Serving, not StoringLoad: servire, non archiviare
The destination of a modern pipeline is not a folder of files but a serving layer: a spatial database with indexes tuned for the queries that will actually run, vector tiles for the map, OGC endpoints for external tools, and access control applied at load time — not bolted on later. This is where ETL quietly becomes governance: whoever controls the load step controls what is queryable, by whom, and how fresh it is. “Load” done well is the difference between a data swamp and a platform.
La destinazione di una pipeline moderna non è una cartella di file ma uno strato di servizio: un database spaziale con indici tarati sulle query che verranno eseguite davvero, vector tile per la mappa, endpoint OGC per gli strumenti esterni, e il controllo degli accessi applicato al momento del load — non appiccicato dopo. È qui che l'ETL diventa silenziosamente governance: chi controlla il load controlla cosa è interrogabile, da chi, e quanto è fresco. Un «load» fatto bene è la differenza fra una palude di dati e una piattaforma.
A Pipeline ChecklistChecklist per una pipeline
- Every source normalised at the door, with recorded provenance and version.
- One declared CRS internally; reprojection is explicit, never implicit.
- Geometry validation as a gate, not a patch.
- Vocabulary mappings versioned and reviewable — a join that matches zero rows must alert, not pass.
- Repeatability: re-running the pipeline on the same input yields the same output.
- The output is a service (tiles, OGC, API), not a folder.
- Ogni sorgente normalizzata all'ingresso, con provenienza e versione registrate.
- Un solo CRS dichiarato all'interno; la riproiezione è esplicita, mai implicita.
- Validazione delle geometrie come cancello, non come toppa.
- Mappature di vocabolario versionate e revisionabili — un join che aggancia zero righe deve avvisare, non passare.
- Ripetibilità: rieseguire la pipeline sullo stesso input produce lo stesso output.
- L'output è un servizio (tile, OGC, API), non una cartella.
NEXT Fusion already covers the load side of this story — spatial database, vector tiles, OGC services and tenant-level access control on the same layers — and imports the common formats at the door. The transformation layer is where we are investing next.
NEXT Fusion copre già il lato load di questa storia — database spaziale, vector tile, servizi OGC e controllo accessi per tenant sugli stessi layer — e importa i formati comuni all'ingresso. Lo strato di trasformazione è dove stiamo investendo adesso.