[Gfoss] formato di scambio o formato di lavoro ? - ex Quale formato

[a.furieri a lqt.it]

Noto che spesso si parla di formati di scambio e di lavoro come se
fossero la medesima cosa e come se fossero due concetti piu' o
meno equivalenti e liberamente interscambiabili.

Dissento fortemente da questa interpretazione perche' mi sembra
un po' troppo semplicistica e quindi inevitabilmente fuorviante.
formati di scambio e formati di lavoro rispondono a due esigenze
funzionali ampiamente diversificate e spesso chiaramente antitetiche:
- un buon formato di scambio spesso e' un pessimo formato di lavoro.
- un buon formato di lavoro spesso non e' affatto un formato di 
scambio.

Provo a spiegare perche' questo accade inevitabilmente; purtroppo
non potro' fare a meno di approfondire alcuni dettagli tecnici.


supporto per gli accessi random
--------------------------------
cioe' capacita' di leggere selettivamente solo determinate porzioni del
dataset (quanto piu' piccole possibile) e seguendo un ordine 
assolutamente
casuale e non prestabilito a priori.

giusto un paio di esempi ultra-familiari:
- un documento di testo me lo devo sempre necessariamente leggere
   tutto da cima a fondo: se anche mi interessa un singolo paragrafo
   oppure una singola riga comunque prima devo caricare in memoria tutto
   il documento per intero, e solo in sequito posso provare a cercare
   quel determinato paragrafo o quella specifica riga.
   anche nel migliore dei casi mi dovro' comunque leggere il documento
   almeno fino a quando non trovo la frase incriminata (e potrebbe anche
   trovarsi proprio in fondo in fondo).
- un'imagine JPEG la devo necessariamente leggere e decomprimere in una
   singola passata. se anche mi interessa estrapolare solo un 
microscopico
   tassello (p.es. il volto di mia cugina da una foto di gruppo) non 
posso
   mai fare a meno di occupare inutilmente un sacco di RAM per 
decomprimere
   l'intera immagine in via preliminare.

- invece un file DBF e pure uno SHP (almeno in teoria) mi consentono
   di estrarre in modo molto selettivo solo quelle quattro o cinque
   features che mi interessano ignorando tutte le altre.
   anche quando lo SHP nel suo complesso contiene magari svariati
   milioni di features; basta solo disporre di appropriati indici di
   ricerca, sia spaziali che non spaziali.
   non e' detto che poi questa capacita' sia effettivamente implementata
   dalle mille applicazioni che supportano DBF / SHP: ma almeno in pura
   teoria il formato consente questa possibilita'.
- anche un'immagine TIFF strutturata per scanlines o per tiles mi
   consente di estrarre una singola tile ignorando tutte le altre,
   e quindi si presta (teoricamente) bene per estrapolare piccoli
   dettagli dall'immagine complessiva (sempre ammesso che sappia dove
   andare a cercarli).

corollario: un formato che non supporta intrinsecamente nessun tipo
di accesso random puo' essere un ottimo formato di scambio.
ma in pratica sara' un formato di lavoro assolutamente insoddisfacente
perche' impone dei carichi computazionali ed un consumo di risorse
del tutto indesiderabili e non ottimizzabili visto che sara' 
materialmente
impossibile implementare una qualsivoglia strategia di indexing 
selettivo.

in soldoni: non solo e' lento, e' pure sconsideratamente sciupone.
puo' ancora andar bene nei contesti applicativi piu' semplici e
limitati, ma mostrera' sicuramente la corda con l'aumentare dei
carichi e dei volumi di lavoro, come inevitabilmente accade nei
contesti professionali o istituzionali.


supporto per il c.d. "in place replacement"
-------------------------------------------
cioe' capacita' di modificare/correggere una informazione gia' presente
sostituendo direttamente il valore pre-esistente (cioe' effettuando
una semplice sovra-scrittura).

