Ciao a tutti,
ho notato un piccolo problema con l'accoppiata QGIS-Spatialite. Se creo un nuovo layer geometrico spatialite e successivamente aggiungo dei campi utilizzando:
ALTER TABLE xxx ADD column yyy TEXT la nuova colonna non viene vista da QGIS. Ho provato facendo un vacuum del DB, riavviando QGIS ma nisba. Qualcuno conferma il problema o è una cosa mia locale ?
grazie mille Luca _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
Aggiungo che ho notato che la tavola vectro_layers_field_infos in effetti non è stata aggiornata con i nuovi campi. Devo farlo manualmente ? Luca Il giorno 17 luglio 2014 14:14, Luca Lanteri <[hidden email]> ha scritto:
_______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
Il giorno 17 luglio 2014 14:17, Luca Lanteri <[hidden email]> ha scritto:
_______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
Il 17/07/2014 14:29, Luca Lanteri ha scritto:
> probabilmente legato a questo: > > http://hub.qgis.org/issues/8923 che dice una triste verita': il supporto a SpatiLite in QGIS ha bisogno di cure ed affetto; la situazione si e' venuta complicando, fra versioni diverse, vari modi di accedere al DB, duplicazione di plugins, ecc., e nessuno ha affrontato il problema alla radice, mettendo a pulito il tutto. volontari? saluti. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
In reply to this post by Luca Lanteri-3
On Thu, 17 Jul 2014 14:14:13 +0200, Luca Lanteri wrote:
> Ciao a tutti, > > ho notato un piccolo problema con l'accoppiata QGIS-Spatialite. > Se creo un nuovo layer geometrico spatialite e successivamente > aggiungo dei campi utilizzando: > > ALTER TABLE xxx ADD column yyy TEXT > > la nuova colonna non viene vista da QGIS. Ho provato facendo un > vacuum > del DB, riavviando QGIS ma nisba. > Qualcuno conferma il problema o è una cosa mia locale ? > Ciao Luca, il dataprovider di QGIS impone l'obbligo di comunicare in anticipo svariate informazioni relative al layer al momento in cui viene aperto / connesso: - il tipo delle geometrie - il relativo srid - il total extent - il numero complessivo delle features - l'esatto data-type per ciascuna colonna/attributo; ed e' proprio qua che casca l'asino :-) notoriamente SQLite e' stato volutamente progettato ed implementato in modo tale che tutte le colonne (eccetto quelle usate per le Primary Keys) siano assolutamente "typeless"; insomma il modello concettuale alla base di SQLite e quello supportato da QGIS qua fanno completamente a pugni, siamo esattamente agli antipodi. conseguenza pratica: -------------------- per riuscire a passare a QGIS tutte le informazioni di cui ha tassativamente bisogno per riuscire a gestire il layer, occorre fare un "full tablescan" esplorativo (lettura di tutta la tavola dalla prima fino all'ultima riga), in modo tale da valutare dinamicamente i contenuti effettivi. ovviamente un approccio cosi' semplicistico funziona bene solo per datasets "giocattolo" (max qualche migliaia di righe); se provi ad aprire un dataset "tosto" con milioni di righe il "full tablescan" preliminare porterebbe via sicuramente molti minuti ... forse addirittura decine di minuti ... e questo accadrebbe tutte le volte che QGIS prova a stabilire una connessione con quella tavola/layer. approccio piu' "smart": ----------------------- SpatiaLite gestisce semi-automaticamente tutta una serie di meta-tavole che contengono dei riepiloghi statistici; in questo modo basta salvare una volta per tutte il risultato del "full tablescan", e tutte le connessioni successive avverrano in modo istantaneo, anche per tavole contenenti milioni di righe. per rendere ancora piu' "smart" l'approccio, spatialite intercetta tramite triggers tutti gli eventi SQL che possono alterare il contenuto di una tavola (INSERT/UPDATE/DELETE); e quindi e' perfettamente in grado di sapere se/quando le statistiche "congelate" siano ancora valide oppure richiedano di essere aggiornate. QGIS comunque adotta sempre l'approccio OPTIMISTIC: se le statistiche esistono, usa comunque quel che trova fidandosi che sia sempre valido; se vuoi puoi comunque chiedere di aggiornare le statistiche non piu' valide; c'e' un apposito pulsantino nel dialog box di connessione dei layers. ------------------ e finalmente arriviamo all'ALTER TABLE ADD COLUMN a differenza di INSERT/UPDATE/DELETE, questo evento non e' intercettabile tramite triggers SQL. e quindi le statistiche continuano ad apparire valide, anche se di fatto non coprono la colonna aggiunta in seguito. eccoti spiegato perche' non riesci a vedere la nuova colonna che hai aggiunto: accade perche' non e' descritta nel riepilogo statistico, mentre il dataprovider di QGIS si basa solo sui riepiloghi per determinare quale sia la struttura della tavola layer. soluzione: ---------- p.es. puoi usare la versione test di spatialite_gui http://www.gaia-gis.it/gaia-sins/windows-bin-x86-test/spatialite_gui-1.8,0-devel-win.x86.7z dopo di che esegui questi due statements SQL: SELECT InvalidateLayerStatistics('mio_layer'); SELECT UpdateLayerStatistics('mio_layer'); se invece hai a disposizione solo versioni precedenti che non supportano InvalidateLayerStatistics(), puoi comunque aggirare l'ostacolo in quest'altro modo: UPDATE geometry_columns_statistics SET last_verified = NULL WHERE f_table_name = 'mio_layer'; SELECT UpdateLayerStatistics('mio_layer'); in entrambi i casi otterrai sempre il medesimo effetto; tutte le statistiche di supporto per quella tavola/layer verranno prima invalidate, e quindi successivamente aggiornate. e finalmente anche la colonna che hai aggiunto con la ALTER TABLE ADD COLUMN risultera' visibile anche a QGIS 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. 666+40 iscritti al 5.6.2014 |
Il 17/07/2014 14:50, [hidden email] ha scritto:
> p.es. puoi usare la versione test di spatialite_gui > http://www.gaia-gis.it/gaia-sins/windows-bin-x86-test/spatialite_gui-1.8,0-devel-win.x86.7z > > dopo di che esegui questi due statements SQL: > > SELECT InvalidateLayerStatistics('mio_layer'); > SELECT UpdateLayerStatistics('mio_layer'); > > se invece hai a disposizione solo versioni precedenti > che non supportano InvalidateLayerStatistics(), puoi > comunque aggirare l'ostacolo in quest'altro modo: > > UPDATE geometry_columns_statistics > SET last_verified = NULL > WHERE f_table_name = 'mio_layer'; > SELECT UpdateLayerStatistics('mio_layer'); Basta eseguire questo in una qualsiasi shell SQL, o c'e' bisogno di spatialite_gui? Saluti, e grazie. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
Grazie Alessandro e Paolo per le risposte sempre esustive. Io alla fine ho risolto con: UPDATE geometry_columns_statistics set last_verified = 0; SELECT UpdateLayerStatistics('geometry_table_name');
lanciato da una qualsiasi shell non so quanto corretto formalmente ma fuziona.
Il giorno 17 luglio 2014 14:55, Paolo Cavallini <[hidden email]> ha scritto: Il 17/07/2014 14:50, [hidden email] ha scritto: _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
In reply to this post by pcav
On Thu, 17 Jul 2014 14:55:37 +0200, Paolo Cavallini wrote:
> Basta eseguire questo in una qualsiasi shell SQL, o c'e' bisogno di > spatialite_gui? > come per tutte le funzioni SQL non importa minimamente quale tool di frontend si usa. l'unica cosa rilevante e' che sotto ci sia la libreria della versione giusta, cioe' libspatialite 4.2.0 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. 666+40 iscritti al 5.6.2014 |
In reply to this post by Luca Lanteri-3
On Thu, 17 Jul 2014 14:58:07 +0200, Luca Lanteri wrote:
> Grazie Alessandro e Paolo per le risposte sempre esustive. > > Io alla fine ho risolto con: > > UPDATE geometry_columns_statistics set last_verified = 0; > SELECT UpdateLayerStatistics('geometry_table_name'); > > lanciato da una qualsiasi shell > non so quanto corretto formalmente ma fuziona. > certo che funziona; sostanzialmente e' equivalente a questa che ti suggerivo per le vecchie versioni che non supportano la InvalidateLayerStatistics() UPDATE geometry_columns_statistics SET last_verified = NULL WHERE f_table_name = 'mio_layer'; SELECT UpdateLayerStatistics('mio_layer'); giusto per cercare il peluzzo nell'uovo; la tua versione usa zero invece di NULL (non e' formalmente pulistissimo, ma comunque funziona) la differenza sostanziale e' che la tua "ammazza" tutte le statistiche, non solo quella della tavola incriminata. se tu puta caso ti trovassi a lavorare p.es. con un DB da 5GB e passa, la differenza nel siccessivo tempo di ricalcolo delle statistiche potrebbe anche essere un'oretta abbondante :-D 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. 666+40 iscritti al 5.6.2014 |
ottimo, mi segno la query aggiornata! La mia versione l'avevo trovata in http://hub.qgis.org/issues/8923.
grazie mille Luca Il giorno 17 luglio 2014 15:43, <[hidden email]> ha scritto:
_______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
In reply to this post by pcav
Concordo a pieno con te!
Spatialite è per me una componente fondamentale di QGIS: in diversi casi l'utilizzo di SL per me è stato risolutivo e non ho trovato strumento migliore per affrontare determinati problemi. Recentemente, purtroppo, mi pare che però il supporto di SL in QGIS sia diminuito rispetto al passato. Come fai notare tu ci sono almeno 3-4 strumenti diversi per gestire i dati in SL ed ognuno fa bene alcune cose e peggio altre. DB Manager e Spatialite-gui in questo momento sono il mio riferimento. Sarebbe interessante riuscire a fondere insieme i due strumenti in un unico strumento potente e flessibile.
Ci sono poi diverse cose che richiedono una conoscenza sopra la media per utilizzare SL con profitto: il mio problema ne è un esempio lampante. Un problema tutto sommato banale mi ha portato via parecchio tempo. Per fortuna che in lista il supporto è sempre on-line !
;-) Detto questo come al solito servirebbero tempo e risorse (umane ed economiche) per lavorarci su ed entrambe scarseggiano parecchio. Sarebbe comunque interessante capire se sta ancora bollendo qualcosa in pentola e se c'è ancora interesse a lavorare su questi temi.
Qualcuno ha news in merito ? a presto Luca Il giorno 17 luglio 2014 14:32, Paolo Cavallini <[hidden email]> ha scritto: Il 17/07/2014 14:29, Luca Lanteri ha scritto: _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
Il 18/07/2014 11:56, Luca Lanteri ha scritto:
> Concordo a pieno con te! > Detto questo come al solito servirebbero tempo e risorse (umane ed economiche) per > lavorarci su ed entrambe scarseggiano parecchio. Sarebbe comunque interessante capire > se sta ancora bollendo qualcosa in pentola e se c'è ancora interesse a lavorare su > questi temi. > Qualcuno ha news in merito ? Non sono a conoscenza di investimenti significativi in questo senso, purtroppo. Saluti. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
.... a parte una serie di novità presenti nella 4.2
Luca, dai un'occhiata alla pagina https://www.gaia-gis.it/fossil/spatialite-tools/wiki?name=version+4.2.0 ai "new XML processing tools" (pensa alla possibilità di importare in DBMS un qualsiasi XML, es.: uno stesso progetto QGS, poterlo modificare e poi riesportare). oppure alla pagina https://www.gaia-gis.it/fossil/libspatialite/wiki?name=4.2.0+functions al "building/updating a MetaCatalog" (per derivare informazioni su tutti i valori assunti da qualsiasi attributo di una qualsiasi tabella del tuo DBMS). Un'altro strumento interessante è il Dataseltzer https://www.gaia-gis.it/fossil/dataseltzer/index e https://www.gaia-gis.it/fossil/dataseltzer/wiki?name=user_guide ciao, Maurizio Il 18/07/14, Paolo Cavallini<[hidden email]> ha scritto: > Il 18/07/2014 11:56, Luca Lanteri ha scritto: >> Concordo a pieno con te! > >> Detto questo come al solito servirebbero tempo e risorse (umane ed >> economiche) per >> lavorarci su ed entrambe scarseggiano parecchio. Sarebbe comunque >> interessante capire >> se sta ancora bollendo qualcosa in pentola e se c'è ancora interesse a >> lavorare su >> questi temi. >> Qualcuno ha news in merito ? > > Non sono a conoscenza di investimenti significativi in questo senso, > purtroppo. > Saluti. > -- > Paolo Cavallini - www.faunalia.eu > Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html > _______________________________________________ > [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. > 666+40 iscritti al 5.6.2014 [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. 666+40 iscritti al 5.6.2014 |
Grazie per le notizie positive su SL.
Per chiarire: la mia valutazione si riferiva all'integrazione QGIS-SL, non a questo secondo. Credo che una migliore integrazione sarebbe molto utile per tutti. Saluti. Il 18/07/2014 20:41, Maurizio Trevisani ha scritto: > .... a parte una serie di novità presenti nella 4.2 > > Luca, > dai un'occhiata alla pagina > https://www.gaia-gis.it/fossil/spatialite-tools/wiki?name=version+4.2.0 > ai "new XML processing tools" (pensa alla possibilità di importare in > DBMS un qualsiasi XML, es.: uno stesso progetto QGS, poterlo > modificare e poi riesportare). > > oppure alla pagina > https://www.gaia-gis.it/fossil/libspatialite/wiki?name=4.2.0+functions > al "building/updating a MetaCatalog" (per derivare informazioni su > tutti i valori assunti da qualsiasi attributo di una qualsiasi tabella > del tuo DBMS). > > Un'altro strumento interessante è il Dataseltzer > https://www.gaia-gis.it/fossil/dataseltzer/index > e > https://www.gaia-gis.it/fossil/dataseltzer/wiki?name=user_guide > > ciao, > Maurizio > > > > > Il 18/07/14, Paolo Cavallini<[hidden email]> ha scritto: >> Il 18/07/2014 11:56, Luca Lanteri ha scritto: >>> Concordo a pieno con te! >> >>> Detto questo come al solito servirebbero tempo e risorse (umane ed >>> economiche) per >>> lavorarci su ed entrambe scarseggiano parecchio. Sarebbe comunque >>> interessante capire >>> se sta ancora bollendo qualcosa in pentola e se c'è ancora interesse a >>> lavorare su >>> questi temi. >>> Qualcuno ha news in merito ? >> >> Non sono a conoscenza di investimenti significativi in questo senso, >> purtroppo. >> Saluti. >> -- >> Paolo Cavallini - www.faunalia.eu >> Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html >> _______________________________________________ >> [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. >> 666+40 iscritti al 5.6.2014 -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
In reply to this post by Maurizio Trevisani
Ciao Maurizio, in effetti anch'io notavo (e mi chiedevo il motivo) del rallentamento nell'integrazione di SL in QGIS, non tanto nello sviluppo di SL stesso che da quanto mi dici tu, e già mi diceva Alessandro tempo fa, sembra vispo !
Aiutami a capire, da utente di SL alle prime armi quale sono: con gli "XML processing tools" non solo puoi fare il parsing di un file xml per controllarne la validità, ma puoi anche scomporre il file xml in un database, modificarlo con sql e poi riesportarlo in xml ? Oppure ho capito male ?
grazie mille delle info Luca Il giorno 18 luglio 2014 20:41, Maurizio Trevisani <[hidden email]> ha scritto: .... a parte una serie di novità presenti nella 4.2 _______________________________________________ [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. 666+40 iscritti al 5.6.2014 |
On Tue, 22 Jul 2014 00:01:22 +0200, Luca Lanteri wrote:
> Aiutami a capire, da utente di SL alle prime armi quale sono: con gli > "XML processing tools" non solo puoi fare il parsing di un file xml > per controllarne la validità, ma puoi anche scomporre il file xml in > un database, modificarlo con sql e poi riesportarlo in xml ? Oppure > ho > capito male ? > Luca, hai capito perfettamente bene. grazie agli investimenti di Regione Toscana nell'ultimo anno spatialite si e' notevolmente irrobustita e sta diventato un tool discretamente potente e certamente molto flessibile per la gestione avanzata e sofisticata di datasets decisamente pesanti ed assai complessi (svariate decine di GB, centinai di layers, milioni e milioni di features, regole complesse da rispettare e verificare etc) paradossalmente SpatiaLite sta anche attraversando un periodo decisamente felice sul versante delle nuove piattaforme ultra light (Android etc), dove evidentemente le sue doti di estrema leggerezza e semplicita' rendono facile per moltissimi sviluppatori di apps (anche completamente a digiuno dei rudimenti piu' basilari del GIS "classico") affrontare con successo quelle problematiche di tipo GeoSpatial che stanno diventando sempre piu' pervasive nei settori piu' disparati anche grazie alla sempre crescente disponibiiita' di GeoOpenData. insomma, i due estremi opposti in questo caso si toccano; la medesima architettura pare essere ragionevolmente in grado di adattarsi flessibilmente tanto alle trappolette portatili dotate di risorse HW misurate col contagocce quanto agli ambienti piu' muscolosi tipici delle workstations e dei servers. venendo allo specifico XML gia' fin dalla precedente versione 4.1.0 spatialite ha pienamente integrato la poderosa libxml2, e quindi ora offre molti strumenti completamente SQL-based utili per lavorare con documenti XML generici p.es. e' supportata pienamente la validazione formale dei documenti XML rispetto agli schemi XSD, e' ben integrato il linguaggio standard XPATH per l'analisi degli alberi XML etc in particolare vengono supportati in modo piu' specifico e mirato i formati XML-like di maggior interesse GeoSpatial: - metadati ISO 19115 (Inspire) - stili SLD/SE (RasterSymbolizer etc) - reader WFS e WMS i nuovi XML tools introdotti dalla 4.2.0 (in via di rilascio a brevissimo) ora consentono anche di mappare completamente un qualsiasi documento XML (ma anche una serie di documenti, se sono tutti basati sul medesimo schema XSD) all'interno di un unico DBMS sqlite/spatialite. dopo di che a partire da questo punto ciascuno sara' poi evidentemente libero di sfruttare a fondo tutte le infinite potenzialita' di elaborazione tipiche del linguaggio SQL insomma, avendo come pre-requisito i necessari skills SQL, diventa poi ragionevolmente semplice scriversi tutti gli SQL scripts necessari per validare, verificare, correggere, integrare etc il dataset di partenza; fino eventualmente ad arrivare a riespotare nuovamente il DBMS con i contenuti finali sotto forma di un nuovo documento XML corrispondente allo schema di origine. se a tutto questo ci aggiungi poi il fatto che spatialite integra direttamente al suo interno tutta una serie di strumenti che consentono di esportare ed importare molti tra i formati dati di piu' ampia diffusione (SHP, DBF, XLS, DXF, TXT, WFS etc) ecco che alla fine abbiamo una piattaforma autonoma, leggera ma ragionevolmente completa che consente di affrontare con successo le piu' svariate categorie di data processing (sia Geo che non-Geo) basandosi esclusivamente su SQL come linguaggio standard. scordati del tutto il mondo "vita facile" tipico degli ambienti GUI click-click-click; qua siamo a pieno titolo in un ambiente tipicamente "da sviluppatori" e che richiede sicuramente robuste competenze di tipo informatico generale prima ancora che di tipo piu' speficamente GeoSpatial. ma che magari ti fara' scoprire quanto e' possibile spingersi lontano utilizzando esclusivamente le mille potenzialita' che ti offre il portentoso SQL (probabilmente il piu' bistrattato ed il meno compreso tra tutti i linguaggi di prgrammazione che siano mai stati inventati) ;-) 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. 666+40 iscritti al 5.6.2014 |
Free forum by Nabble | Edit this page |