[Gfoss] VirtualKNN e max_distance

[Maurizio Trevisani]

Non sono in grado di valutare complessità e prestazioni, ma un parametro
max distanza mi sembra metta insieme sia la ricerca per vicinanza che una
intersezione spaziale con un buffer (appunto di max distanza) per scartare
risultati "troppo lontani".
Ma il vantaggio in termini di individuazione dei risultati desiderati va
considerato alla luce dello sforzo implementativo e se le prestazioni che
si ottengono risultino comparabili o migliori della combinazione di knn ed
intersection.

Un abbraccio,
Ciao,
Maurizio

Il dom 30 mag 2021, 00:01 <a.furieri a lqt.it> ha scritto:

> On Sat, 29 May 2021 12:51:54 -0700 (MST), pigreco wrote:
> > Maurizio Trevisani wrote
> >> Devi scrivere sulla mailing list di spatialite.
> >> Ciao,
> >> Maurizio
> >
> > Buonasera,
> > ormai penso sia tardi, la mia idea è stata bocciata.
> >
> > le prossime volte scriverò in lista spatialite.
> >
>
> Toto' e Maurizio,
>
> non vorrei che la mia risposta precedente sia suonata
> troppo perentoria.
>
> se ritente che un KNN basato sul concetto di MaxDistance
> possa essere utile e' una cosa assolutamente praticabile,
> ma deve essere ben chiaro che non avra' nulla a che fare
> con il KNN attuale perche' sara' basata su criteri del
> tutto diversi. in altre parole, non sara' una modifica
> dell'attuale, ma una implementazione nuova di pacca a
> partire da zero.
>
> schematizzando per quanto possibile: il KNN attuale e'
> basato su una interfaccia molto speciale di SQLite che
> consente di traversare la struttura ad albero R*Tree
> a basso livello. non c'e' nessuno spazio per introdurre
> un concetto di MaxDistance, c'e' solo da esplorare
> tutti i rami dell'albero potenzilament interessanti,
> che e' un'oparazione che fornisce risultati perfetti
> ma che ovviamente richiede del tempo.
>
> quello che invece e' ipotizzabile e' un approccio
> radicalmente diverso, che lasci perdere le API ultra
> sofisticate di SQLite e che lavori internamente a
> forza di query SQL "normali" basate sullo SpatialIndex
> tradizionale. ed in questo caso il criterio della
> MaxDistance nota a priori diventa un requisito
> ineluttabile per ottenere una ragionevole velocita'
> di esecuzione.
>
> dal punto di vista dell'utente cambia poco (giusto
> un parametro in piu, la MaxDistance), ma dal punto
> di vista del codice cambia assolutamente tutto, non
> si salva neppure una riga dell'esistente.
>
> --------------------
>
> detto di striscio: il KNN sta causando diversi
> problemi agli utenti Java, Python, PHP e C#,
> specie su Windows.
>
> tutti questi linguaggi hanno dei connettori per
> SQLite che quasi sempre utilizzano la propria
> libsqlite3.dll privata interna che spesso e' di
> una versione differente da quella utilizzata
> da mod_spatialite, e magari e' stata compilata
> con opzioni differenti.
> una combinazione che non porta a nulla di buono
> in termini di stabilita' e compatibilita'.
>
> l'unica causa che scatena tutti questi conflitti
> e' proprio il KNN che dipende in modo critico dal
> supporto della libsqlite3. tutto funziona bene
> se la libsqlite3 utilizzata a runtime e' esattamente
> la stessa usata in compilazione (come accade p.es.
> per SpatialiteGUI e suppongo anche per QGIS),
> altrimenti si avranno sicuramente problemi piu'
> o meno seri.
>
> capite dunque che a me personalmente farebbe anche
> molto comodo "fare fuori" il KNN attuale sostituendolo
> con un KNN2 basato sulla MaxDistance, perche' sarebbe
> un modo soddisfacente per tutti per eliminare un
> pasticcio di architettura.
>
> ma per arrivarci dobbiamo necessariamente trasferire
> questa nostra discussione sulla ML di spatialite; e
> mi serve il vostro appoggio, perche' non sembri un
> mio capriccetto personale.
>
> vogliamo provarci ?
>
> ciao Sandro
>
>
>
>
> _______________________________________________
> Gfoss a lists.gfoss.it
> 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.
> 764 iscritti al 23/08/2019