[Gfoss] consigli su stoccaggio dati‏

Andrea Peri aperi2007 a gmail.com
Ven 11 Maggio 2012 11:19:29 CEST


>Ciao a tutti,chiederei consigli e opinioni riguardanti sistemi e sw da utilizzare per l'archiviazione, catalogazione e condivisione dati geografici e non ovviamente di tipo opensource.Sembra facile, ma non lo è, perchè chi ha accesso a questa condivisione dati ha le proprie abitudini e pretese in quanto a modalità di organizzazione, accesso, usabilità, ecc...Fissiamo dei punti:i dati sono digitali di ogni tipo, dai documenti doc, xls, ppt, pdf, jpg a quelli di tipo geografici localizzati e non di tipo raster e geografici vettoriali per lo più di tipo shp o ascii.I dati al momento da 'organizzare sono qualcosa come 1 Tb , con una velocità di espansione non elevatissima, diciamo circa 100 Gb anno??boh?forse è quasi troppo...
>Nel gruppo di lavoro c' è chi mi chiede una sorta di directory condivisa, con una organizzazione precisa delle sottodirectory, un modo insomma perchè tutti abbastanza 'amichevolmente' abbiano accesso alle varie directory....Questo secondo me crea il CAOS...quanto meno a lungo termine, senza considerare che dopo un pò di tempo ci si dimentica cosa viene stoccato chi l'ha stoccato,creando duplicati e versioni varie. A questo si aggiungono ovvi problemi di ricerca file.
>Sarebbe auspicabile un sistema catalogato, quindi organizzazione dati che passa da una metadatazione....ma questa è pratica faticosa e poco digeribile ai più...
>Cosa mi consigliate? Impongo un sistema organizzato? o organizzo un file system condiviso...che sarà caotico in men che non si dica?
>Il gruppo di lavoro ha già utilizzato geonetwork, che a mio modesto parere non è male, ma non è neanche il top per l'utente della strada...
>Aspetto commenti e suggerimenti...grazie, a presto...
>Eugenio

AFAIK

non esiste alternativa alle cartelle condivise mediante samba.