sempre continuando con i soliti esempi ultra-familiari:
- qualsiasi editor di testo / word processor non ha mai nessuna
   capacita' di in-place-replacement; e cosi' dicasi anche per
   tutti i fogli di calcolo.
   se anche mi limito a correggere una singola virgola l'intero
   documento verra' comunque sovra-scritto per intero da capo a fondo;
   se sfortunatamenta va via la corrente a meta' rischio seriamente
   di perdere sia la veccha versione che la nuova e di trovarmi alla
   fine con un file irrimediabilmente corrotto e quindi inutilizzabile.
   in genere il sw applicativo e' abbastanza furbo da salvarsi uno
   swap-file temporaneo in via precauzionale; ma non e' qualcosa
   di direttamente supportato dal formato in quanto tale, e'
   piuttosto un'indispensabile assicurazione anti-infortuni (nonche'
   un'ulteriore complicazione indesiderata) imposta dai limiti
   intrinseci del formato.

- un file DBF (sempre in teoria) consente invece di modificare il
   valore di una singola cella in modo preciso e selettivo, e senza
   alcun bisogno di toccare in alcun modo le altre celle.
   temo sinceramente che ben pochi applicativi sfruttino questa
   capacita' intrinseca; sono quasi certo che sia Excel che Calc
   lavorano esattamente all'inverso, cioe' per sostituzione totale
   dell'intero archivio piuttosto che per correzione di singole celle.
   ma ovviamente e' un problema delle applicazioni, non e' certo
   un limite imposto dal formato in quanto tale.

corollario: un formato che non supporti in alcun modo il c.d.
"in place replacement" puo' ben essere un ottimo formato di
scambio. ma sara' inevitabilmente un pessimo formato di lavoro
(tranne che per chi lavora in pura lettura facendo solo ed
esclusivamente attivita' di mera consultazione, come accade
p.es. nel caso delle pagine HTML).


supporto transazionale
----------------------
quando si aggiorna/modifica/elimina/inserisce una qualsiasi 
informazione
sul file-system ci sono sempre mille pericoli insidiosi in agguato.
una interruzione di alimentazione, un guasto hardware, un crash 
improvviso
del programma possono mandare tutto in malora con risultati 
assolutamente
disastrosi.
nel caso migliore posso semplicemente perdere le ultime modifiche; nel
caso piu' catastrofico posso addirittura ritrovarmi con un dataset
pesantemente corrotto e del tutto inutilizzabile nel suo complesso.
peggio ancora; posso ritrovarmi con informazioni incoerenti e 
mutuamente
contraddittorie. magari il problema potrebbe emergere solo a distanza
di tempo, quando ovviamente sara' troppo tardi per rimediare e quando
verosimilmente il problema si sara' allargato a macchia d'olio con
conseguenze nefaste e devastanti.

il problema e' del tutto irrilevante per un formato di mero scambio
dati; se l'import non va a buon fine posso pur sempre ricominciare
pazientemente da capo. se fallisce durante la fase di export posso
comunque ritentare in un secondo momento.
ma per un formato di lavoro qualsiasi incidente durante un'operazione
di scrittura e' sempre potenzialmente catastrofico, perche' rischia
di friggere tutto quanto in un sol colpo.

torniamo ad un esempio concreto basato su file DBF; il formato mi
consente di inserire nuove righe senza toccare quelle gia' esistenti;
basta semplicemente aggiungerle il coda al file.
pero' occorre anche aggiornare contemporaneamente le informazioni
presenti nel primo blocco di testa (header); le due azioni devono
necessariamente avvenire in sincronia perfetta, e sono ovviamente
del tutto indipendenti l'una dall'altra.
qualsiasi incidente produce direttamente un DBF corrotto.
ancora peggio nel caso di uno SHP, perche' in quest'ultimo caso
presumibilmente devo anche aggiornare i due files SHP e SHX inserendovi
le nuove righe e modificando i corrispettivi headers.
se una qualsiasi di queste operazioni fallisce mi trovero' alla fine
con uno Shapefile malfunzionante.

