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

Mar 11 Nov 2014 18:29:59 CET

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 <a.furieri a lqt.it> 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
> _______________________________________________
> Gfoss a lists.gfoss.it
> 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
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20141111/99ee2dcb/attachment-0001.html>