[Gfoss] Spatial Join con SpatiaLite

[a.furieri a lqt.it]

On Wed, 15 Nov 2017 09:36:53 +0100, Massimiliano Moraca wrote:
> Nel caso specifico del db ISTAT precedentemente avevo fatto un LEFT
> JOIN tra le geometrie ed il csv dei dati statistici, dovrei quindi
> riportare oltre alle colonne che hai indicato anche il resto:p1, p2,
> ...st9 etc. E' lunghetto da scrivere ma se mi dici che non conviene
> usare SELECT* allora la strada è una. Toglimi una curiosità,
> premetto che ho conoscenze basilari di SQL e ne faccio un uso
> discontinuo, il non usare SELECT* è dato da una limitazione di
> SpatiaLite (essendo una LITE) o vale per ogni DMBS?
>

ciao Massimiliano,

direi proprio che e' una buona abitudine che vale per qualsiasi
DBMS, per un motivo abbastanza semplice.
quando tu scrivi "SELECT *" stai autorizzando il DBMS ad
assegnare i nomi-colonna come meglio preferisce, ed a volte
potrebbero nascere situazioni difficili da gestire.

giusto qualche esempio a caso:
- nel caso in cui la colonna 'pippo' sia presente sia nella
   tavola 'a' che nella tavola 'b' potresti poi scoprire che
   la tua View contiene una colonna di nome 'a.pippo' ed
   un'altra di nome 'b.pippo'; questi sono nomi SQL rognosi,
   che poi ti costringeranno ad usare il quoting tra doppie
   virgolette per mascherare il nome illegale.
   decisamente meglio evitare di finire in situazioni di questo
   tipo.
- versioni diverse del DBMS potrebbero usare criteri diversi
   per assegnare automaticamente i nomi-colonna alle View; e
   quindi tu potresti anche scoprire che la tua View funziona
   bene solo su alcune macchine ma non su altre.

insomma, e' essenzialmente un problema di autorita' e di controllo;
gli utenti occasionali trovano comodo affidarsi alle decisioni
automatiche del DBMS perche' (apparentemente) costa poca fatica.
invece gli utenti professionali specificano sempre tutto in modo
esplicito evitando accuratamente di affidarsi ai default
automatici perche' non gradiscono avere sorprese inattese.


> Toglimi una curiosità. ST_DISTANCE se usato in solitaria mi permette
> di creare un buffer visibile in QGIS
>

no; e' semplicemente un calcolo che ritorna un valore Double Precision,
non una geometria.


> potrei pure cavarmela con il virtual layer di QGIS ma se ne può
> creare solo uno ed a me ne servono 4: 250m, 500m, 750m, 1000.
>

guarda che con SpatiaLite puoi risolvere questo problema in modo
molto semplice. basta solo che tu aggiunga altre quattro colonne
geometriche alla tua tavola "input" e QGIS le vedra' poi come
se fossero layers distinti. prova qualcosa del genere:

SELECT AddGeometryColumn('input', 'buf250', 32632, 'POLYGON', 'XY');
SELECT AddGeometryColumn('input', 'buf500', 32632, 'POLYGON', 'XY');
SELECT AddGeometryColumn('input', 'buf750', 32632, 'POLYGON', 'XY');
SELECT AddGeometryColumn('input', 'buf1000', 32632, 'POLYGON', 'XY');

UPDATE input SET buf250 = ST_Buffer(geom, 250.0);
UPDATE input SET buf500 = ST_Buffer(geom, 500.0);
UPDATE input SET buf750 = ST_Buffer(geom, 750.0);
UPDATE input SET buf1000 = ST_Buffer(geom, 1000.0);

ciao Sandro