Creare un Server GIS
Locked
 
|
Salve a tutti,
sto lavorando su un progetto con il Gis dove sono presenti dati salvati su un database, però vorrei che sullo stesso ci lavorassero altre persone, soprattutto per quanto riguarda la compilazione del database. E' possibile creare un server dove poter condividere gli stessi file su cui lavorare? Grazie in anticipo, Giuseppe |
|
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 |
|
|
Ciao Nino, grazie per aver risposto e chiedo scusa per la domanda piuttosto confusionaria. Cercherò di spiegarmi meglio. Io sono già in possesso di un database (SQLite) che carico sul gis ogni volta che lavoro... quindi vorrei che il db principale rimanesse sul mio pc, ma che venisse compilato da altri. Leggevo che si possono allineare i db, ma in che modo? PS: ho le idee molto confuse, mi sto studiando i database :) Il giorno 24 giugno 2015 08:41, nformica [via Gfoss -- Geographic Free and Open Source Software - Italian mailing list] <[hidden email]> ha scritto: Ciao Giuseppe, |
|
|
... 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 |
|
|
Gli darò un'occhiata e terrò in considerazione postGIS. Grazie mille Nino. Un saluto, Giuseppe Il giorno 24 giugno 2015 11:06, nformica [via Gfoss -- Geographic Free and Open Source Software - Italian mailing list] <[hidden email]> ha scritto: ... beh, certo studiare i DB per averne più dimestichezza ti conviene ! |
|
|
In reply to this post by nformica
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 :-) 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 ;-) ciao Sandro _______________________________________________ [hidden email] 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. 750 iscritti al 18.3.2015 |
|
|
This post was updated on .
Ciao Sandro,
non credo che ci sia dissenso tra quanto ho scritto e quello che dettagliatamente e diligentemente hai risposto tu, ... almeno secondo me ! ;) Sono pienamente d'accordo con te che SQLite e postGIS sono DBMS strutturalmente diversi e con fini diversi, non comparabili. L'unica cosa , 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 è che con il tuo post "chiarificatore", lui 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 |
|
|
Vi ringrazio per aver risposto, sicuramente Sandro è stato più chiaro, ma sicuramente ho capito che devo andare a studiare i database molto più approfonditamente di quanto già sappia. Purtroppo se non si applica con la pratica quello che studi, difficilmente si riesce a capire subito. Sto guardando dei corsi sul sito html, credo siano fatti molto bene. Il giorno 24 giugno 2015 17:47, nformica [via Gfoss -- Geographic Free and Open Source Software - Italian mailing list] <[hidden email]> ha scritto: Ciao Sandro, |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |