Allegato B — Standard di riferimento e formati aperti
B.1 Standard di riferimento
Come già indicato per i principi FAIR (v. par. 4.4) e, più in generale, nelle indicazioni fornite nei paragrafi 5.1.4 e 5.1.5 relativi alle fasi, rispettivamente, di arricchimento e di modellazione, per assicurare l’interoperabilità e consentire che dati e metadati possano essere combinati con altri dati e/o strumenti, è necessario, tra l’altro, che vengano utilizzati standard pertinenti, oltre a vocabolari controllati, thesauri e ontologie, riconosciuti auspicabilmente a livello internazionale.
Nel pubblicare dati aperti, quindi, sarebbe opportuno, ove possibile, seguire standard definiti dagli organismi di standardizzazione internazionali, come ISO, W3C, OGC, IETF, o nell’ambito delle attività istituzionali della Commissione Europea. Nel caso in cui non siano disponibili standard a livello internazionale e/o europeo, allora si può fare riferimento a standard e regole tecniche nazionali, anche definiti dalle amministrazioni competenti in funzione dello specifico dominio. Si richiama qui quanto indicato per i modelli dati al par. 5.1.5.
Le tabelle che seguono riportano l’elenco, non esaustivo, dei principali standard di riferimento. In aggiunta a quelli riportati, sono da considerare i documenti tecnici (come, per es., le Linee Guida) indicati nel Capitolo 2.
| Acronimo/ abbreviazione | Titolo | Organismo di standardizzazione | Dominio |
|---|---|---|---|
| DataCube | The RDF Data Cube Vocabulary | W3C | Dati statistici |
| EU vocabularies | Risorse (vocabolari controllati, modelli, schemi e ontologie) rese disponibili dall’Ufficio delle Pubblicazioni dell’Unione Europea | Commissione Europea | Vari domini |
| INSPIRE | Infrastructure for Spatial Information in the European Community | Commissione Europea | Dati territoriali |
| ISO 639 | Language codes | ISO | Lingua |
| ISO 8601 | Date and time format | ISO | Tempo |
| ISO 19100 | Serie 19100 “Geographic Information” | ISO | Dati territoriali |
| NDC | Catalogo nazionale della semantica dei dati | Governo italiano / ISTAT | Vari domini |
| NUTS | Nomenclature of territorial units for statistics | Commissione Europea | Dati territoriali |
| SDMX | Statistical Data and Metadata eXchange | SDMX community | Dati statistici |
| Regole tecniche dati territoriali | Governo italiano / AgID | Dati territoriali |
SDMX è anche uno Standard ISO (ISO 17369:2013)
| Acronimo/ abbreviazione | Titolo | Organismo di standardizzazione | Dominio |
|---|---|---|---|
| DCAT | Data Catalog Vocabulary | W3C | Vari domini |
| DCAT-AP_IT | DCAT Application Profile (Italia) | AgID | Vari domini |
| DCMI | Dublin Core Metadata Initiative | Dublin Core | Vari domini |
| RNDT | Profilo italiano di metadati per i dati territoriali e relativi servizi | AgID | Dati territoriali |
DCMI è anche disponibile come Standard ISO:
- ISO 15836-1:2017 Information and documentation — The Dublin Core metadata element set — Part 1: Core elements;
- ISO 15836-2:2019 Information and documentation — The Dublin Core metadata element set — Part 2: DCMI Properties and classes
B.2 Formati aperti per dati e documenti
Nei sottoparagrafi che seguono vengono elencati i più comuni formati per dati e documenti; un elenco comunque non esaustivo. Per alcuni formati, vengono indicate anche alcune puntuali raccomandazioni tratte dal documento “data.europa.eu – Data quality guidelines”, indicato nel box “Risorse utili”, a cui si rimanda per ulteriori approfondimenti.
Una raccomandazione generale valida per tutti i formati è la seguente:
- Utilizza codifiche dei caratteri standard
Per garantire che i caratteri siano visualizzati correttamente e avere la massima compatibilità possibile con le applicazioni che elaborano i dati, è sempre necessario utilizzare una codifica standardizzata dei caratteri. In genere, UTF-8 è la codifica utilizzata nel web. È utile, in ogni caso, indicare qual è la codifica dei caratteri utilizzata.
B.2.1 Formati aperti per i dati
B.2.1.1 CSV (Comma Separated Values)
È un formato di file testuale utilizzato per rappresentare informazioni con struttura tabellare. Le righe delle tabelle corrispondono a righe nel file di testo CSV e i valori delle celle sono divisi da un carattere separatore, che, come indica il nome stesso, dovrebbe essere la virgola. Il CSV non è uno standard vero e proprio ma la sua modalità d’uso è descritta nell’RFC 4180. Nel rilascio di dati secondo il formato CSV, per agevolare i riutilizzatori, si raccomanda di dichiarare almeno 1) il separatore di campo utilizzato (per es., virgola, punto e virgola); 2) se è stato usato un carattere per delimitare i campi di testo.
B.2.1.1.1 Raccomandazioni sul formato CSV1
B.2.1.1.1.1 Dichiara il separatore di campo utilizzato
Come indicato nel nome stesso del formato, il separatore dei campi è generalmente la virgola. Tuttavia, possono essere utilizzati altri segni; il documento europeo suggerisce di utilizzare il punto e virgola perché la virgola è utilizzata spesso all’interno dei valori, per esempio in caso di numeri decimali. In ogni caso, è bene rendere esplicito al fruitore dei dati qual è il separatore utilizzato.
B.2.1.1.1.2 Utilizza un file per tabella
Ogni file CSV deve contenere solo una tabella. Se la tabella da pubblicare è composta da più fogli, è necessario creare un file CSV per ogni foglio. Nella tabella ogni riga deve contenere una sola osservazione, così come ogni colonna una sola variabile (cd. regole di Tidy Data).
B.2.1.1.1.3 Evita gli spazi bianchi e informazioni aggiuntive nel file
È importante assicurarsi che il file contenga solo i dati che appartengono alla tabella effettiva, come le intestazioni di colonna e i valori delle voci presenti nella tabella stessa. Nel file CSV, quindi, non devono essere presenti titolo della tabella, righe vuote o eventuali informazioni aggiuntive che aiutino l’utente a capire meglio i dati (queste ultime, che sono utilissime, vanno inserite nei metadati). Il file, inoltre, deve contenere una sola riga di intestazione.
B.2.1.1.1.4 Inserisci le intestazioni di colonna
Le intestazioni di colonna devono essere auto-esplicative ed essere incluse nella prima riga del file CSV. Senza le intestazioni, è difficile per gli utenti interpretare il significato dei dati. Le intestazioni dovrebbero seguire le etichette dei concetti definiti nelle ontologie di riferimento, se disponibili, pubblicate nel Catalogo nazionale della semantica dei dati.
B.2.1.1.1.5 Assicurati che tutte le righe abbiano lo stesso numero di colonne
Ogni riga deve avere lo stesso numero di colonne e, quindi, di caratteri separatori. Se in una riga manca un valore, questo di solito viene interpretato come “null”. Ciò può comportare un trattamento errato dei dati. Se il CSV contiene righe con un numero diverso di colonne, bisognerebbe controllare se c’è un problema con valori di ‘escape’ non corretti (ad es. un valore che corrisponde al carattere separatore che in quel caso non va interpretato come tale).
B.2.1.1.1.6 Indica le unità in una modalità facilmente elaborabile
L’unità di misura di un valore dovrebbe essere indicata nell’intestazione della colonna. Se l’unità cambia da un valore all’altro, allora bisognerebbe considerare una colonna dedicata con un’opportuna intestazione e non inserire l’unità insieme al valore stesso. Per le unità dovrebbero essere utilizzati i codici (URI) derivati da un vocabolario controllato.
B.2.1.2 JSON (JavaScript Object Notation)
È un formato aperto per la rappresentazione e lo scambio di dati semi-strutturati, leggibile anche dagli utenti e che mantiene, rispetto a formati simili come l’XML, una sintassi poco prolissa. Questo aspetto ne fa un formato flessibile e compatto. Esso nasce dalla rappresentazione di strutture dati semplici nel linguaggio di programmazione JavaScript, ma mantiene indipendenza rispetto ai linguaggi di programmazione.
B.2.1.2.1 Raccomandazioni sul formato JSON2
B.2.1.2.1.1 Utilizza tipi di dati adeguati
JSON consente l’utilizzo dei seguenti tipi di dati:
- Valore nullo (assenza di un valore), rappresentato dalla parola chiave
null; - Valori booleani, vero o falso;
- Stringhe, dove la mascheratura dei singoli caratteri funziona allo stesso modo del file CSV;
- Numeri e sequenze semplici delle cifre 0–9, eventualmente con un segno e/o punto decimale;
- Elenchi, detti anche array, racchiusi tra parentesi quadre, in cui i singoli elementi sono separati da virgole. Gli elenchi possono anche essere vuoti;
- Oggetti, racchiusi tra parentesi graffe e contenenti un numero qualsiasi di coppie chiave-valore separate da virgole.
Per ulteriori elaborazioni è importante utilizzare tipi di dati adeguati.
B.2.1.2.1.2 Utilizza le gerarchie per raggruppare i dati
Invece di allegare tutti i campi all’oggetto radice del JSON, i dati dovrebbero essere raggruppati semanticamente. Ciò migliora la leggibilità da parte degli esseri umani e può migliorare le prestazioni durante l’elaborazione del file.
B.2.1.3 XML (eXtensible Markup Language)
È un linguaggio di marcatura standardizzato dal W3C usato per l’annotazione di documenti e per la costruzione di altri linguaggi più specifici per l’annotazione di documenti. XML è basato sull’utilizzo di marcatori (tag) che consentono di strutturare il contenuto informativo da rappresentare. Nell’ambito del Web Semantico è stata definita una specifica serializzazione RDF/XML.
B.2.1.3.1 Raccomandazioni sul formato XML3
B.2.1.3.1.1 Fornisci una dichiarazione XML
Ogni file XML dovrebbe avere una dichiarazione XML completa. Questa contiene metadati relativi alla struttura del documento ed è importante affinché le applicazioni elaborino correttamente il file.
B.2.1.3.1.2 Fai l’“escaping” dei caratteri speciali
Quando vengono utilizzati caratteri speciali nei file XML, è necessario eseguire l’ “escape”. Ciò garantisce una struttura del file pulita e impedisce alle applicazioni utilizzate per l’elaborazione del file di interpretare erroneamente i dati. L’ ‘escape’ viene eseguito sostituendoli con le entità XML equivalenti.
B.2.1.3.1.3 Utilizza nomi significativi per gli identificatori
Tutti gli identificatori, siano essi tag o attributi, dovrebbero avere nomi significativi e non dovrebbero auspicabilmente essere usati due volte.
B.2.1.3.1.4 Utilizza correttamente attributi ed elementi
Sebbene non vi sia una direttiva vincolante obbligatoria in merito alla codifica dei dati in elementi o attributi, la prassi è che le informazioni che fanno parte dei dati effettivi debbano essere rappresentate da elementi. I metadati che contengono informazioni aggiuntive dovrebbero invece essere implementati come attributi.
B.2.1.3.1.5 Rimuovi i dati specifici del programma
XML, come qualsiasi formato aperto, dovrebbe essere sempre indipendente da programmi o strumenti specifici utilizzati per l’elaborazione dei file. Questo permette all’utente di scegliere lo strumento che preferisce per il trattamento dei dati senza doverlo prima bonificare.
B.2.1.4 Serializzazioni RDF
B.2.1.4.1 N-triples
È una serializzazione di RDF in cui ogni tripla è espressa interamente e indipendentemente dalle altre. La concatenazione delle triple di un dataset RDF secondo N-Triples avviene utilizzando il carattere punto (es., <soggetto1> <predicato1> <oggetto1> . <soggetto2> <predicato2> <oggetto2>).
B.2.1.4.2 Notation3
Notation3 (o N3) è una serializzazione RDF pensata per essere più compatta rispetto a quella ottenuta utilizzando la sintassi XML. Essa risulta più leggibile da parte degli utenti e possiede delle caratteristiche che esulano dall’uso stretto di RDF (per es., rappresentazione di formule logiche).
B.2.1.4.3 Turtle
È una versione semplificata (un sottoinsieme di funzionalità) di N3. Un dataset in Turtle è una rappresentazione testuale di un grafo RDF e, al contrario di RDF/XML, è di più facile lettura e gestione anche manuale.
B.2.1.4.4 JSON-LD
È un formato di serializzazione per RDF, standardizzato dal W3C, che fa uso di una sintassi JSON. Viene proposto come formato per Linked Data, mascherando di proposito la sua natura di serializzazione di RDF per ragioni di diffusione del formato. Il gruppo di lavoro che l’ha definito ha posto come obiettivo, oltre quello di mettere a disposizione un’ulteriore funzionalità al framework RDF, anche quello di avvicinare il mondo dello sviluppo Web e degli utilizzatori dei sistemi di gestione dati NoSQL (in particolare dei document store) al Web Semantico. Da un punto di vista pratico è possibile rilasciare dati RDF utilizzando questo «dialetto» JSON nelle situazioni in cui inizialmente non ci si possa dotare di tecnologie ad-hoc come triple store. Allo stesso tempo, con JSON-LD si fornisce uno strumento standard che consente il collegamento di documenti JSON che per loro natura sono unità di informazione indipendenti.
B.2.1.4.5 Raccomandazioni sul formato RDF/xxx4
B.2.1.4.5.1 Utilizza URI http/https per identificare le risorse
Gli ID di una risorsa dovrebbero essere URI HTTP/HTTPS, poiché questi consentono l’accesso diretto alla risorsa in questione. Rendono inoltre le risorse indicizzabili dai motori di ricerca, il che migliora la loro reperibilità.
B.2.1.4.5.2 Utilizza ‘namespace’ (spazi dei nomi) quando possibile
Sebbene gli spazi dei nomi non siano necessari per l’elaborazione di RDF, riducono la verbosità e le dimensioni del file.
B.2.2 Formati aperti più diffusi per i dati geografici
B.2.2.1 Shapefile
È il formato standard de-facto per la rappresentazione dei dati dei sistemi informativi geografici (GIS). I dati sono di tipo vettoriale. Lo shapefile è stato creato dalla società privata ESRI che rende comunque pubbliche le sue specifiche. L’apertura delle specifiche ha consentito lo sviluppo di diversi strumenti in grado di gestire e creare tale formato. Seppur impropriamente ci si riferisca a uno shapefile, nella pratica si devono considerare almeno tre file: un .shp contenente le
forme geometriche, un .dbf contenente il database degli attributi delle forme geometriche e un file
.shx come indice delle forme geometriche. A questi tre si deve anche accompagnare un file .prj che contiene le impostazioni del sistema di riferimento. Si raccomanda comunque di specificare nei metadati la proiezione utilizzata, meglio se fornendo il file .prj stesso. È importante notare che non risulta ancora chiaro se tale formato lo si possa considerare propriamente aperto (e quindi coerente con la definizione introdotta dal CAD) di livello 3 secondo il modello per i dati proposto nel presente documento. Tenuto conto dell’ampio uso di tale formato per la rappresentazione dei dati geografici si ritiene opportuno includerlo comunque in questo elenco.
B.2.2.2 KML
È un formato basato su XML per rappresentare dati geografici. Nato con Google, è diventato poi uno standard OGC. Le specifiche della versione 2.2 presentano una serie di entità XML attraverso cui archiviare le coordinate geografiche che rappresentano punti, linee e poligoni espressi in coordinate WGS84 e altre utili a definire gli stili attraverso cui visualizzare i dati. Eventuali attributi delle geometrie vanno espressi invece attraverso la personalizzazione di alcune entità. Molti strumenti di conversione non si occupano tuttavia di creare questa struttura dati e delegano gli attributi delle geometrie allo stile di visualizzazione. Si consiglia pertanto di distribuire questo dato prestando attenzione o, eventualmente, accompagnando il dataset assieme ad un altro formato aperto per i dati geografici (ad esempio, .shp, .geojson).
B.2.2.3 GeoJSON
È un formato aperto per la rappresentazione e l’interscambio dei dati territoriali in forma vettoriale, basato su JSON. Ogni dato è codificato come oggetto che può rappresentare una geometria, una caratteristica o una collezione di caratteristiche. A ogni oggetto è associato un insieme di coppie nome/valore (membri). I principali nomi di membri che rappresentano le caratteristiche dei dati geografici sono: «type» che serve a indicare il tipo di geometria (punto, linea, poligono o insieme multi-parte di questi tipi); «coordinates» attraverso cui sono indicate le coordinate dell’oggetto in un dato sistema di riferimento; «bbox» attraverso cui sono indicate le coordinate di un riquadro di delimitazione geografica; «crs» (opzionale) per l’indicazione del sistema di riferimento. Inoltre, è possibile associare all’oggetto specifici attributi, attraverso il membro con nome «properties». Si tratta di un formato molto diffuso e supportato da diversi software, ampiamente utilizzato in ambito di sviluppo web. Nel 2016 è stata pubblicata la relativa RFC 7946 “The GeoJSON Format”. La specifica raccomanda di limitare la precisione delle coordinate a 6 decimali, attraverso cui si può specificare qualsiasi posizione sulla terra con una
tolleranza di 10 centimetri. La specifica inoltre richiede che i dati siano memorizzati con un sistema di riferimento di coordinate geografiche WGS 84, in latitudine e longitudine, nello stesso stile dei dati GPS.
B.2.2.4 GML
È una grammatica XML che rappresenta un formato di scambio aperto per i dati territoriali. Definita originariamente da OGC e diventata poi lo Standard ISO 19136:2008, essa fornisce la codifica XML (schemi XSD) delle classi concettuali definite in diversi Standard ISO della serie 19100 e di classi aggiuntive quali: geometrie, oggetti topologici, unità di misura, tipi di base, riferimenti temporali, caratteristiche, sistemi di riferimento, copertura.
B.2.2.5 GeoPackage
È un formato aperto per la rappresentazione di dati geografici e può essere un’alternativa al suddetto formato shapefile. Esso supporta SpatiaLite ovvero un’estensione dello schema del database SQLite. Il principale vantaggio offerto da GeoPackage è quello di rappresentare in un unico file diversi dati geografici, sia di tipo vettoriale che raster, che possono essere gestiti anche tramite apposite interrogazioni SQL. Lo standard è riconosciuto dall’Open Geospatial Consortium.
B.2.3 Formati aperti per i documenti
B.2.3.1 ODF (Open Document Format)
È uno standard dell’OASIS che specifica le caratteristiche di un formato per documenti digitali basato su XML, indipendente dall’applicazione e dalla piattaforma utilizzata. La seguente serie di formati aperti è parte dello standard OASIS ODF:
- ODT (Open Document Text). Standard aperto per documenti testuali. È stato adottato come formato principale per i testi in alcune suite per l’automazione
d’ufficio come OpenOffice.org e LibreOffice; è supportato da altre come Microsoft Office, Google Drive e IBM Lotus.
ODS (Open Document Spreadsheet). Standard aperto per fogli di calcolo. Come nel caso precedente, è stato adottato come formato principale per i fogli di calcolo in alcune suite per l’automazione d’ufficio come OpenOffice.org e LibreOffice; è supportato da altre come Microsoft Office, Google Drive e IBM Lotus.
ODP (Open Document Presentation). Standard aperto per documenti di presentazione. È stato adottato come formato principale per i documenti di presentazione in alcune suite per l’automazione d’ufficio come OpenOffice.org e LibreOffice; è supportato da altre come Microsoft Office, Google Drive e IBM Lotus.
B.2.3.2 PDF
È un formato aperto creato da Adobe per la rappresentazione di documenti contenenti testo e immagini che sia indipendente dalla piattaforma di lettura (applicativo, sistema operativo e hardware). È stato standardizzato dall’ISO (ISO/IEC 32000-1:2008) con una serie di formati differenti, ognuno avente una propria prerogativa (per es., PDF/UA per l’accessibilità, PDF/H per documenti sanitari, PDF/A per l’archiviazione, ecc.). Si noti che rilasciare dati secondo tale formato limita fortemente il riutilizzo dei dati stessi in quanto l’intervento umano richiesto per la loro elaborazione è molto elevato (dati rilasciati in formato PDF con una licenza aperta rappresentano solo il primo livello del modello dei dati aperti e quindi non sono coerenti con il REQUISITO 2 delle presenti Linee Guida).
B.2.3.3 Akoma Ntoso
È un linguaggio basato su XML per la rappresentazione di documenti giuridici. Nel 2017 è diventato una specifica OASIS.
Lo standard Akoma Ntoso 1.0 al primo livello è stato adottato quale standard di riferimento per la rappresentazione elettronica dei provvedimenti normativi con la Circolare n. 2/2019 di AgID recante “Adozione di standard per la rappresentazione elettronica e l’identificazione univoca del patrimonio informativo di natura giuridica e istituzione del Forum Nazionale per l’informazione giuridica” (v. box “Risorse utili”), a cui si rimanda per tutto quello non previsto nelle presenti Linee Guida.
B.2.4 Altri formati per i dati di elevato valore
Per le serie di dati di elevato valore, il Regolamento UE dispone che, in generale, si debba utilizzare un formato aperto e leggibile meccanicamente riconosciuto nell’Unione o a livello internazionale, indicazione che può trovare attuazione seguendo il REQUISITO 2 e quanto riportato innanzi nel presente allegato.
Per alcune categorie tematiche, il predetto Regolamento indica la possibilità di utilizzare anche alcuni formati specifici che sono riportati di seguito.
B.2.4.1 Formati per dati meteorologici
Oltre che, in generale, un formato aperto e leggibile meccanicamente riconosciuto nell’Unione o a livello internazionale, per i dati di osservazione misurati dalle stazioni meteorologiche, il Regolamento indica che è possibile utilizzare i seguenti formati:
- JSON per dati orari;
- BUFR (Binary Universal Form for the Representation of meteorological data), formato di dati gestito dall’Organizzazione Meteorologica Mondiale (WMO – World Meteorological Organization);
- NetCDF (Network Common Data Form), insieme di librerie software e formati di dati indipendenti dalla macchina che supportano la creazione, l’accesso e la condivisione di dati scientifici array-oriented;
- ASCII (American Standard Code for Information Interchange), codice per la codifica dei caratteri da utilizzare per lo scambio generale di informazioni tra sistemi di elaborazione e comunicazione.
Per i dati climatici, possono essere utilizzati i formati NetCDF e JSON. Per gli avvisi meteo possono essere utilizzati i seguenti formati:
- CAP (Common Alerting Protocol), formato di dati basato su XML per lo scambio di avvisi pubblici ed emergenze tra tecnologie di allerta;
- RSS (Really Simple Syndication)/Atom, formati di dati basati su XML per distribuire contenuti come elenchi di informazioni conosciuti come “feed”5.
Per i dati radar, oltre al JSON, può essere utilizzato il formato HDF5 (Hierarchical Data Format), progettato per archiviare e organizzare grandi quantità di dati.
Per i dati del modello NWP (Numerical weather prediction), oltre al JSON e a NetCDF, si può utilizzare il formato GRIB (General Representation of fields In Binary), rappresentazione binaria di dati risultanti da un’osservazione o da una simulazione su modello numerico di una proprietà osservabile in un dominio spaziale e temporale su un sistema di riferimento geospaziale o celeste6.
B.2.4.2 Formati per dati statistici
Per i dati statistici il Regolamento indica che, oltre a CSV, JSON e qualsiasi altro formato aperto e leggibile meccanicamente, si può utilizzare anche il formato XML con riferimento a SDMX (Statistical Data and Metadata eXchange), uno standard ISO progettato per descrivere dati statistici e relativi metadati, normalizzare il loro scambio e migliorare la loro condivisione tra organizzazioni statistiche e simili.
B.2.4.3 Formati per i dati relativi alle imprese e alla proprietà delle imprese
Oltre all’indicazione di utilizzare qualsiasi formato che sia aperto e leggibile meccanicamente, per dati e documenti che rientrano nel campo di applicazione del Regolamento Delegato (UE) 2018/81579 della Commissione il Regolamento indica di utilizzare il formato XHTML (Xtensible HyperText Markup Language), un linguaggio di marcatura per creare pagine web che utilizza la sintassi XML.
B.2.5 Formati per immagini e dati raster
B.2.5.1 PNG (Portable Network Graphics)
È un formato che supporta la compressione dei dati senza perdita di informazioni (lossless). Nel 2004 è stato definito come Standard ISO/IEC 15948:2004, rivisto e confermato l’ultima volta nel 2021.
B.2.5.2 JPEG
È un formato che utilizza un metodo per la compressione con perdita di informazioni (lossy) per le immagini digitali. È stato definito come Standard ISO/IEC 10918 composto da cinque parti e denominato ufficialmente “Information technology – Digital compression and coding of continuous- tone still images”.
B.2.5.3 JPEG 2000
È un sistema di codifica delle immagini che utilizza tecniche di compressione all’avanguardia basate sulla tecnologia wavelet. Esso utilizza compressione sia lossy che lossless. È definito dalla suite di Standard ISO/IEC 15444-1:2019 “Information technology — JPEG 2000 image coding system”.
B.2.5.4 GeoTIFF (Georeferenced Tagged Image File Format)
È un formato che definisce una serie di tag per descrivere tutte le informazioni geografiche associate alle immagini TIFF che provengono da sistemi satellitari, ortoimmagini, modelli di elevazione digitali o come risultato di analisi geografiche. È diventato uno Standard OGC.
B.2.5.5 SAFE (Standard Archive Format for Europe)
È un formato standard per l’archiviazione e il trasporto dei dati di osservazione della Terra all’interno del sistema di archiviazione dell’Agenzia spaziale europea (ESA), conforme allo standard Open Archival Information System (OAIS).
NdR: queste linee guida sono una versione derivata dal documento ufficiale pubblicato da AgID in formato PDF. Questo sito web non è un documento ufficiale e si prega di fare riferimento al suddetto PDF.
Tratte dal documento “data.europa.eu – Data quality guidelines”, a cui si rimanda per ulteriori approfondimenti.↩︎
Tratte dal documento “data.europa.eu – Data quality guidelines”, a cui si rimanda per ulteriori approfondimenti.↩︎
Tratte dal documento “data.europa.eu – Data quality guidelines”, a cui si rimanda per ulteriori approfondimenti.↩︎
Tratte dal documento “data.europa.eu – Data quality guidelines”, a cui si rimanda per ulteriori approfondimenti.↩︎
Per RSS v. https://www.rssboard.org/rss-2-0-1, per Atom v. https://datatracker.ietf.org/doc/html/rfc4287↩︎
https://old.wmo.int/extranet/pages/prog/www/WMOCodes/ManualonCodes.html#Codes↩︎