[Gfoss] Spatial Join con SpatiaLite

[Massimiliano Moraca]

Ciao Alessandro, grazie per la risposta come prima cosa :)

- primo errore: per arrivare a creare una View non si deve mai
>   partire creando direttamente la View stessa, perche' in questo
>   modo se qualcosa va storto non capirai piu' nulla e non sarai
>   in grado di identificare e correggere i tuoi errori.
>   si parte sempre definendo (e testando accuratamente) lo
>   statement SELECT, che una volta messo opportunamente a punto
>   sara' poi facilissimo trasformare in una View.


Hai ragione, in realtà è un errore voluto/non voluto nel senso che prima di
creare una view o una table faccio sempre come indichi, ho voluto però
postare l'intera query per completezza.

- secondo errore: mai usare "SELECT *" in una View; tu pensi in
>   questo modo di risparmiare tempo e fatica, ma finirari invece
>   per perdere un sacco di tempo e per faticare un sacco rincorrendo
>   errori "misteriosi".
>   buona regola da usare _SEMPRE_ con le View: tutte le colonne
>   vanno identificate esplicitamente con il proprio nome qualificato
>   (specificando cioe' a quale tavola appartiene ciascuna colonna),
>   ed e' sempre opportuno specificare esplicitamente tutti gli
>   alias names di colonna per evitare poi spiacevoli sorprese al
>   momento dell'esecuzione.


Ok, questo non lo sapevo, considera che lo faccio sempre... :(
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?

- terzo errore: (vedo che lo segnali tu stesso nella tua
>   mail successiva) ST_Contains() non e' l'operatore spaziale
>   che devi usare, perche' richiede che la prima geometria
>   copra interamente la seconda. Ma nel nostro caso e' molto
>   piu' verosimile che le Sezioni di Censimento ricadano solo
>   parzialmente all'interno del Buffer, ragion per cui e' molto
>   piu' opportuno usare la ST_Intersects()


Si, non ho capito perchè mi ero impuntato con ST_CONTAINS quando eseguendo
la stessa cosa in QGIS utilizzavo l'intersezione....purtroppo sono tornato
sano di mente quando già avevo inviato il messaggio :D

- quarto errore (veniale): quando usi un alias-name per le
>   tavole, cerca di usare una singola lettera, altrimenti poi
>   ti troverai a dovere gestire nomi completi esageratamente
>

  lunghi ed inutilmente complicati.


Questo è un altro errore voluto/non voluto. Volevo esplicitare sempre per
completezza chi era il target del join e chi il buffer ma in genere uso
sempre a, b, c, ect come alias.

Ora non posso provare le query che hai scritto ma spero di farlo in serata,
le ho lette e devo dire che sicuramente mi servirà velocizzare la selezione
visto che ho sia le geometrie che i dati censuari di tutta Italia in una
unica tabella :)

Toglimi una curiosità. ST_DISTANCE se usato in solitaria mi permette di
creare un buffer visibile in QGIS? (Appena posso proverò) Perchè usando
ST_BUFFER per creare la view a cui si aggiungono le geometrie con INSERT
INTO il vettore creato viene visto da QGIS come un punto e non un buffer.
Usando la stessa sintassi del buffer con un virtual layer invece ho la
visualizzazione del buffer. Mi serviva vedere il buffer per un purissimo
fatto visivo e non sono interessato ad inserirlo in nessun processo
ulteriore; 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.