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 <[email protected]> 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 > _______________________________________________ > [email protected] > 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
_______________________________________________ [email protected] 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