peccato solo che DBF e SHP non offrano assolutamente nulla per
tutelarsi in caso di malaugurati incidenti; si affidano fiduciosamente
alla protezione miracolosa di qualche Nume benevolente.
ma i miracoli notoriamente sono piu' l'eccezione che la regola ...
ogni tanto qualcuno finisce inevitabilmente con lo scottarsi.

corollario: usare un formato di lavoro di tipo non transazionale
non e' per nulla affidabile, e quindi e' decisamente pericoloso
e fortemente sconsigliabile.
e' un approccio che va sicuramente bene per gli hobbisti (absit
iniuria), ma non puo' venire preso in nessuna seria considerazione
in un contesto professionale o istituzionale.


una valutazione complessiva
---------------------------
- un buon formato di interscambio non ha obblighi di efficienza.
   e' molto piu' importante che sia facilmente interoperabile, che
   sia definito in modo chiaro, ben documentato e rigoroso, che non
   presenti nessun vincolo dipendente da specifiche piattaforme o
   da specifici componenti, che sia assolutamente stabile nel tempo.
   soprattutto e' decisivo che sia generosamente supportato dal
   numero piu' ampio possibile di componenti ed applicazioni, in modo
   tale da  facilitarne un'adozione pressoche' universale in tutti i
   contesti possibili ed immaginabili, anche in quelli meno ovvi.

- invece un formato di lavoro mette sempre necessariamente la
   robustezza, l'efficienza e l'affidabilita' al primissimo posto.
   se introdurre una nuova funzionalita' o essere piu' efficienti
   o anche semplicemente rimuovere un critical bug implica una qualche
   rottura della interoperabilita' con le versioni precedenti si
   cerchera' possibilmente di mitigare il problema offrendo qualche
   tool accessorio che faciliti le conversioni in modo quanto piu'
   possibile indolore, ma non per questo si rinuncera' a modificare
   il formato.

e' fin troppo facile constatare che si tratta di due "Weltanschauung"
nettamente diversificate e per molti versi antitetiche.
in alcuni casi particolarmente felici sara' anche possible ottenere
qualche compromesso a meta' strada che metta d'accordo capra e cavoli,
ma sara' pur sempre una mezza-soluzione che lascera' inevitabilmente
qualche aspetto piu' o meno critico risolto solo in via approssimativa.

magari come nel caso dello Shapefile, che proprio a causa degli 
infiniti
difetti che si porta dietro fin dalla nascita finisce per essere un
"ragionevole compromesso" che riesce a conciliare (male, ma meglio di
niente) tantissime esigenze contrastanti.
quasi tutti lo odiano e ne parlano male, ma praticamente nessuno riesce
mai a farne del tutto a meno. ;-)

