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@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