Io organizzerei due distinte aree di lavoro.
Una aperta al caos, in cui ogni utente ha la propria zona di lavoro e puo'
fare e disfare come meglio crede.
Si sa' benissimo che cosi' il rischio (e' praticamente sicuro) è che in
poco tempo ti ci ritrovi con copie su copie dei medesimi dati,
o, peggio ancora, con i medesimi dati sempre modificati in maniera
differente tra i vari utenti.

Questa purtroppo e' una cosa irrisolvibile, e quindi non va combattuta , ma
piuttosto va circoscritta.
Per questo farei due aree, appunto, una dove ogni utente fa come gli pare,
e una altra, in cui scrivi solo te e in cui metti cio' che ' definitivo.
In maniera che sulle ultime e definitive versioni hai anche una
metainformazione coerente e allineata.

Infatti il problema peggiore, e' quando hai una metainformazione che dice
che nell'archivio ci sono 4 campi con determinati domini, poi apri
l'archivio e scopri invece 6 campi e domini differenti.
Senza sapere bene perche' e' cosi', come mai e quando e' successo.

Poi , magari la spiegazione e' semplice, magari l'utente ha aggiunto un
campo perche' gli serviva per una ualche elaborazione sua, e magari si e'
accorto che i domini erano troppo pochi.
Per cui fa' le sue brave modifiche , ma "dimentica" di trascriverle nella
MTD e quindi si perde quasi subito traccia della cosa.

Invece se la zona con gli archivi "ufficiali" e' gestita da un apposito
responsabile e solo lui ci puo' scrivere, questo lo responsabilizza e
garantisce che qualciasi cosa ci va a finire, almeno una persona sa' da
dove quella roba proviene.

Ovviamente deve essere una persona responsabile, se invece e' un
informatico "bove" spallato e scocciato che copia quello che gli passano
senza chiedersi se sono vettori o cavoli, allora non serve a niente avere
una area di dati ufficiali a sola lettura.

Per il resto, la scelta delle cartelle condivise via samba/cifs e'
praticamente obbligata.
E' l'unica soluzione che ti permette di organizzare i dati in maniera
gerarchica con percorsi che portano fino al dato da usare, e permette di
impiegarli in sistema GIS per elaborazioni spaziali anche complesse.

Anche in questo caso pero' il lavoro del cosidetto "responsabile della area
dei dati ufficiali" e' comunque importante.
Perch'e deve mantenere gli indici spaziali sempre aggiornati , per
garantire il massimo delle performance agli utenti, e
ancora piu' importante.
DEVE cercare di mantenere i percorsi invariati.

Mi spiego meglio:

Deve studiare una gerarchia di cartelle che si presti ad accogliere anche
dati futuri, non solo il presente, altrimenti sara' sempre un rimodulare le
cartelle, con conseguente cambio dei perocrsi e quindi progetti qgis che
oggi si aprono e domani non si aprono piu'.

Questo non deve succedere , almeno non deve succedere troppo spesso,
altirmenti chi usa i dati si trova in difficolta' e lavora male.

Infine nel progettare queste cartelle tieni presente che esiste un limite
ai percorsi.

Ad esempio noi cerchiamo dinon scendere mai sotto i 128 caratteri nel
percorso delle cartelle perche' altrimenti arcview3 non legge piu' i dati.
QGIS va piu' lontano, ma su windows non credo che superi i 256 caratteri,
per cui non vi e' comunque da scialare.

Una alternativa potrebbe essere l'impiego del DBMS, ma lo ritengo perdente
in questo contesto.
Il DBMS non consetne la gerarchizzazione dei contesti e costringe a
appiattire tutto al medesimo livello questo rende complicato l'impiego
degli archivi quando cominciano a essere migliaia.

Noi, ad esempio, abbiamo migliaia di archivi di vario genere, e ognuno di
essi ha almeno un utente per cui esso e' rilevante.
Senza contare gli utenti che ogni si affacciano ai nostri sistemi e cercano
in maniera piu' o meno cosciente i dati che servono per il loro lavoro.
Una strutturazione degli archivi di tipo piatto non li aiuterebbe
certamente nel loro lavoro.
Anche per questo la struttura gerarchica ottenibile con il filesystem e'
imbattibile.

Un altro aspetto importante e' il contesto tecnologico in cui ti devi
muovere, ovvero che tipo di archivi prevedono i tuoi utenti:

Se puoi spingerti oltre, io cercherei di abbinare l'impiego del filesystem
con il formato spatialite (e prossimamente rasterlite),
perche' cosi' hai la combinazione di una struttura gerarchica a filesystem,
con la potenza interrogativa di un database .
Collocando in ogni cartella della tua struttura gerarchica di cartelle uno
o piu' file spatialite.

Noi stiamo adottando una tale strategia, e per ora i primi risultati sono
incoraggianti.
Chiaramente e' un approccio ibrido, ma a mio parere porta dei vantaggi
significativi.

L'unico vero svantaggio e' che attualmente spatialite' e visibile solo da
QGIS, e quesot costringe a tenere a disposizione anche gli shapefile, che
pero' con tutti i loro limiti finiscono per condizionare anche lo
spatialite.
Intendo dire che cercando di tenere i medesimi dati nei due formati finisci
per castrarti abbastanza rispetto alle possibilita' dello spatialite.


Infine nella cartella dove ci dovrebbe stare l'archivio ci metti 4 cartelle
noi le chiamiamo cosi':
shp
splite
documenti
tabelle-varie

nella prima lo (o gli ) shapefile,

nella seconda il file splite che contiene tutti i medesimi dati della
cartella shapefile,
nella terza tutti i documenti correlati , comprese le relazioni-tecniche
(importanti per descrivere la qualita' del dato)
nella quarta eventuali dati non strettamente geografici, ma necessari per
supportare la componente alfanumerica, ad esmepio fogli excel, file dbf, o
altri formati.


-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20120511/7bac4b49/attachment.html>


Maggiori informazioni sulla lista Gfoss