[Gfoss] Creare un Server GIS

Ciao Giuseppe,
se interpreto bene la tua domanda, più che un server GIS nel senso stretto ,
visto che devi permettere ad altri di compilare ed aggiornare i dati
geografici, ti serve un geoDB, come per esempio postGIS.
In questo modo può creare utenti e permessi di accesso (schemas) per la
condivisione attiva dei dati.

... non so se sono stato abbastanza chiaro !
Cari saluti
Nino

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Creare-un-Server-GIS-tp7592857p7592858.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

... beh, certo studiare i DB per averne più dimestichezza ti conviene !
In ogni caso, io per cose di una certa rilevanza e appunto quando voglio
lavorare in condivisione con altri, preferisco usare postGIS piuttosto che
SQLite per una questione di prestazioni.

In ogni caso, anche se io non lo uso, puoi condividere il tuo DB SQLite sul
tuo PC, dandone accesso remoto agli altri via HTTP usando un admin-tool come
questo:
https://code.google.com/p/phpliteadmin/
... e chiaro, ci devi smanettare un pò per imparare, ma non è tanto
difficile !

Cari saluti
Nino

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Creare-un-Server-GIS-tp7592857p7592860.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

On Wed, 24 Jun 2015 02:06:39 -0700 (MST), nformica wrote:

... beh, certo studiare i DB per averne più dimestichezza ti conviene !
In ogni caso, io per cose di una certa rilevanza e appunto quando voglio
lavorare in condivisione con altri, preferisco usare postGIS piuttosto che
SQLite per una questione di prestazioni.

Rino,

consentimi di dissentire :slight_smile:

fare riferimento alle prestazioni in questo contesto e' del tutto fuorviante;
non aiuta affato a capire meglio fornendo informazioni precise ed accurate,
serve solo ad aumentare ulteriormente la confusione.

nell'accezione piu' comune prestazioni intende efficienza e performances,
e quindi in ultima analisi e' un sinonimo di velocita' di elaborazione.
comparare oggettivamente le performances di due diversi DBMS e' sempre un
problema molto complesso e per nulla semplice, perche' dipende dalla specifica
natura del problema, da come sono scritte le query SQL, da come sono strutturati
fisicamente i dati, da quanto e' ottimizzata la configurazione di sistema
... e da un sacco di altri fattori variabili non certo facili da controllare
in modo rigorosamente oggettivo.
insomma, il rischio sempre in agguato e' quello di finire con la piu'
classica delle inutili comparazioni tra mele e pere.

quello che posso assicurarti e' che in giro per il mondo c'e un discreto
numero di power users che preferisce utilizzare proprio SQLite/SpatiaLite
piuttosto che PostgresSQL/PostGIS quando serve fare Spatial Processing
su grandi moli di dati complessi ... o sono pazzi, oppure significa che
le prestazioni sono almeno grossolamente comparabili, e forse in qualche
caso persino migliori.

quello che invece andrebbe sempre chiarito in modo cristallino e' che
si tratta di due DBMS basati su scelte architetturali completamente
divergenti e radicalmente alternative.

PostgreSQL/PostGIS e' interamente basato su un'architettura client/server;
quindi e' inevitabilmente pesante e complesso ma e' progettato apposta
per reggere un numero teoricamente illimitato di connessioni che operano
simultaneamente in stretto parallelismo.

SQLite/SpatiaLite e' l'esatto contrario; e' semplice e molto leggero,
ma il prezzo da pagare e' l'assoluta rinuncia a qualsiasi tipo di
accesso concorrente da parte di piu' utenti in parallelo.
piu' precisamente: funziona benissimo anche con tantissime connessioni
in parallelo ma solo se si tratta di connessioni in sola lettura.
quando oltre alla lettura dei dati e' richiesta anche la possibilita'
di inserire o aggiornare allora deve essere ben chiaro che SQLite
puo' supportare un'unica configurazioe: quella rigorosamnete mono-utente.

tirando le somme: alla luce delle consideraioni precedenti non e'
affatto difficle stabilire i criteri di scelta del DBMS "ottimale":

* serve assolutamente supportare una configurazione multi-utente ?
   se si, allora esiste un'unica opzione tecnicamente sensata:
   PostgreSQL/PostGIS

* basta una semplice configurazione mono-utente ?
   se si, allora la scelta preferibile e' sempre SQLite/SpatiaLite,
   perche' ha una soglia di complessita' molto minore e non fa
   rimpiangere nulla in termini di potenza ed efficienza.

* serve una configurazione multi-utente ma siamo assolutamente sicuri
   che verranno effettuate esclusivamente operazioni di sola lettura ?
   qua andrebbe sempre valutato oculatamente caso per caso facendo
   qualche test pratico sul campo.
   molto spesso si scoprira' che SQLite/SpatiaLite puo' essere la
   soluzione ottimale, ma non e' detto che lo sia sempre in tutti
   i contesti possibili e immaginabili.

In ogni caso, anche se io non lo uso, puoi condividere il tuo DB SQLite sul
tuo PC, dandone accesso remoto agli altri via HTTP usando un admin-tool come
questo:
https://code.google.com/p/phpliteadmin/
... e chiaro, ci devi smanettare un pò per imparare, ma non è tanto
difficile !

personalmente sconsiglio caldamente l'uso di strumenti di questo tipo,
per un motivo banalmente semplice.
puoi anche sforzarti di montare una cabina ed un cassone su una
motocicletta cercando di farla assomigliare ad un camioncino;
magari puoi anche risucire a saldarci assieme un paio di ruote
extra, ma alla fine otterrai inevitabilmente un pessimo camioncino.
ma in compenso avrai sacrificato tutte le doti di agilita', di
scatto e di scioltezza che aveva inizialmente la motocicletta.
... non parrebbe un affare molto vantaggioso :wink:

ciao Sandro

Ciao Sandro,
non credo che ci sia dissenso tra quanto ho scritto e quello che
dettagliatamente e diligentemente hai risposto tu, ... almeno secondo me !
:wink:
Sono pienamente d'accordo con te che SQLite e postGIS sono DBMS
strutturalmente diversi e con fini diversi, non comparabili.
L'unica cosa è che ammetto di aver risposto a Giuseppe, semplificando molto
e parlando genericamente di prestazioni diverse.
Ma la mia intenzione, in base a quelle che erano le richieste di Giuseppe
(la multi-utenza), era quello di consigliargli la stessa cosa, che hai
meglio espresso tu nel sequente modo:

serve assolutamente supportare una configurazione multi-utente ?
se si, allora esiste un'unica opzione tecnicamente sensata:
PostgreSQL/PostGIS

Se mi sono espresso male e ho ingenerato confusione a Giuseppe, chiedo
scusa.
L'importante e con il tuo post "chiarificatore", possa avere le idee più
chiare.

Quanto all'uso di "phpliteadmin" per condividere l'accesso a SQLite, è
chiaro che questo non è da intendersi in un strumento che trasforma SQLite
in qualcosa che non è nella sua natura (... come dici tu da motocicletta a
camioncino).
Tuttavia ritengo che usato con le dovute cautele e per una condivisione
"semplice", può essere una soluzione di comodo per continuare a usare
SQLite. Poi chiaramente ognuno è libero di fare come preferisce.

cari saluti
Nino

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Creare-un-Server-GIS-tp7592857p7592865.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.