viceversa SpatiaLite funziona esattamente all'opposto di Shapefile;
mette sempre al primo posto efficienza e funzionalita', sacrificando
eventualmente la compatibilita' universale quando e' indispensabile.
a dispetto di tutto questo, riesce comunque a conservare una 
"ragionevole"
interoperabilita', certamente imperfetta ma mediamente soddisfacente.
almeno fino a quando su entrambi i versanti si usa la medesima versione
della libreria la compatibilita' e' sempre pienamente assicurata.
se le versioni della libreria sono diverse allora e' possibile (non e'
sempre detto) che sia richiesta qualche operazione di conversione
(come e' accaduto p.es. nel passaggio dalla 3.x alla 4.x).

del resto SpatiaLite non ha mai preteso di presentarsi come un formato
di scambio universale; io per primo ho sempro vivacemente polemizzato
con chi intendeva presentare SpatiaLite principalmente come un vero e
proprio formato di scambio.
e' del tutto ovvio che non potra' mai esserlo, perche' e' in primis uno
Spatial DBMS che segue la sua naturale spirale di sviluppo evolutivo;
la capacita' di essere *anche* facilmente interscambiabile tra
piattoforme disomogenee e' sicuramente un bonus molto interessante,
ma non e' certamente la prima ragione d'essere del progetto.

il GeoPackage "Candidate" si che avrebbe avuto effettivamente tutte
le carte in regola per riuscire a diventare un formato di scambio
universale vero e proprio oltre ad essere uno Spatial DBMS a
tutti gli effetti.
... ma se persino l'US Army non e' riuscito a portare a casa
l'obbiettivo qualcosa vorra' pur dire; evidentemente ci sono
troppe forze che spingono in tutt'altre direzioni :-D


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

a questo punto tiriamo velocemente le somme:

- GML, KML, GeoJSON, CSV (e qualsiasi altro formato testuale)
   non supportano gli accessi random, non supportano l'in-place
   replacement, non offrono nessuna sicurezza transazionale,
   non si sposano affatto bene con l'indexing.
   possono essere certamente ottimi formati di scambio (e di
   fatto lo sono). ma sono sicuramente pessimi formati di lavoro.

- DBF / Shapefile
   supportano gli accessi random e pure l'in-place replaceemnt
   (almeno a spanne; entrare nel dettaglio sarebbe troppo noioso)
   pero' non offrono nessuna tutela transazionale: qualsiasi
   incidente e' potenzialmente catastrofico, come del resto
   conferma la pratica esperienza sul campo.
   praticamente tutto dipende dalla specifica implementazione;
   il formato di per se non garantisce nulla, apre solo delle
   interessanti potenzialita' che potrebbero venire sfruttate
   in modo intelligente come anche no ...
   in ultima analisi tutto dipende esclusivamente dall'applicazione;
   non e' una base di partenza ottimale per sperare in una reale
   interoperabilita' universale (che in effetti, non sempre e'
   assicurata come si potrebbe sperare).
   insomma, e' un mediocre formato di lavoro (sicuramente buono
   per i palati meno raffinati e per le esigenze meno complesse)
   ed e' anche un ragionevole formato di scambio.
   presenta pecche evidenti su entrambi i versanti, ma ben si sa
   che l'"aurea mediocritas" alla fine paga sempre.
   e' decisamente semplice ed e' molto ben radicato, quindi e'
   sicuramente immortale :-D

infine abbiamo tutta la genia dei DBMS / Spatial DBMS; questi si
che offrono realmente di tutto (ed anche molto di piu').
supportano gli accessi random, supportano l'in-place-replacement,
supportano le transazioni, supportano pure l'indexing sia per
i dati generici che per quelli specializzati di tipo spatial.
ma supportano pure i constraints, i triggers, i vincoli relazionali
ed un sacco di altra roba super-fighissima.

soprattutto supportano intrinsecamente quel meraviglioso ed ultra
potente linguaggio universale per la definizione e la manipolazione
dei dati che e' SQL
un DBMS mi consente tranquillamente di progettare, gestire e consultare
una banca dati corposa e molto complessa anche in totale assenza di
qualsiasi altro sw applicativo piu' specializzato.
usare una qualche app di supporto mirato e' quasi sempre consigliabile
perche' facilita di gran lunga il lavoro, ma non e' mai strettamente
indispensabile.

last but not least: i DBMS sono pure mostruosamente efficienti e
dannatamente robusti, perche' hanno alle spalle una solida teoria
matematica supportata da una lunghissima esperienza operativa sul
campo consolidatasi in tutte le condizioni d'uso concepibili, anche
e soprattutto in quelle piu' severe ed impegnative.
da circa quarant'anni a questa parte i DBMS dominano incontrastati
in tutti i settori dell'Information Technology quando entrano in
gioco moli di dati impegnative.
solo all'interno del mondo GIS i DBMS sono ancora considerati con
palese sospetto e con mal celata diffidenza.

colpa del GIS o colpa dei DBMS ?
ai posteri l'ardua sentenza :-D

ciao Sandro