formato di scambio o formato di lavoro ? - ex Quale formato

[a.furieri]

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
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[Andrea Peri]

E allora, tirando le somme, quali/difetti aggiungeresti al formato spatialite parlando in termini di formato di interscambio ?
Mi pare fuori di dubbio che identifichi una serie di difetti.
Ma personalmente il fatto che abbia l accesso rrandom non implica necessariamente che sia un difetto per lo scambio.
Caso è un difetto se non ha l accesso sequenziale. Ho ha un accesso random che usato per simulare l accesso sequenziale è inefficiente.

Quindi. Quali difetti devo aggiungere alla lista dei difetti di spatialite in termini di formato di scambio ?
:)

A.

Il 11/nov/2014 18:05 <[hidden email]> ha scritto:

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
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[pcav]

Il 11/11/2014 18:05, [hidden email] ha scritto:
> 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.

concordo; il punto essenziale pero', dal punto di vita dell'utente, e' la
semplicita'. e usare due formati diversi e' sempre piu' complesso, e potenzialmente
molto piu' complesso. secondo me questo e' il motivo per cui tutti, alla fin fine,
usano un formato di lavoro che sia anche scambiabile con semplicita'.
voi conoscete un formato di scambio che sia realmente utilizzato e diffuso?
qualcuno ha detto GML ;) ?
saluti.

--
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[a.furieri]

On Tue, 11 Nov 2014 18:29:59 +0100, Andrea Peri wrote:
> E allora, tirando le somme, quali/difetti aggiungeresti al formato
> spatialite parlando in termini di formato di interscambio ?
>  Mi pare fuori di dubbio che identifichi una serie di difetti.
>  Ma personalmente il fatto che abbia l accesso rrandom non implica
> necessariamente che sia un difetto per lo scambio.
>  Caso è un difetto se non ha l accesso sequenziale. Ho ha un accesso
> random che usato per simulare l accesso sequenziale è inefficiente.
>
>

no, infatti non intendevo questo :-)
e' il non avere l'accesso random che rende poco credibile l'uso di
un formato per usi diversi sal mero scambio di dati (come accade p.es.
per il GML o per GeoJSON)
ma averlo non pone nessun limite all'uso come formato di scambio.


> Quindi. Quali difetti devo aggiungere alla lista dei difetti di
> spatialite in termini di formato di scambio ?
>  :)
>

sostanzialmente uno: che funziona bene come formato di scambio se
(e solo se) si usa la medesima versione della libreria su entrambi
i versanti.
quando invece le versioni sono differenti allora tutto questo non
e' affatto assicurato: spesso non crea problemi di sorta, ma in
qualche caso potresti anche incontrare problemi piu' o meno seri
di mancata interoperabilita'.

e' sempre sicuramente assicurata una piena e totale compatibilita'
"ascendente", nel senso che una versione successiva della libreria
sara' sempre in grado di leggere qualsiasi DB-file prodotto da una
qualunque versione precedente.

purtroppo non sempre funziona nel verso opporto: una versione obsoleta
della libreria potrebbe anche non essere in grado di leggere un db-file
creato da una versione successiva.
non e' detto che accada inevitabilmente ad ogni nuovo rilascio (di
fatto e' l'eccezione piuttosto che la regola), ma e' bene essere
pienamente consapevoli che ogni tanto puo' anche capitare.

in tutti questi casi e' comunque sempre garantito che verra'
distribuito
un apposito tool per effettuare la conversione in entrambi i sensi;
onestamente ho visto girare molto di peggio, ma in queste condizioni
non possiamo certo parlare di "interoperabilita' universale assicurata
e garantita"

ovviamente e' abbastanza facile ipotizzare dei semplici workaround
che consentono di aggirare facilmente l'ostacolo.
p.es. per chi volesse eventualmente distribuire delle cartografie su
base splite basterebbe semplicemente avere la cautela di usare una
vecchia 3.x o addirittura una 2.3 per produrre i  db-files da offrire
in download (o ancora piu' banalmente, avere l'accortezza di far
girare spatialite_convert per ristabilire il vecchio formato).

allora si che potremmo anche ragionevolmente parlare di "portabilita'
universale" ... ma saremmo comunque finiti con lo scivolare nella
zona scivolosa ed un po' fangosa del workaround ;-)

ciao Sandro

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014