<p dir="ltr">E allora, tirando le somme, quali/difetti aggiungeresti al formato spatialite parlando in termini di formato di interscambio ?<br>
Mi pare fuori di dubbio che identifichi una serie di difetti.<br>
Ma personalmente il fatto che abbia l accesso rrandom non implica necessariamente che sia un difetto per lo scambio.<br>
Caso è un difetto se non ha l accesso sequenziale. Ho ha un accesso random che usato per simulare l accesso sequenziale è inefficiente.</p>
<p dir="ltr">Quindi. Quali difetti devo aggiungere alla lista dei difetti di spatialite in termini di formato di scambio ?<br>
:)</p>
<p dir="ltr">A.</p>
<div class="gmail_quote">Il 11/nov/2014 18:05 <<a href="mailto:a.furieri@lqt.it">a.furieri@lqt.it</a>> ha scritto:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Noto che spesso si parla di formati di scambio e di lavoro come se<br>
fossero la medesima cosa e come se fossero due concetti piu' o<br>
meno equivalenti e liberamente interscambiabili.<br>
<br>
Dissento fortemente da questa interpretazione perche' mi sembra<br>
un po' troppo semplicistica e quindi inevitabilmente fuorviante.<br>
formati di scambio e formati di lavoro rispondono a due esigenze<br>
funzionali ampiamente diversificate e spesso chiaramente antitetiche:<br>
- un buon formato di scambio spesso e' un pessimo formato di lavoro.<br>
- un buon formato di lavoro spesso non e' affatto un formato di scambio.<br>
<br>
Provo a spiegare perche' questo accade inevitabilmente; purtroppo<br>
non potro' fare a meno di approfondire alcuni dettagli tecnici.<br>
<br>
<br>
supporto per gli accessi random<br>
------------------------------<u></u>--<br>
cioe' capacita' di leggere selettivamente solo determinate porzioni del<br>
dataset (quanto piu' piccole possibile) e seguendo un ordine assolutamente<br>
casuale e non prestabilito a priori.<br>
<br>
giusto un paio di esempi ultra-familiari:<br>
- un documento di testo me lo devo sempre necessariamente leggere<br>
tutto da cima a fondo: se anche mi interessa un singolo paragrafo<br>
oppure una singola riga comunque prima devo caricare in memoria tutto<br>
il documento per intero, e solo in sequito posso provare a cercare<br>
quel determinato paragrafo o quella specifica riga.<br>
anche nel migliore dei casi mi dovro' comunque leggere il documento<br>
almeno fino a quando non trovo la frase incriminata (e potrebbe anche<br>
trovarsi proprio in fondo in fondo).<br>
- un'imagine JPEG la devo necessariamente leggere e decomprimere in una<br>
singola passata. se anche mi interessa estrapolare solo un microscopico<br>
tassello (<a href="http://p.es" target="_blank">p.es</a>. il volto di mia cugina da una foto di gruppo) non posso<br>
mai fare a meno di occupare inutilmente un sacco di RAM per decomprimere<br>
l'intera immagine in via preliminare.<br>
<br>
- invece un file DBF e pure uno SHP (almeno in teoria) mi consentono<br>
di estrarre in modo molto selettivo solo quelle quattro o cinque<br>
features che mi interessano ignorando tutte le altre.<br>
anche quando lo SHP nel suo complesso contiene magari svariati<br>
milioni di features; basta solo disporre di appropriati indici di<br>
ricerca, sia spaziali che non spaziali.<br>
non e' detto che poi questa capacita' sia effettivamente implementata<br>
dalle mille applicazioni che supportano DBF / SHP: ma almeno in pura<br>
teoria il formato consente questa possibilita'.<br>
- anche un'immagine TIFF strutturata per scanlines o per tiles mi<br>
consente di estrarre una singola tile ignorando tutte le altre,<br>
e quindi si presta (teoricamente) bene per estrapolare piccoli<br>
dettagli dall'immagine complessiva (sempre ammesso che sappia dove<br>
andare a cercarli).<br>
<br>
corollario: un formato che non supporta intrinsecamente nessun tipo<br>
di accesso random puo' essere un ottimo formato di scambio.<br>
ma in pratica sara' un formato di lavoro assolutamente insoddisfacente<br>
perche' impone dei carichi computazionali ed un consumo di risorse<br>
del tutto indesiderabili e non ottimizzabili visto che sara' materialmente<br>
impossibile implementare una qualsivoglia strategia di indexing selettivo.<br>
<br>
in soldoni: non solo e' lento, e' pure sconsideratamente sciupone.<br>
puo' ancora andar bene nei contesti applicativi piu' semplici e<br>
limitati, ma mostrera' sicuramente la corda con l'aumentare dei<br>
carichi e dei volumi di lavoro, come inevitabilmente accade nei<br>
contesti professionali o istituzionali.<br>
<br>
<br>
supporto per il c.d. "in place replacement"<br>
------------------------------<u></u>-------------<br>
cioe' capacita' di modificare/correggere una informazione gia' presente<br>
sostituendo direttamente il valore pre-esistente (cioe' effettuando<br>
una semplice sovra-scrittura).<br>
<br>
sempre continuando con i soliti esempi ultra-familiari:<br>
- qualsiasi editor di testo / word processor non ha mai nessuna<br>
capacita' di in-place-replacement; e cosi' dicasi anche per<br>
tutti i fogli di calcolo.<br>
se anche mi limito a correggere una singola virgola l'intero<br>
documento verra' comunque sovra-scritto per intero da capo a fondo;<br>
se sfortunatamenta va via la corrente a meta' rischio seriamente<br>
di perdere sia la veccha versione che la nuova e di trovarmi alla<br>
fine con un file irrimediabilmente corrotto e quindi inutilizzabile.<br>
in genere il sw applicativo e' abbastanza furbo da salvarsi uno<br>
swap-file temporaneo in via precauzionale; ma non e' qualcosa<br>
di direttamente supportato dal formato in quanto tale, e'<br>
piuttosto un'indispensabile assicurazione anti-infortuni (nonche'<br>
un'ulteriore complicazione indesiderata) imposta dai limiti<br>
intrinseci del formato.<br>
<br>
- un file DBF (sempre in teoria) consente invece di modificare il<br>
valore di una singola cella in modo preciso e selettivo, e senza<br>
alcun bisogno di toccare in alcun modo le altre celle.<br>
temo sinceramente che ben pochi applicativi sfruttino questa<br>
capacita' intrinseca; sono quasi certo che sia Excel che Calc<br>
lavorano esattamente all'inverso, cioe' per sostituzione totale<br>
dell'intero archivio piuttosto che per correzione di singole celle.<br>
ma ovviamente e' un problema delle applicazioni, non e' certo<br>
un limite imposto dal formato in quanto tale.<br>
<br>
corollario: un formato che non supporti in alcun modo il c.d.<br>
"in place replacement" puo' ben essere un ottimo formato di<br>
scambio. ma sara' inevitabilmente un pessimo formato di lavoro<br>
(tranne che per chi lavora in pura lettura facendo solo ed<br>
esclusivamente attivita' di mera consultazione, come accade<br>
<a href="http://p.es" target="_blank">p.es</a>. nel caso delle pagine HTML).<br>
<br>
<br>
supporto transazionale<br>
----------------------<br>
quando si aggiorna/modifica/elimina/<u></u>inserisce una qualsiasi informazione<br>
sul file-system ci sono sempre mille pericoli insidiosi in agguato.<br>
una interruzione di alimentazione, un guasto hardware, un crash improvviso<br>
del programma possono mandare tutto in malora con risultati assolutamente<br>
disastrosi.<br>
nel caso migliore posso semplicemente perdere le ultime modifiche; nel<br>
caso piu' catastrofico posso addirittura ritrovarmi con un dataset<br>
pesantemente corrotto e del tutto inutilizzabile nel suo complesso.<br>
peggio ancora; posso ritrovarmi con informazioni incoerenti e mutuamente<br>
contraddittorie. magari il problema potrebbe emergere solo a distanza<br>
di tempo, quando ovviamente sara' troppo tardi per rimediare e quando<br>
verosimilmente il problema si sara' allargato a macchia d'olio con<br>
conseguenze nefaste e devastanti.<br>
<br>
il problema e' del tutto irrilevante per un formato di mero scambio<br>
dati; se l'import non va a buon fine posso pur sempre ricominciare<br>
pazientemente da capo. se fallisce durante la fase di export posso<br>
comunque ritentare in un secondo momento.<br>
ma per un formato di lavoro qualsiasi incidente durante un'operazione<br>
di scrittura e' sempre potenzialmente catastrofico, perche' rischia<br>
di friggere tutto quanto in un sol colpo.<br>
<br>
torniamo ad un esempio concreto basato su file DBF; il formato mi<br>
consente di inserire nuove righe senza toccare quelle gia' esistenti;<br>
basta semplicemente aggiungerle il coda al file.<br>
pero' occorre anche aggiornare contemporaneamente le informazioni<br>
presenti nel primo blocco di testa (header); le due azioni devono<br>
necessariamente avvenire in sincronia perfetta, e sono ovviamente<br>
del tutto indipendenti l'una dall'altra.<br>
qualsiasi incidente produce direttamente un DBF corrotto.<br>
ancora peggio nel caso di uno SHP, perche' in quest'ultimo caso<br>
presumibilmente devo anche aggiornare i due files SHP e SHX inserendovi<br>
le nuove righe e modificando i corrispettivi headers.<br>
se una qualsiasi di queste operazioni fallisce mi trovero' alla fine<br>
con uno Shapefile malfunzionante.<br>
<br>
peccato solo che DBF e SHP non offrano assolutamente nulla per<br>
tutelarsi in caso di malaugurati incidenti; si affidano fiduciosamente<br>
alla protezione miracolosa di qualche Nume benevolente.<br>
ma i miracoli notoriamente sono piu' l'eccezione che la regola ...<br>
ogni tanto qualcuno finisce inevitabilmente con lo scottarsi.<br>
<br>
corollario: usare un formato di lavoro di tipo non transazionale<br>
non e' per nulla affidabile, e quindi e' decisamente pericoloso<br>
e fortemente sconsigliabile.<br>
e' un approccio che va sicuramente bene per gli hobbisti (absit<br>
iniuria), ma non puo' venire preso in nessuna seria considerazione<br>
in un contesto professionale o istituzionale.<br>
<br>
<br>
una valutazione complessiva<br>
---------------------------<br>
- un buon formato di interscambio non ha obblighi di efficienza.<br>
e' molto piu' importante che sia facilmente interoperabile, che<br>
sia definito in modo chiaro, ben documentato e rigoroso, che non<br>
presenti nessun vincolo dipendente da specifiche piattaforme o<br>
da specifici componenti, che sia assolutamente stabile nel tempo.<br>
soprattutto e' decisivo che sia generosamente supportato dal<br>
numero piu' ampio possibile di componenti ed applicazioni, in modo<br>
tale da facilitarne un'adozione pressoche' universale in tutti i<br>
contesti possibili ed immaginabili, anche in quelli meno ovvi.<br>
<br>
- invece un formato di lavoro mette sempre necessariamente la<br>
robustezza, l'efficienza e l'affidabilita' al primissimo posto.<br>
se introdurre una nuova funzionalita' o essere piu' efficienti<br>
o anche semplicemente rimuovere un critical bug implica una qualche<br>
rottura della interoperabilita' con le versioni precedenti si<br>
cerchera' possibilmente di mitigare il problema offrendo qualche<br>
tool accessorio che faciliti le conversioni in modo quanto piu'<br>
possibile indolore, ma non per questo si rinuncera' a modificare<br>
il formato.<br>
<br>
e' fin troppo facile constatare che si tratta di due "Weltanschauung"<br>
nettamente diversificate e per molti versi antitetiche.<br>
in alcuni casi particolarmente felici sara' anche possible ottenere<br>
qualche compromesso a meta' strada che metta d'accordo capra e cavoli,<br>
ma sara' pur sempre una mezza-soluzione che lascera' inevitabilmente<br>
qualche aspetto piu' o meno critico risolto solo in via approssimativa.<br>
<br>
magari come nel caso dello Shapefile, che proprio a causa degli infiniti<br>
difetti che si porta dietro fin dalla nascita finisce per essere un<br>
"ragionevole compromesso" che riesce a conciliare (male, ma meglio di<br>
niente) tantissime esigenze contrastanti.<br>
quasi tutti lo odiano e ne parlano male, ma praticamente nessuno riesce<br>
mai a farne del tutto a meno. ;-)<br>
<br>
viceversa SpatiaLite funziona esattamente all'opposto di Shapefile;<br>
mette sempre al primo posto efficienza e funzionalita', sacrificando<br>
eventualmente la compatibilita' universale quando e' indispensabile.<br>
a dispetto di tutto questo, riesce comunque a conservare una "ragionevole"<br>
interoperabilita', certamente imperfetta ma mediamente soddisfacente.<br>
almeno fino a quando su entrambi i versanti si usa la medesima versione<br>
della libreria la compatibilita' e' sempre pienamente assicurata.<br>
se le versioni della libreria sono diverse allora e' possibile (non e'<br>
sempre detto) che sia richiesta qualche operazione di conversione<br>
(come e' accaduto <a href="http://p.es" target="_blank">p.es</a>. nel passaggio dalla 3.x alla 4.x).<br>
<br>
del resto SpatiaLite non ha mai preteso di presentarsi come un formato<br>
di scambio universale; io per primo ho sempro vivacemente polemizzato<br>
con chi intendeva presentare SpatiaLite principalmente come un vero e<br>
proprio formato di scambio.<br>
e' del tutto ovvio che non potra' mai esserlo, perche' e' in primis uno<br>
Spatial DBMS che segue la sua naturale spirale di sviluppo evolutivo;<br>
la capacita' di essere *anche* facilmente interscambiabile tra<br>
piattoforme disomogenee e' sicuramente un bonus molto interessante,<br>
ma non e' certamente la prima ragione d'essere del progetto.<br>
<br>
il GeoPackage "Candidate" si che avrebbe avuto effettivamente tutte<br>
le carte in regola per riuscire a diventare un formato di scambio<br>
universale vero e proprio oltre ad essere uno Spatial DBMS a<br>
tutti gli effetti.<br>
... ma se persino l'US Army non e' riuscito a portare a casa<br>
l'obbiettivo qualcosa vorra' pur dire; evidentemente ci sono<br>
troppe forze che spingono in tutt'altre direzioni :-D<br>
<br>
<br>
-----------------<br>
<br>
a questo punto tiriamo velocemente le somme:<br>
<br>
- GML, KML, GeoJSON, CSV (e qualsiasi altro formato testuale)<br>
non supportano gli accessi random, non supportano l'in-place<br>
replacement, non offrono nessuna sicurezza transazionale,<br>
non si sposano affatto bene con l'indexing.<br>
possono essere certamente ottimi formati di scambio (e di<br>
fatto lo sono). ma sono sicuramente pessimi formati di lavoro.<br>
<br>
- DBF / Shapefile<br>
supportano gli accessi random e pure l'in-place replaceemnt<br>
(almeno a spanne; entrare nel dettaglio sarebbe troppo noioso)<br>
pero' non offrono nessuna tutela transazionale: qualsiasi<br>
incidente e' potenzialmente catastrofico, come del resto<br>
conferma la pratica esperienza sul campo.<br>
praticamente tutto dipende dalla specifica implementazione;<br>
il formato di per se non garantisce nulla, apre solo delle<br>
interessanti potenzialita' che potrebbero venire sfruttate<br>
in modo intelligente come anche no ...<br>
in ultima analisi tutto dipende esclusivamente dall'applicazione;<br>
non e' una base di partenza ottimale per sperare in una reale<br>
interoperabilita' universale (che in effetti, non sempre e'<br>
assicurata come si potrebbe sperare).<br>
insomma, e' un mediocre formato di lavoro (sicuramente buono<br>
per i palati meno raffinati e per le esigenze meno complesse)<br>
ed e' anche un ragionevole formato di scambio.<br>
presenta pecche evidenti su entrambi i versanti, ma ben si sa<br>
che l'"aurea mediocritas" alla fine paga sempre.<br>
e' decisamente semplice ed e' molto ben radicato, quindi e'<br>
sicuramente immortale :-D<br>
<br>
infine abbiamo tutta la genia dei DBMS / Spatial DBMS; questi si<br>
che offrono realmente di tutto (ed anche molto di piu').<br>
supportano gli accessi random, supportano l'in-place-replacement,<br>
supportano le transazioni, supportano pure l'indexing sia per<br>
i dati generici che per quelli specializzati di tipo spatial.<br>
ma supportano pure i constraints, i triggers, i vincoli relazionali<br>
ed un sacco di altra roba super-fighissima.<br>
<br>
soprattutto supportano intrinsecamente quel meraviglioso ed ultra<br>
potente linguaggio universale per la definizione e la manipolazione<br>
dei dati che e' SQL<br>
un DBMS mi consente tranquillamente di progettare, gestire e consultare<br>
una banca dati corposa e molto complessa anche in totale assenza di<br>
qualsiasi altro sw applicativo piu' specializzato.<br>
usare una qualche app di supporto mirato e' quasi sempre consigliabile<br>
perche' facilita di gran lunga il lavoro, ma non e' mai strettamente<br>
indispensabile.<br>
<br>
last but not least: i DBMS sono pure mostruosamente efficienti e<br>
dannatamente robusti, perche' hanno alle spalle una solida teoria<br>
matematica supportata da una lunghissima esperienza operativa sul<br>
campo consolidatasi in tutte le condizioni d'uso concepibili, anche<br>
e soprattutto in quelle piu' severe ed impegnative.<br>
da circa quarant'anni a questa parte i DBMS dominano incontrastati<br>
in tutti i settori dell'Information Technology quando entrano in<br>
gioco moli di dati impegnative.<br>
solo all'interno del mondo GIS i DBMS sono ancora considerati con<br>
palese sospetto e con mal celata diffidenza.<br>
<br>
colpa del GIS o colpa dei DBMS ?<br>
ai posteri l'ardua sentenza :-D<br>
<br>
ciao Sandro<br>
______________________________<u></u>_________________<br>
<a href="mailto:Gfoss@lists.gfoss.it" target="_blank">Gfoss@lists.gfoss.it</a><br>
<a href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss" target="_blank">http://lists.gfoss.it/cgi-bin/<u></u>mailman/listinfo/gfoss</a><br>
Questa e' una lista di discussione pubblica aperta a tutti.<br>
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.<br>
666+40 iscritti al 5.6.2014</blockquote></div>