Re: [Gfoss] Spatialite FOREIGN KEY in LOAD_SHAPEFILE
On Thu, 22 Jun 2023 11:34:34 +0200, Marco Guiducci via Gfoss wrote: procedo (anzi o già proceduto): la prima spatial view è nata. ora ridisfo tutto e riparto. devo mettere le FK su tutte le tabelle (il grafo regionale... che penso tu conosca!). mi domando perché non lo diamo già in sqlite "bell'e che fatto" direbbe qualcuno :-) mi associo sentitamente ;-) ho perso il conto di quante volte ho dovuto smadonnare come un carrettiere turcomanno per riuscire a tirare fuori un grafo stradale utilizzabile a partire dagli shapefiles di Iter.Net :-P gia' che siamo in argomento ne approfitto per segnalarti uno sviluppo che potrebbe potenzialmente interessarti. grazie al draping supportato da RasterLite2 e' molto facile (e pure ragionevolmente veloce) ottenere un grafo derivato completamente 3D appoggiandolo sul DEM TinItaly ad alta risoluzione (10m) rilasciato in CC-BY 4.0 dall'INGV caveat: padella di brutto sui viadotti e sulle gallerie perche' ovviamente segue il profilo altimetrico del rilievo, ma in linea di massima si ottengono risultati decisamente notevoli. 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
Re: [Gfoss] Spatialite FOREIGN KEY in LOAD_SHAPEFILE
On Thu, 22 Jun 2023 09:52:26 +0200, Marco Guiducci via Gfoss wrote: Buongiorno, la funzione LOAD_SHAPEFILE non permette di creare una FK (probabilmente perché la tabella referenziata potrebbe non esistere ancora?) A quanto leggo SQlite non permette di creare una FK, dopo, con ALTER TABLE (1). (ottengo errore di sintassi) Se è così occorre creare una nuova tabella popolandola con la tabella creata dalla LOAD e creare, contestualmente la/le FK. Qualcuno mi conferma? ciao Marco, effettivamente la ALTER TABLE di SQLite presenta molte limitazioni rispetto a quella che trovi su altri DBMS (primo tra tutti Postgres). quello che dici e' corretto; e' possibile definire le PK e le FK di una tavola solo al momento delle CREATE TABLE perche' la ALTER TABLE non consente in alcun modo di intervenire a posteriori sulle definizioni della PK e delle FK da parte sua la ImportSHP() e' una funzione abbastanza rigida che si limita a creare una tavola spatial con tutte le colonne che trova nello Shapefile seguendo una logica di cieco automatismo. quindi alla fine non hai alternative: se ti serve una Spatial Table con dei vincoli relazionali FK/PK con ulteriori tavole te le devi creare a mano per poi procedere al loro popolamento. nota: in situazioni come queste puo' essere utile ricorrere ai VirtualShape che trovi documentati qua: https://www.gaia-gis.it/fossil/libspatialite/wiki?name=Virtual+Tables+(misc) in sostanza ricorrendo al VirtualShape puoi leggere direttamente lo Shapfile esterno senza caricarlo nel DB, cosa che ti permette di popolare la "vera" tavola Spatial creata a mano con tutte le sue PK/FK semplicemente con una sintassi come questa: INSERT INTO my_real_table SELECT a,b,c,d,,x,y,z FROM my_virtual_shape; nota: per inciso questo ti consente anche di specificare una eventuale WHERE per restringere le features da importare. una volta che hai compiuto l'operazione di trasferimento dei dati poi dovrai semplicemente eliminare la VirtualShape che non serve piu' a nulla: DROP TABLE my_virtual_shape; spero di esserti stato utile, 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
Re: [Gfoss] Un servizio WMS con dati OSM
On Fri, 25 Jun 2021 22:21:10 +0200, Andrea Peri wrote: Ciao Alessandro, mi rifaccio vivo per ringraziarti delle segnalazioni.Ora dovrebbe essere molto migliorato , almeno spero. Andrea, sentite congratulazioni, ora e' veramente bella e soprattuto molto chiara, intuitiva e facilmente leggibile a tutte le scale Ho confrontato con il risultato di un plugin OSM e a me pare che ora le strade di siano tutte. altro che ... su Arezzo citta' ci sono pure le (poche) piste ciclabili che abbiamo :-D Caso mai la renderizzazione non è che sia il massimo, ma li' vedro' se con il tempo riesco a migliorare le cose. a me pare piu' che accettabile anche cosi' come e' ora; certo, tutto si puo' sempre migliorare, ma tu sei gia' decisamente ad un ottimo punto. rallegramenti. mi stai facendo venire la voglia di provare a vedere come funziona come cartografia di sfondo per i miei percorsi degli autobus ;-) ciao Sandro Ricordo la url: http://www.mappegis.it/osm_cached/wms [4]? Il giorno dom 30 mag 2021 alle ore 18:33 ha scritto: On Sat, 29 May 2021 23:58:12 +0200, Andrea Peri wrote: > Salve, > > Per chi è interessato a provarlo. > > A questa url ho messo in piedi un servizio WMS che serve i dati di > OSM in > forma WMS usando MapProxy > > http://www.mappegis.it/osm_cached/wms [1]? > Andrea, recensione breve: fighissimo !! molto rapido e fluido, gira che e' una bellezza, grafica molto piacevole. recensione piu' ponderata = tanto per iniziare, mi ha fatto sudare prima di riuscirmi a collegare con il client WMS di spatialite/rasterlite2. :-P capiamoci bene, non che ci sia nulla di sbagliato nel tuo server WMS: semplicemente ha portato a galla un paio di bacherozzoli nel client (HTTP/2 anziche' il piu' comune HTTP1/1, una redirect che ti ridirige da HTTP su HTTPS, qualche altro pasticcetto sugli headers HTTP). meglio cosi', perche' cosi' anche senza volerlo hai dato una robusta mano al debugging del client WMS :-D qualche appunto per eventuali migliorie: 1. non c'e' nessuno strato che faccia da sfondo, lo sfondo rimane in larga parte trasparente. vedo invece che nel sito "ufficiale" OSM [1] usano sempre qualcosa come riempitivo che ti fa capire a colpo d'occhio cosa e' mare e cosa e' terra (suppongo che usino i confini amministrativi) 2. ho dato un'occhiata alla citta' di Arezzo; rispetto a quanto vedo sul sito OSM nel tuo WMS mancano tanti edifici, ci sono interi quartieri anche densamente edificati che appaiono vuoti. suppongo che sia legato alla codifica delle features di OSM, probabilmente stai ignorando qualche tipologia che invece e' importante. 3. anche sul reticolo stradale noto diverse differenze; ci sono tante stradine che mancano, piu' che un reticolo sembrano tanti "spaghetti" buttati un po' a caso qua e la. se provi a guardare la SS1 Aurelia a nord di Orbetello verso Albinia e Fonteblanda vedrai che appare perfetta alle piccole scale, ma se provi ad ingrandire vedrai che sparisce quasi tutto lasciando solo qualche "vermetto" qua e la. cosi' a occhio mi pare che capita quando scendi sotto 1:50.000; invece di vedere piu' dettagli come ti aspetteresti sparisce un sacco di roba. > ps: > Il sito e' per divertirmi a fare prove e non garantisco sulla > continuità > del servizio. > ;) > sarebbe un vero peccato, perche' sicuramente e' una risorsa parecchio utile ;-) ciao Sandro ___ Gfoss@lists.gfoss.it [2] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss [3] 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 -- - Andrea Peri . . . . . . . . . qwerty àèìòù - Links: -- [1] http://www.mappegis.it/osm_cached/wms [2] mailto:Gfoss@lists.gfoss.it [3] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss [4] http://www.mappegis.it/osm_cached/wms [5] mailto:a.furi...@lqt.it ___ 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
Re: [Gfoss] {Disarmed} Re: clonetable e opzione cast2multi
On Mon, 14 Jun 2021 17:25:47 +0200, Totò Fiandaca wrote: allora è bug io uso spatialite_gui 2.1.0 beta1 e faccio scrivere tutto alla gui si, c'era un bug nel wizard della GUI era proprio li che mancava il primo ':' nel nome del parametro. grazie per la segnalazione, 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
Re: [Gfoss] clonetable e opzione cast2multi
On Mon, 14 Jun 2021 16:45:35 +0200, Totò Fiandaca wrote:
Buonasera,
l'output di un script SQL genera una tabella di tipo LINESTRING
32632,
non ha geometrie malformate e il check RTOPO è tutto verde.
la clono [0] per forzare la geometria in MULTILINESTRIG:
SELECT CloneTable('MAIN', 'split_finale', 'divisa', 1,
':cast2multi::geom');
---
1
ma nonostante tutto rimane LINESTRING.
Cosa sbaglio?
Toto',
stai sbagliano la sintassi: ti sei mangiato un due-punti davanti al
cast
::cast2multi::geom
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
Re: [Gfoss] SpatiaLite e SnapAndSplit
On Sun, 13 Jun 2021 10:19:27 +0200, Totò Fiandaca wrote: Buongiorno, fino a ieri per dividere delle MultiLineString 32632 con dei punti utilizzavo, nel mio script SQL, due aggiornamenti della geometria: 1. per fare lo snap 2. per fare lo split ho scoperto la funziona SnapAndSplit [0] che dovrebbe fare tutto in un unico passaggio, sembra funzionare ma da vari test l'uso di SnapAndSplit mi genera un output con una riga in più rispetto al caso diviso (prima snap e poi split). Esiste un motivo teorico oppure devo indagare sulla geometria di input? Toto', la SnapAndSplit() si limita semplicemente a chiamare in sequenza prima la Snap e poi la Split, non fa altro. vedo pero' che nel tuo SQL c'e' una sottilissima differenza; tu parti col la Snap, poi applichi la RemoveRepeatedPoints() ed infine chiami la Split. nell'altra versione chiami la SnapAndSplit() e poi la RemoveRepeatedPoints(); non e' la stessa cosa, perche' nel primo caso elimini i punti doppi _PRIMA_ della Split, mentre nel secondo casi li elimini _DOPO_ la Split. per evitare di confrontare le mele con le banane dovesti provare a chiamare la RemoveRepeatedPoints() sempre come ultimissimo passaggio. cosi' a lume di naso potrebbe essere proprio quel passaggio a fare la differenza, altrimenti trovo difficile spiegare come facciano a venire fuori due risultati diversi. domanda: ma non e' che per caso il tuo dataset e' "sporco" e contiene gia' in partenza punti doppi ? perche' allora parrebbe piu' saggio iniziare chiamando la RemoveRepeatedPoints() al primissimo passaggio prima ancora di procedere con Snap e Split. 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
Re: [Gfoss] {Disarmed} Re: stored procedure e messaggio finale NULL
On Fri, 11 Jun 2021 16:20:24 +0200, Totò Fiandaca wrote: Grazie mille per la rapida risposta. Quindi non mi preoccupo. Nuovamente grazie, ma le stored procedure sono solo in spatialite o anche in sqlite? sono un'estensione a SQLite implementata da libspatialite. SQLite ha una bella architettura spartanamente rudimentale in cui c'e' solo lo stretto indispensabile. ma e' molto facile sfruttare la sua struttura modulare aperta e flessibile per aggiungere un sacco di ulteriori funzionalita' piu' sofisticate ... che e' esattamente quel che fa SpatiaLite. 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
Re: [Gfoss] stored procedure e messaggio finale NULL
On Fri, 11 Jun 2021 15:40:18 +0200, Totò Fiandaca wrote:
Buonasera a tuttə,
ho studiato le stored procedure di spatialite 5 [0] e ho un problema
che
non riesco a risolvere da solo.
Lavoro con spatialite_gui 2.1.0 beta1 con spatialite 5.0.0 e sqlite
3.33.0
Ho creato un mio database usando la gui e importato una sola tabella
(vettore MultiLineString 32632),
su questa tabella faccio una serie di query, circa 53, tutte a
cascata.
Ho usato le stored procedure, ovvero ho sostituito al posto del nome
della
tabella (es:pippo) la variabile @toto@ e ho salvato l'intero script
SQL in
un file, es: my_script_sql.sql
da spatialite_gui lancio la seguente query:
SELECT SqlProc_SetLogfile(
'C:\Users\pigre\Desktop\db_prova_route\logfile.txt', 1);
SELECT
SqlProc_Execute(SqlProc_FromFile('D:\Gitlab\civ_x_of\
my_script_sql.sql
'),'@toto@=pippo');
tutto procede bene, ma alla fine ottengo:
SqlProc_Execute(SqlProc_FromFile('D:\Gitlab\civ_x_of\
my_script_sql.sql
'),'@toto@=pippo')
NULL
ma ottengo l'output corretto, cosa significa questo NULL? devo
preoccuparmi?
Toto',
almeno in teoria quando uno sviluppatore decide di perdere
qualche giornata per tenere aggiornata la documentazione
tecnica lo fa proprio con l'intenzione di chiarire dubbi
come questo :-D
http://www.gaia-gis.it/gaia-sins/spatialite-sql-5.0.1.html
ecco cosa dice per la funzione SqlProc_Execute()
"On success will return the Return Value defined
(explicitly or implicitly) by SqlProc_Return()."
a sua volta la SqlProc_Return() riporta:
"Any SQL Body terminating without explicitly
calling SqlProc_Return() or StoredProc_Return()
will always behave as if SqlProc_Return(NULL)
was implicitly called."
conclusione: nel tuo SQL script non viene mai
chiamata nessuna SqlProc_Return(); e di conseguenza
esce con il valore impostato by default che e' NULL
insomma, e' tutto assulutamente regolare, fa
esattamente quel che ci si aspetta che faccia. :-D
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
Re: [Gfoss] Un servizio WMS con dati OSM
On Sun, 6 Jun 2021 11:10:08 +0200, Andrea Peri wrote: Ciao Alessandro. Ho aggiunto le batimetriche come accennato sottoforma di layergroup costruito lato server.L'effetto nel risultato è ottimo, ma non so quanto sia corretto dal punto di vista della licenza. Infatti l'effetto finale del LayerGroup e' raggruppare lato server e quindi in maniera trasparente all'utente utlizzatore. E' vero che i due dati sorgente sottostanti sono differenti e non esiste una vera elaborazione che produca un terzo strato vettoriale a partire dai due citati, ma l'effetto all'utente finale è lo stesso. Ovvero il server fornisce una mappa con dentro entrambi i dataset. Andrea, la nuova versione con le batimetriche e' veramente molto carina ed accattivante, bella grafica molto intuitiva. giusto due appunti: - il layer delle batimetriche non pare combaciare bene con OSM; lungo le linee di costa si notano sempre della fasce trasparenti causano un effetto abbastanza evidente di pixellizazione (quadratoni piu' o meno grossi). ma e' solo un dettaglio e non disturba poi troppo - mi pare che ora giri abbastanza piu' lento, direi che c'e' un sensibile allungamento dei tempi di risposta; evidentemente le batimetriche si fanno sentire. venendo alle tue considerazioni sulle licenze, per capirsi meglio dobbiamo dare un'occhiata alla GetCapabilities; riporto solo i tags rilevanti. Mappe GIS - OSM Dataset Toscana,Emilia-Romagna,Marche,Umbria (Italy) rt_osm.osm_g.default@96dpi OSM g-style 96 DPI ... OpenStreetMap rt_osm.osm_g.default@150dpi rt_osm.osm_g.default@300dpi cioe' prima vai a definire un Layer Group (privo di Name, e qunque non direttamente selezionabile, un mero aggregato simbolico). dentro a questo contenitore poi vengono definiti tre Layers, che sono sostanzialmente identici a parte la risoluzione DPI. ciascuno di questri Layer "figli" mescola tutto assieme lato server sia i dati OSM che le batimetrie, in un modo tale che non rende possibile selezionare separatamente le una dalle altre. infatti poi dichiari come Open Street Map, che pero' non e' corretto perche' cosi' finisci per dare l'impressione che anche le batimetrie siano copyright OSM, cosa non vera. infine dentro ad appare la seguente declaratoria: "Dataset OSM del territorio di Toscana, Emilia-Romagna, Marche e Umbria con stile di vestizione 'google-like' a 96DPI. Strato DTM relativo alle batimetriche del bacino del mediterraneo. Fonte: EMODnet Bathymetry Consortium (2018): EMODnet Digital Bathymetry (DTM) http://doi.org/etcetc. Anno 2018. Risoluzione 1/16 arc minuto. Sistema di riferimento originale epsg:4326" qua finalmente si capisce che in effetti vengono utilizzati due dataset ben distinti con copyright indipendenti, ma allora quantomeno EMODnet andrebbe citata anche e soprattutto nel tag -- quello che avevo in mente io quando ti suggerivo di utilizzare i Layer Groups per tenere distinti i copyright dei vari datasets era qualcosa di diverso: Mappe GIS - OSM Dataset Toscana,Emilia-Romagna,Marche,Umbria (Italy) mappa_aggregata@96dpi EMODnet 96dpi ... EMODnet mappa_osm@96dpi OSM 96 DPI ... OpenStreetMap ovviamente ciascun andrebbe adattato in modo tale da citare solo il dataset di specifico interesse per ciascun layer. in questo modo riusciresti a rendere chiarissimo che stai offrendo due Layers "figli" del tutto indipendenti (che potrebbero anche venire utilizzati uno alla volta se il client lo ritiene opportuno), continuando pero' a consentire la consultazione aggregata visto che ora il Layer Group dichiara un mi rendo conto che pero' tu hai 3 versioni (96, 150 e 300) DPI, per cui dovresti definire 3 Layers Group ciascuno con 2 "figli" ... l'affare si ingarbuglia. 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
Re: [Gfoss] Un servizio WMS con dati OSM
On Fri, 4 Jun 2021 08:02:49 +0200, Andrea Peri wrote: Ciao Alessandro, ritorno suquesto tuo messaggio per una richiesta di un parere. Ho preso in carico il tuo suggerimento di mettere sui tasselli della cached anche delle batimetriche (e e anche la parte a terra). La mia intenzione sarebbe di metterci delle batimetriche molto belle che ho recuperato dal sito emodnet, piuttosto che una semplice pennellata di celeste piatto, e piuttosto che delle "finte" batimetriche ricopiate a occhio da chissa' dove... Pero' ho il dubbio che la licenza di OSM , che e' virale , non consenta di mescolare su delle immagini come lo sarebbero i tasselli di una cache i suoi dati, con delle batimetriche che hanno una altra provenienza e una licenza differente. parere personale: se nel tuo WMS riesci a pubblicare un Layer Group che mantenga l'identita' individuale dei due Layers sottostanti (quello OSM e quello delle batimetriche) non dovresti avere problemi di sorta visto che nella GetCapabilities potresti accuratamente segnalare le diverse licenze e titolarieta' per ciascun dataset. in fondo un Layer Group e' per definizione un livello di aggregazione multi-source, e parrebbe abbastanza logico supporre che ciascuno dei Layers di livello inferiore viva di vita autonoma. Anche per questo ero piu' propenso piuttosto a predisporre un servizio che forniva i tasselli dell'OSM e a parte le betimetriche. In questo modo e' l'utente che le impiega entrambe. questa sicuramente direi che sia una soluzione a prova di bomba dal punto di vista delle licenze, visto che in questo modo i diversi dataset si sovrappongono solo sui client. come dici tu, e' pero' un pelo meno pratica dell'altra. Certamente capisco anche il punto di vista che avere la mappa gia' pronta con le batimetriche e la parte a terra, in una unica chiamata semplifica molto l'impiego, ma ho dubbi che sia possibile, come accennavo, per la licenza di OSM. D'altronde non ci metterei una spennellata di celeste, perche' il bianco puo' essere reso trasparente e permette giochi di sovrapposizione con altri strati , mentre altri colori specialmente se non uniformi complicano questa cosa. Luca Delucchi e Maurizio Napolitano: i due massimi esperti italiani sull'interpretazione della ODbL siete voi. cosa ne pensate ? 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
Re: [Gfoss] Un servizio WMS con dati OSM
On Sat, 29 May 2021 23:58:12 +0200, Andrea Peri wrote: Salve, Per chi è interessato a provarlo. A questa url ho messo in piedi un servizio WMS che serve i dati di OSM in forma WMS usando MapProxy http://www.mappegis.it/osm_cached/wms? Andrea, recensione breve: fighissimo !! molto rapido e fluido, gira che e' una bellezza, grafica molto piacevole. recensione piu' ponderata = tanto per iniziare, mi ha fatto sudare prima di riuscirmi a collegare con il client WMS di spatialite/rasterlite2. :-P capiamoci bene, non che ci sia nulla di sbagliato nel tuo server WMS: semplicemente ha portato a galla un paio di bacherozzoli nel client (HTTP/2 anziche' il piu' comune HTTP1/1, una redirect che ti ridirige da HTTP su HTTPS, qualche altro pasticcetto sugli headers HTTP). meglio cosi', perche' cosi' anche senza volerlo hai dato una robusta mano al debugging del client WMS :-D qualche appunto per eventuali migliorie: 1. non c'e' nessuno strato che faccia da sfondo, lo sfondo rimane in larga parte trasparente. vedo invece che nel sito "ufficiale" OSM [1] usano sempre qualcosa come riempitivo che ti fa capire a colpo d'occhio cosa e' mare e cosa e' terra (suppongo che usino i confini amministrativi) 2. ho dato un'occhiata alla citta' di Arezzo; rispetto a quanto vedo sul sito OSM nel tuo WMS mancano tanti edifici, ci sono interi quartieri anche densamente edificati che appaiono vuoti. suppongo che sia legato alla codifica delle features di OSM, probabilmente stai ignorando qualche tipologia che invece e' importante. 3. anche sul reticolo stradale noto diverse differenze; ci sono tante stradine che mancano, piu' che un reticolo sembrano tanti "spaghetti" buttati un po' a caso qua e la. se provi a guardare la SS1 Aurelia a nord di Orbetello verso Albinia e Fonteblanda vedrai che appare perfetta alle piccole scale, ma se provi ad ingrandire vedrai che sparisce quasi tutto lasciando solo qualche "vermetto" qua e la. cosi' a occhio mi pare che capita quando scendi sotto 1:50.000; invece di vedere piu' dettagli come ti aspetteresti sparisce un sacco di roba. ps: Il sito e' per divertirmi a fare prove e non garantisco sulla continuità del servizio. ;) sarebbe un vero peccato, perche' sicuramente e' una risorsa parecchio utile ;-) 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
Re: [Gfoss] VirtualKNN e max_distance
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
Re: [Gfoss] VirtualKNN e max_distance
On Sat, 29 May 2021 07:11:42 -0700 (MST), pigreco wrote: Forse le query non sono scritte in modo ottimale, ma secondo me un parametro max_distance nelle virtualKNN aiuterebbe molto Toto' scusami tanto per la sincerita' forse brutale, ma introdurre un parametro MaxDistance nel KNN e' un completo nonsense logico. mi spiego meglio: se l'approccio KNN ha qualcosa di meritevole e' proprio nel fatto che ti consente di lavorare su datasets di cui ignori completamente la distribuzione spaziale delle features. non importa se in alcuni casi troverai distanze minime di pochi metri ed in altri di migliaia di chilometri, il KNN ti trovera' sempre e comunque quali sono le features piu' vicine le une alle altre. se invece hai gia' un'idea di massima di una "ragionevole" distanza massima entro cui speri di trovare delle possibili corrispondenze, allora l'approccio KNN e' del tutto ridondante, perche' una banalissima query basata sull'uso convenzionale dello SpatialIndex imponendo il raggio di distanza atteso nel codice della tua query SQL sara' sempre sicuramente piu' performante. le due cose (KNN e MaxDistance) non stanno assieme, sono mutuamente esclusive; o l'uno o l'altra. riassumendo: se conosci a priori un raggio di distanza "ragionevole" allora la tua query puo' essere riscritta come segue facendo del tutto a meno ti tirare in ballo il KNN: CREATE TABLE civici10m AS SELECT p.id AS id_punto, s.id AS id_strada, Min(ST_Distance(s.geom, p.geom)) AS distance, ST_shortestline(p.geom, s.geom) as geom FROM civici AS p LEFT JOIN strade AS s ON (ST_Distance(s.geom, p.geom) < 10.0 AND s.id IN ( SELECT rowid FROM SpatialIndex WHERE f_table_name = 'strade' AND f_geometry_column = 'geom' AND search_frame = ST_Buffer(p.geom, 10.0))) GROUP BY p.id; giusto per avere un'idea dei tempi di esecuzione con datasets "pesantucci" ho testato la query nelle condizioni seguenti: a) grafo stradale ITER.NET di regione toscana (oltre 400mila archi) i punti di fermata degli autobus toscani sparsi su tutta le regione (circa 38mila) la query gira in meno di 10 sec b) solito grafo stradale i numeri civici della toscana (poco piu' di 1 milione e mezzo) qua evidentemente i dimensionamenti si fanno sentire, ma comunque se la cava in circa 4 minuti, che definirei un tempo decisamente confortevole. ciao Sandro piccolo approfondimento tecnico: il KNN e' un modulo molto sofisticato che va ad intrufolarsi direttamente dentro alla struttura interna degli R*Tree che sono alla base dello SpatialIndex. non e' necessariamente un fulmine di velocita' perche' per esplorare tutti i nodi dell'albero (almeno della parte piu' interessante) occorre tempo, pero' e' completo e sicuramente trova tutti i possibili candidati. in tutti gli altri casi l'approccio classico di tipo dicotomico e' sicuramente preferibile. ___ 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
Re: [Gfoss] [spatialite] spatialIndex e punti
On Wed, 26 May 2021 22:28:42 +0200, Totò Fiandaca wrote: Ho il classico problema di determinare, a partire da punti e linee, quale sia la distanza minima tra punti e linee. Per velocizzare la query uso lo spatialIndex e la query è la seguente SELECT a.pk_uid as fid, Min(ST_Distance(a.geom, zz.geom)) AS distance, zz.pk_uid as pk_uid_punti, st_shortestline (a.geom, zz.geom) as geom FROM strade as a, punti as zz WHERE a.pk_uid IN ( SELECT rowid FROM SpatialIndex WHERE f_table_name = 'strade' AND search_frame = ST_Buffer(zz.geom, 100)) GROUP by zz.pk_uid order by 2 desc; nel search_frame uso un buffer di 100 m sul punto, cosi facendo mi aspetto che determini le distanze solo per punti entro 100 m, invece ci sono punti anche oltre i 100m (fino a 163 m); non riesco a capire il perché. Toto', giusto una considerazione finale che mi era sfuggita nella mia risposta precedente. non c'e' nessun bisogno di costruire un Buffer attorno al punto se almeno una delle due geometrie e' sicuramente un (multi)Linestring oppure un (multi)Polygon. bastano abbondantemente i BBOX cosi' come sono. costruire un Buffer e' invece strettamente indispensabile per riuscire a far funzionare lo SpatialIndex quando entrambe le geometrie sono Point, perche' altrimenti il filtro ti lascera' passare solo i punti esattamente sovrapposti, una circostanza decisamente improbabile. considerando che l'operazione di costruzione di un Buffer richiede comunque un certo carico computazionale, e' meglio evitare di effetturarla quando non e' strettamente indispensabile perche' finisce per rallentare la query. 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
Re: [Gfoss] [spatialite] spatialIndex e punti
On Wed, 26 May 2021 22:28:42 +0200, Totò Fiandaca wrote: Ho il classico problema di determinare, a partire da punti e linee, quale sia la distanza minima tra punti e linee. Per velocizzare la query uso lo spatialIndex e la query è la seguente SELECT a.pk_uid as fid, Min(ST_Distance(a.geom, zz.geom)) AS distance, zz.pk_uid as pk_uid_punti, st_shortestline (a.geom, zz.geom) as geom FROM strade as a, punti as zz WHERE a.pk_uid IN ( SELECT rowid FROM SpatialIndex WHERE f_table_name = 'strade' AND search_frame = ST_Buffer(zz.geom, 100)) GROUP by zz.pk_uid order by 2 desc; nel search_frame uso un buffer di 100 m sul punto, cosi facendo mi aspetto che determini le distanze solo per punti entro 100 m, invece ci sono punti anche oltre i 100m (fino a 163 m); non riesco a capire il perché. Toto', una semplicissima figurina ti aiutera' sicuramente a capire meglio. 1) la spezzata rappresenta un ipotetico Linestring (la tua strada) quello evidenziato in rosso e' il BBOX corrispondente. 2) in blu vedi un Point, anzi per la precisione vedi il Buffer allargato costruito attorno al punto, che e' un cerchio. sempre in blu vedi il BBOX corrispondente al Buffer. 3) come vedi i due BBOX (quello rosso e quello blu) presentano un'intersezione; e di conseguenza lo Spatial Index, che e' semplicemente basato sulla valutazione speditiva dei BBOX, ti lascia passare la coppia Linestring-Point per ulteriori valutazioni piu' raffinate (*). 4) infine abbiamo il tratto violetto che indica la minima distanza; che come vedi in questo esempio supera di gran lunga il raggio del Buffer costruito attorno al Point. (*) eccoci arrivati alla valutazione piu' raffinata che devi fare. lo SpatialIndex e' semplicemente un filtro spaziale molto rapido che ti consente di scartare a priori tutte le coppie "impossibili", ma che non ti assicura affatto la valutazione precisa della relazione spaziale tra le due geometrie. quella la deve fare la tua query nella sua clausola WHERE FROM strade as a, punti as zz WHERE ST_Distance (a.geom, zz.geom) <= 100.0 AND a.pk_uid IN ( 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
Re: [Gfoss] VirtualKNN in SpatiaLite 5
On Mon, 19 Apr 2021 12:37:29 -0700 (MST), pigreco wrote: Altra sorpresona, anche da me è velocissimo ma genera dati senza senso. hai ragione, c'era una falla logica in qualle query; occorre definire un buffer che "gonfi" il punto-incrocio, altrimenti il filtro sullo spatial index prende in considerazione solo quelle strade che casualmente intersecano il BBOX del punto. eccoti qua la versione riveduta e corretta: CREATE TABLE wow AS SELECT a.pk as fid, Min(ST_Distance(a.geom, zz.geom)) AS distance, zz.pk as pk_punti, st_shortestline (a.geom, zz.geom) as geom FROM strade_palermo as a, inc2k18Palermo as zz WHERE a.pk IN ( SELECT rowid FROM SpatialIndex WHERE f_table_name = 'strade_palermo' AND search_frame = ST_Buffer(zz.geom, 0.01)) GROUP by zz.pk; -- abbiamo cosi' introdotto due perditempo: - la ST_ShortestLine - la ST_Buffer e comunque stiamo sempre sui 6-7 secondi. N.B. il raggio del buffer e' fissato "a occhio" (circa 1km), che almeno in questo caso pare rappresentare un buon compromesso tra efficienza e precisione dei risultati. ecco dove sta il principale vantaggio dal KNN; che non ti costringe mai a fare assunzioni piu' o meno arbitrarie sui raggi di probabile distanza. 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
Re: [Gfoss] VirtualKNN in SpatiaLite 5
On Mon, 19 Apr 2021 19:36:25 +0200, Marco Curreli wrote: On 19.04.21, a.furi...@lqt.it wrote: On Mon, 19 Apr 2021 03:20:37 -0700 (MST), pigreco wrote: > > dati due tabelle, una con circa 3000 punti e un'altra con circa 1 > linee > (assi stradali); trovare, per ogni punto, l'asse stradale più vicino. Con v.distance di GRASS è molto più veloce. Sorpresona ... alla fine si scopre che il miglior tempo su SpatiaLite lo si ottiene usando l'approccio classicissimo lasciando perdere il KNN :-D SELECT a.pk as fid, Min(ST_Distance(a.geom, zz.geom)) AS distance, zz.pk as pk_punti FROM strade_palermo as a, inc2k18Palermo as zz WHERE a.pk IN ( SELECT rowid FROM SpatialIndex WHERE f_table_name = 'strade_palermo' AND search_frame = zz.geom) GROUP by zz.pk; chiude con un tempo superstellare di 0.409 secondi (si, avete letto bene: meno di mezzo secondo) conclusione: il KNN e' un metodo sofisticato basato sulle API "advanced" di SQLite che consentono l'introspezione degli R*Tree. nulla assicura che sia il metodo in grado di dare i risultati migliori in assoluto. sarebbe casomai interessante indagare come evolvono i tempi quando si passa di risolvere problemi piu' complessi (tipo svariati milioni di righe e di punti) ... magari nella prossima vita, quando magari avremo piu' tempo libero per divertici a fare benchmarking ;-) 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
Re: [Gfoss] VirtualKNN in SpatiaLite 5
On Mon, 19 Apr 2021 03:20:37 -0700 (MST), pigreco wrote: Buongiorno a tutte/i ho usato in passato i VirtualKNN di SpatiaLite soprattutto nei trigger, ma ora volevo usarlo per risolvere il seguente quesito: dati due tabelle, una con circa 3000 punti e un'altra con circa 1 linee (assi stradali); trovare, per ogni punto, l'asse stradale più vicino. Per risolvere questo problema ho pensato di usare spatialite 5 e la tabella KNN. Ho importato i due vettori in un geodatabase sqlite (creato con QGIS 3.19 master, che ha implementato spatialite 5.0.1) e ho lanciato la seguente query: SELECT a.fid as pk_strade, a.distance as distance, zz.pk as pk_punti FROM knn as a JOIN inc2k18Palermo as zz WHERE f_table_name = 'strade_palermo' AND f_geometry_column = 'geom' AND ref_geometry = zz.geom AND max_items = 1 la query restituisce un output e quindi creo la relativa tabella (create table as ..), ma impiega circa 200 secondi (sia da db manager di QGIS che da spatialite_gui 2.1.0 beta 1); che ci impieghi sempre lo stesso tempo e' normale; il lavoro duro lo fa esclusivamente libspatialite, che venga incapsulata dentro a QGIS oppure dentro alla GUI e' assolutamente irrilevante. i tempi che riporti non mi tornano con quanto verifico sul mio PC; qua da me ci mette poco piu' di 1 minuto (60-70 secondi), che e' un valore abbastanza differente dal tuo. possibile spiegazione: il tuo HW e' molto piu' lento del mio. giusto per curiosita', io uso una workstation con un Intel i7 che ha 8 cores fisici da 3.0 GHz, 32 GB RAM e un SSD. volevo chiedere se faccio un uso corretto dei virtualKNN oppure ho scritto male la query? si puo' scrivere meglio invertendo l'ordine delle tavole. SELECT a.fid as pk_strade, a.distance as distance, zz.pk as pk_punti FROM inc2k18Palermo as zz JOIN knn as a ON (f_table_name = 'strade_palermo' AND f_geometry_column = 'geom' AND ref_geometry = zz.geom AND max_items = 1) riscritta in questa seconda forma gira in 45-50 secondi; la differenza non e' abissale, ma con un problema simile ma con maggiori dimensioni potrebbe facilmente diventare molto piu' consistente. nota metodologica: == il query oprimizer di SQLite non e' particolarmente sofisticato; molto spesso indovina la strategia ottimale di accesso ai dati, ma qualche volta imbocca la strada sbagliata. capita soprattutto quando ci sono di mezzo le VirtualTables, che per SQLite sono "oggetti buffi" dal comportamento non predicibile, ed ai quali viene sempre assegnata la minima priorita' possibile. visto che sia lo SpatialIndex che il KNN sono proprio basati sulle VirtualTable di tipo R*Tree, occorre sempre stare attenti a come si scrivono le query SQL, perche' potrebbe avere un notevole impatto sui tempi di esecuzione. le seconda forma toglie il query optimizer dall'imbarazzo, perche' diventa chiarissimo che la sequenza attesa e': 1. pescati una riga dagli incroci 2. e poi vatti a cercare via KNN la geometria piu' vicina. regola empirica a braccio: ogni volta che hai il sospetto che una query basata su R*Tree giri lenta prova sempre a riscrivere la tua query "rovesciata". 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
Re: [Gfoss] QGIS: richiesta lumi su geometria "collassata"
On Fri, 19 Mar 2021 09:04:14 +0100, Luca Manganelli wrote: Ciao a tutti, qualcuno può spiegarmi cosa si intende per geometria totalmente collassata? ciao Luca, una geometria collassata e' semplicemente una geometria invalida che pretende di essere quello che in effetti non e'. qualche esempio: un LINESTRING che contiene un unico punto, o che magari contiene piu' punti ma tutti con identiche coordinate. formalmente e' un Linestring, ma in termini sostanziali e' un POINT. un POLYGON RING con meno di 4 vertici (anche qua tenendo conto di eventuali vertici ripetuti e del vincolo per cui il primo e l'ultimo devono coincidere). anche qua apparentemente sembra un'area, ma in effetti si riduce ad essere un POINT o al massimo un LINESTRING. e di conseguenza moltissimi algoritimi normalmente applicabili ai POLYGON falliscono, fino eventualmente a provocare qualche spettacoloso crash :-P 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
Re: [Gfoss] OSGeo4W shell utility per unzippare
On Thu, 10 Sep 2020 11:32:59 +0200, Totò Fiandaca wrote: Ciao Luca, purtroppo non ci sono: C:\Users\Public\Desktop\OSGeo4W>unzip "unzip" non è riconosciuto come comando interno o esterno, un programma eseguibile o un file batch. C:\Users\Public\Desktop\OSGeo4W>7z "7z" non è riconosciuto come comando interno o esterno, un programma eseguibile o un file batch. C:\Users\Public\Desktop\OSGeo4W>7za "7za" non è riconosciuto come comando interno o esterno, un programma eseguibile o un file batch. prova a cercare qua: oltre alle versioni con inerfaccia grafica ci sono anche i corrispondenti command line precompilati per WinZoz https://www.7-zip.org/download.html 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
Re: [Gfoss] Automatizzare l'intersezione con un TRIGGER
On Sat, 28 Dec 2019 18:19:02 +0100, Massimiliano Moraca wrote: sostituendo con buffer ottengo questo messaggio di errore nel momento in cui voglio salvare il poligono creato: Could not commit changes to layer buffer Errors: ERROR: 1 feature(s) not added. Provider errors: PostGIS error while adding features: ERRORE: la query non ha una destinazione per i dati restituiti HINT: Se vuoi scartare i risultati di una SELECT, utilizza PERFORM. CONTEXT: funzione PL/pgSQL intersection_function() riga 3 a istruzione SQL Massimiliano, sempre premettendo che io conosco bene i Triggers di SQLite e molto poco quelli di PostgreSQL (e paiono sostanzialmente diversi). ragionando a fil di logica l'errore dovrebbe nascere dal fatto che tu nel tuo trigger-body in effetti ti limiti a fare una SELECT, ma non specifichi mai da nessuna parte che quei valori ottenuti dalla SELECT poi li vuoi inserire nella tavola di output. verosimilmente quello che ti serve e' definire uno statement SQL piu' o meno di questo tenore: INSERT INTO intersection_output (idb, idp, geom) SELECT a.idb, b.idp, ST_Intersection(a.geom, b.geom) FROM . etc etc ... === hint: un trigger non e' altro che un normalissimo statement SQL (piu' o meno complesso) che scatta automaticamente tutte le volte che si realizza un determinato evento. di per se non ha nulla di "magico", tutte le azioni che intendi fare te le devi definire tu una per una. 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
Re: [Gfoss] Automatizzare l'intersezione con un TRIGGER
Massimiliano, premetto che non ho nessuna familiarita' con i Triggers di PostreSQL, ma conosco molto bene quelli di SQLite. CREATE TRIGGER make_intersection AFTER INSERT ON intersection_output con la clausola AFTER INSERT di cui sopra tu stai chiedendo a Postgres di attivare il tuo trigger ogni volta che viene inserita una nuova riga nella tavola "intersection_output" ma da tutta la spiegazione precedente io ho capito che questa (come del resto dice il nome) e' appunto la tavola di output destinata a collezionare le intersezioni. sembra che tu le tue INSERT con QGIS le fai invece su "polygons", e di conseguenza quel trigger non scattera' mai. almeno a lume di naso quel trigger va definito come: CREATE TRIGGER make_intersection AFTER INSERT ON polygons ciao Sandro On Sat, 28 Dec 2019 17:21:17 +0100, Massimiliano Moraca wrote: Salve a tutti, sto dedicando questi giorni a familiarizzare con i TRIGGER in PostGIS prendendo spunto da questa[1] guida. Sono riuscito a creare automaticamente un buffer a partire dall'editing di un vettore lineare e quello che voglio fare ora è eseguire un *intersection* tra i buffer e alcuni poligoni. Ho quindi due tabelle principali: *buffer* e *polygons*; l'output dell'intersezione deve confluire in una tabella in cui verranno riportati anche gli id dei poligoni da cui è scaturita l'intersezione(idb per buffer e idp per polygons). La tabella in cui confluiranno questi dati l'ho chiamata *intersection_output*. Ho scritto quindi questo TRIGGER: CREATE OR REPLACE FUNCTION intersection_function() RETURNS trigger AS $BODY$ BEGIN SELECT a.idb, b.idp, ST_Intersection(a.geom, b.geom) as geom FROM buffer AS a, polygons AS b WHERE ST_Intersects(a.geom, b.geom); RETURN NEW; END; $BODY$ LANGUAGE 'plpgsql'; CREATE TRIGGER make_intersection AFTER INSERT ON intersection_output FOR EACH ROW EXECUTE PROCEDURE intersection_function(); Mi aspetto quindi che ogni volta che creo un poligono, ad esempio con QGIS, nella tabella *buffer*, esso venga intersecato con il o i poligoni, presenti in *polygons*, che vengono coperti dall'area di buffer ed il risultato di questa intersezione deve essere scritto in *intersection_output*. Il problema che riscontro è che la tabella delle intersezioni resta sempre vuota nonostante sia le geometrie di buffer che di polygons siano in 4326. Sicuramente sbaglio io qualcosa ma non mi è chiaro dove. [1] http://www.postgresqltutorial.com/creating-first-trigger-postgresql/ *ing.Massimiliano Moraca* *Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS* *P.IVA*: 08700081212 *CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*) *WEB*: www.massimilianomoraca.it * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1* ___ 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 ___ 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
Re: [Gfoss] Proj e GDAL
On Wed, 12 Jun 2019 16:41:39 +0200, Massimiliano Moraca wrote: Noto che l'errore che compivo era scrivere _./configure --with-proj4=/usr/local_ anzicchè _./configure --with-proj=/usr/local _ sugggerimento: e' una caratteristica standard di tutti gli script ./configure; se tu chiami ./configure --help ti uscira' fuori un paginone bello lungo con tutte le possibili opzioni supportate da quello specifico script. merita sempre leggersele con estrama attenzione, perche' spesso la soluzione di molti problemi di configurazione apparentemente insolubili e' nascosta proprio li dentro. consiglio ancora piu' utile: se ci fai caso ogni volta che fai girare ./configure ti genera un file che si chiama config.log, e che ti spiega per filo e per segno tutto quello che e' stato fatto, inclusi eventuali errori. anche questo e' fondamentale per capire dove eventualmente si impiglia. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Proj e GDAL
On Wed, 12 Jun 2019 16:03:53 +0200, Massimiliano Moraca wrote: Ho rieseguito il processo di installazione delle proj6 per sicurezza ma dopo *./configure* mi ritrovo sempre lo stesso messaggio di errore di cui sopra ma ora stai chiamando ./configure "liscio" (senza argomenti) oppure gli stai passando anche la direttiva che lo punta sulla libreria custom ? ./configure --with-proj=/usr/local se hai fatto tutto secondo le regole e continua a non funzionare non ci rimane che ricorrerre alle variabili d'ambiente del gcc, che in genere risolvono tutti i conflitti quando ci sono piu' versioni della medesima libreria: export "CPPFLAGS=-I/usr/local/include" export "LDFLAGS=-L/usr/local/lib" ./configure --with-proj=/usr/local microspiegazione: la prima export forza gcc a cercare gli headers per prima cosa dentro ad /usr/local/include la seconda forza il linker a cercare le librerie dentro ad /usr/local/lib con la massima priorita'; solo se non le trova continuera' poi a cercarle tra i system packages. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Proj e GDAL
On Wed, 12 Jun 2019 03:46:33 -0700 (MST), Massimiliano Moraca wrote: , sto riscontrando difficoltà con l'installazione di GDAL. In particolare mi viene restituito questo messaggio di errore dopo aver digitato *./configure*: /checking for PROJ >= 6 library... checking for proj_create_from_wkt in -lproj... no checking for internal_proj_create_from_wkt in -lproj... no checking for internal_proj_create_from_wkt in -linternalproj... no configure: error: PROJ 6 symbols not found/ Massimiliano, immagino che sul tuo PC ci fosse gia' installata una precedente versione della PROJ quindi molto probabilmente ora che hai fatto la tua build partendo dai sorgenti ti trovi con _DUE_ diverse versioni della PROJ installate, quella standard di sistema e la tua custom. lo script ./configure in genere va sempre a cercarsi le librerie e gli headers nelle directories standard dei system packages, e quindi finisce per pescare quelle vecchie che non supportano le nuov API della PROJ.6, e quindi fallisce. ma il ./configure della PROJ ti consente di avvisarlo del fatto che intendi usare una PROJ "fuori standard" in modo tutto sommato facile e diretto: ./configure --with-proj=/usr/local giusto nel caso che non funzioni, dovresti verificare se la tua libreria si trova effettivamente dentro a /usr/local/lib, mentre gli header files li dovresti trovare dentro a /usr/local/include se non li trovi in queste posizioni, la cosa piu' facile e' immaginare che tu ti sei dimenticato di intallare la PROJ.6 custom dopo averla compilata ... poco male, basta questo comando per rimediare: sudo make install 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. 796 iscritti al 28/12/2017
Re: [Gfoss] geolocalizzazione database Traffic Message Channel del CCISS?
On Fri, 24 May 2019 12:11:39 +0200, Alessandro Perego wrote: forse in gradi: 012,10177° 43,81899° è plausibile? decisamente molto plausibile; quel punto cade esattamente in corrispondenza dell'incrocio tra due strade provinciali, una posizione molto realistica in un contesto di sicurezza stradale. saremmo sull'appennino tosco-romagnolo nel comune di Verghereto (FC) e le due provinciali sono la 130 e la 135 Napo, ti dice qualcosa di sensato ? ciao Sandro Il 24/05/2019 11:56, Maurizio Napolitano ha scritto: Ho visto che il CCISS - Centro di Coordinamento delle Informazioni sulla Sicurezza Stradale offre le banda dati con le posizioni dei RDS-TMC https://www.cciss.it/web/cciss/database-rds-tmc Sul sito ci sono diversi file zip che contengono file .dat e file .fdo. I primi sono file strutturati come CSV, i secondi, invece, non ho idea. Aprendo il file POINTS.DAT si trova il campo XCOORD e YCOORD solo che i valori che assume non riesco ad interpretarli. Es. XCOORD;YCOORD +01210177;+4381899; Suggerimenti? Grazie ___ 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Punti random nel poligono soluzione SpatiaLite Help
On Wed, 15 May 2019 12:16:48 -0700 (MST), pigreco wrote: C'è qualche suggerimento didattico su come risolvere tutto in una logica SQL (in sqlite) o la strada preferenziale è fare dialogare spatialite con Python (o altro) e qualche while loop? chiaramente la strada piu' liscia, semplice e veloce e' quella di scrivere un banale programmicchio in C, C++, Java, Python o qualsiasi altro linguaggio di programmazione che supporti i loops. SQL e' un linguaggio meraviglioso, ma e' comunque un linguaggio basato sul paradigma dichiarativo; tutti gli altri (C, Java etc) sono invece linguaggi basati sul paradigma imperativo. nei linguaggi dichiarativi va specificato quale risultato finale si intende ottenere, dopo di che ci pensera' il linguaggio stesso ad identificare in modo ottimale tutte le azioni necessarie per arrivare a quel risultato. tutto l'opposto avviene nei linguaggi imperativi, in cui e' il programmatore a dovere specificare minuziosamente tutte le azioni necessarie per arrivare al risultato finale. non e' che un paradigma sia superiore all'altro; sono profondamente diversi, e ciascuno di essi e' piu' adatto ad alcuni problemi piuttosto che ad altri. e' un po' come avere a disposizione un coltello da cucina ed un'ascia; se devi affettare del pane l'ascia sara' decisamente poco pratica, esattamente come il coltello da cucina si rivelera' inadeguato per abbattere una quercia. venendo allo specifico del tuo problema, lo possiamo sintetizzare in questo pseudo-algoritmo: 0. inizializzazione: definisci il poligoo ed azzeri il contatore 1. se il contatore ha raggiunto il valore massimo vai al punto 4) altrimenti procedi al punto successivo. 2. calcola un punto random all'interno del BBOX del poligono 3. verifica se il punto cade realmente all'interno della superficie del poligono 3-A) si: inseriscilo nella tavola, incrementa il contatore e torna al punto 1) 3-B) no: torna al punto 1) senza incrementare il contatore 4. fine questo e' un classico loop, e tutti i linguaggi di programmazione imperativi sono fatti apposta per rendere semplice l'esecuzione dei loops. SQL invece segue tutt'altra logica, ed offre solo la WITH RECURSIVE per mettere in piedi (in modo abbastanza macchinoso e contorto) qualcosa che assomiglia ad un loop. conclusione: quando usare un loop e' assolutamente critico (come nel tuo caso, visto che non puoi sapere in anticipo se/quanti punti random cadranno effettivamente dentro al poligono) pretendere di usare solo SQL puro non e' la scelta ottimale. e' un po' come cercare di affettare pane e salame con l'ascia; se usi invece il coltello da cucina fatichi molto meno. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] SpatiaLite conteggio righe tabelle database
On Mon, 29 Apr 2019 23:36:01 -0700 (MST), pigreco wrote:
a.furieri wrote
Ci riesco con questa, ma sembra bruttina:
SELECT tbl_name,
eval('select count(*) from ' || tbl_name ) AS nro_righe
FROM sqlite_master
where type='table'
and name not like '%geom%'
and name not like '%spatial%'
and name not like '%sql%'
and name not like '%raster%'
and name not like '%SE%'
and name not like '%vector_%'
and sql not like '%geom%';
SELECT tbl_name,
eval('SELECT count(*) FROM "' || tbl_name || '"') AS
nro_righe
FROM sqlite_master
WHERE type='table'
AND name NOT IN (SELECT f_table_name FROM geometry_columns)
ORDER BY tbl_name;
ciao Sandro
Buongiorno e grazie per la risposta,
la query proposta ottiene tutte le tabelle del database tranne quelle
con
geometry e quindi prende anche quelle tabelle del database che non ho
creato
direttamente io, es: prende le tabelle idx..., SE ecc...
il mio intendo era quello di 'acchiappare' solo le tabelle che ho
creato e
popolato io.
SELECT tbl_name,
eval('SELECT count(*) FROM "' || tbl_name || '"') AS nro_righe
FROM sqlite_master
WHERE type = 'table' AND sql NOT LIKE 'CREATE VIRTUAL TABLE %'
AND name NOT IN (SELECT f_table_name FROM geometry_columns)
AND name NOT IN (SELECT 'idx_' || f_table_name || '_' ||
f_geometry_column
FROM geometry_columns WHERE spatial_index_enabled = 1)
AND name NOT IN (SELECT 'idx_' || f_table_name || '_' ||
f_geometry_column || '_node'
FROM geometry_columns WHERE spatial_index_enabled = 1)
AND name NOT IN (SELECT 'idx_' || f_table_name || '_' ||
f_geometry_column || '_parent'
FROM geometry_columns WHERE spatial_index_enabled = 1)
AND name NOT IN (SELECT 'idx_' || f_table_name || '_' ||
f_geometry_column || '_rowid'
FROM geometry_columns WHERE spatial_index_enabled = 1)
AND name NOT IN ('geometry_columns', 'geometry_columns_auth',
'geometry_columns_time')
ORDER BY tbl_name;
Note:
===
1. con queste modifiche filtra automaticamente qualsiasi
SpatialIndex e tutte le VirtualTables
2. l'ultima lista (geometry_columns etc) va espansa fino
a definire l'elenco completo di tutte le meta-tavole
utilizzate internamente da SpatiaLite.
lavoro noiosetto ma per nulla difficoltoso, basta solo
un pizzico di pazienza.
3. non copre eventuali TopoGeometry, TopoNetworks e
RasterCoverages, ma non credo che ti interessino.
nal caso, il problema e' facilmente risolvibile
ricalcando lo schema applicato agli Spatial Index;
occorre fare una subquery sulla metatavola madre
per ricavare tutti i nomi delle tavole figlie.
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.
796 iscritti al 28/12/2017
Re: [Gfoss] SpatiaLite conteggio righe tabelle database
On Mon, 29 Apr 2019 12:54:05 -0700 (MST), pigreco wrote:
Salve a tutti,
questa query:
SELECT f_table_name,
eval('select count(*) from ' || f_table_name) AS nro_feature
FROM geometry_columns;
restituisce a video una tabella con nome geo-tabella e relativo
numero di
righe, ovvero
se un database ha 5 geo-tabelle restituirà una tabella con 5 righe e
due
colonne: la prima colonna con i nomi delle geo-tabelle e la seconda
il
numero complessivo di feature.
Questa query utilizza la tabella 'geometry_columns' e quindi non
tiene conto
delle semplici tabelle (cioè quelle senza il campo geometry).
Come potrei scrivere una analoga query per conteggiare le righe delle
sole
tabelle (quelle senza geometry)??
Ci riesco con questa, ma sembra bruttina:
SELECT tbl_name,
eval('select count(*) from ' || tbl_name ) AS nro_righe
FROM sqlite_master
where type='table'
and name not like '%geom%'
and name not like '%spatial%'
and name not like '%sql%'
and name not like '%raster%'
and name not like '%SE%'
and name not like '%vector_%'
and sql not like '%geom%';
SELECT tbl_name,
eval('SELECT count(*) FROM "' || tbl_name || '"') AS nro_righe
FROM sqlite_master
WHERE type='table'
AND name NOT IN (SELECT f_table_name FROM geometry_columns)
ORDER BY tbl_name;
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.
796 iscritti al 28/12/2017
Re: [Gfoss] Help
On Wed, 6 Feb 2019 12:09:22 +0100, Daniela Pianelli wrote: Buongiorno, Qualcuno sa cosa significhi questo errore: REQUEST_DENIED Requests to this API must be over SSL. Load the API with "https://; instead of "http://;. To fix, *change the URL in line 288 of mmqgis_library.py* to begin Daniela, pare abbastanza facile capire cosa significa. stai cercando di interrogare qualche web service utilizzando il protocollo non sicuro (non cifrato) HTTP; ma quel web service invece pretende l'uso del protocollo sicuro (cifrato) HTTPS e quindi rigetta la tua richiesta. fidandosi del messaggio dovresti correggere la URL che appare alla riga 288 del sorgente Python mqgis_library.py 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Spatialite - calcolo angolo zenith
On Mon, 4 Feb 2019 04:13:26 -0700 (MST), Falz wrote:
Alla fine ho risolto così con spatialite NEXTGEN, facendo anche un
confronto
tra le varie formule, con la bellezza del calcolo 3d =)
--I calcoli geodetici vogliono solo epsg=4326 altrimenti non
funzionano!
--CALCOLA RELAZIONE TRA DUE PUNTI: (epsg=4326 WGS84, epsg=25832
ETRS89/UTM_zone_32N)
select
st_distance(st_transform(geoA, 25832), st_transform(geoB, 25832)) as
'distanza_2d',
st_3ddistance(st_transform(geoA, 25832), st_transform(geoB, 25832))
as
'distanza_3d',
degrees(st_azimuth(st_transform(geoA, 25832), st_transform(geoB,
25832))) as
'azimuth',
degrees(asin((st_z(geoA)-st_z(geoB))/st_3ddistance(st_transform(geoA,
25832), st_transform(geoB, 25832 as 'angolo_zenitale',
geodesicarclength(geoA, geoB) as 'arcodistanza',
geodesicchordlength(geoA, geoB) as 'corda',
degrees(geodesiccentralangle(geoA, geoB)) as 'angolo_centrale',
geodesicarcheight(geoA, geoB) as 'h_arco'
from
(select
st_geomfromtext('POINTZ(11.040796 46.139230 2071)', 4326) as geoA,
st_geomfromtext('POINTZ(11.160461 46.195844 727.5)', 4326) as geoB);
Simone,
hai scritto l'elogio perfetto dello Spatial SQL :-D
quando hai uno strumento di calcolo e di analisi cosi' flessibile
e potente, non e' mai un problema insormontabile se non trovi la
soluzione pre-cotta che ti serve pronta all'uso.
basta un pizzico di fantasia e puoi sempre provare a scrivertela
da solo appoggiandoti alle tantissime funzioni SQL disponibili.
direi che il tuo e' un bel caso da manuale. ;-)
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.
796 iscritti al 28/12/2017
Re: [Gfoss] Spatialite - calcolo angolo zenith
On Wed, 30 Jan 2019 11:40:38 +0100 (CET), falcerisim...@inwind.it wrote: Buongiorno, ho un problema con due punti 3d con quote differenti, qualcuno sa come si fa a calcolare l'angolo zenitale con spatialite, o postgis? L' azimuth è select degrees(st_azimuth(geoA, geoB)) as 'azimuth'; Simone, l'implementazione di SpatiaLite per ST_Azimuth dovrebbe essere esattamente la medesima come per PostGIS, visto che il calcolo vero e proprio lo fanno la lwgeom (per PostGis) e la librttopo (per splite) che e' semplicemente un porting della lwgeom. per quanto vedo dai sorgenti funziona solo per punti 2D, il caso 3D non mi pare che venga mai preso in considerazione. spero di sbagliarmi, ma non mi pare che quanto chiedi rientri tra le opzioni supportate. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Sicurezza informatica
On Sat, 26 Jan 2019 18:08:40 +0100, Alessandro Fanna wrote: Io usavo questo: https://haveibeenpwned.com Da poco il tizio che gli sta dietro ha aggiunto una pagina per testare anche le pw confrontandole con il mega archivio postato qualche settimana fa su mega.nz: mi sono divertito a controllarne di vecchie con lusinghieri risultati. ciao Alessandro, sono la stessa identica cosa. Mozilla ha firmato un accordo con Have I Been Pwned che gli consente di consultare la loro banca dati. cambiano le interfacce Web, ma alla fine i dati per la verifica sono sempre i soliti. il fatto che ora ci sia l'endorsement ufficiale ed autorevole di Mozilla verosimilmente aiutera' ad far diventare sempre piu' vasta e generalizzata l'adozione di questo tipo di strumenti "difensivi". 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Sicurezza informatica
On Sat, 26 Jan 2019 14:09:51 +0100, liste DOT girarsi AT posteo DOT eu wrote: Non è che poi con questo modo gli si da una mano a creare la lista di indirizzi mancanti, visto che anche firefox può essere vittima a sua volta? pare di no, ci hanno gia' pensato: e' spiegato in dettaglio nelle note tecniche: https://blog.mozilla.org/security/2018/06/25/scanning-breached-accounts-k-anonymity/ la mailbox oggetto della ricerca viene immediatamente trasformata in un hash corrispondente. la ricerca sul database delle violazioni utilizza solo l'hash, e quindi il rischio di "furti a catena" dovrebbe essere scongiurato visto che Mozilla assicura che non terra' mai nessuna traccia permanente delle mailbox oggetto di verifica. 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. 796 iscritti al 28/12/2017
[Gfoss] Sicurezza informatica
OT ma non troppo ... sicuramente avrete notato che si stanno moltiplicando a dismisura gli allarmi relativi ai furti delle nostre identita' digitali (caselle e-mail, credenziali di accesso ai social media, passwords, indirizzari dei contatti etc). c'e' poco da fare, e' un fenomeno in continua crescita, e anche se non ne siete consapevoli e' altamente probabile che anche molti di voi siano rimasti vittima in passato di alcuni di questi spiacevoli episodi. fortunatamente Firefox mette a disposizione uno strumento denominato Monitor che consente di verificare se, quando e come siete eventualmente rimasti vittime di un furto di identita' digitale. consultare la banca dati di Firefox Monitor e' facilissimo: basta semplicemente connettersi a questa URL: https://monitor.firefox.com/ e poi inserire l'indirizzo dela propria casella di posta elettronica; avrete immmediatamente la risposta con tutti i dettagli. nota: ho fatto un piccolo controllo a campione sui miei contatti abituali, ed ho scoperto che oltre la meta' risultano tra le vittime di almeno un furto di identita' digitale (alcuni arrivano a collezionare anche cinque e sei furti ...). verificare la propria situazione e' caldamente consigliato. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] La formichina lavoratrice...
On Wed, 19 Dec 2018 20:49:48 +0100, Andrea Peri wrote: Tutti i giorni, molto presto, arrivava in ufficio la Formica produttiva e felice. Là trascorreva i suoi giorni, lavorando e canticchiando una vecchia canzone d’amore. Era produttiva e felice ma, ahimé, non era supervisionata. Il Calabrone, gestore generale, considerò la cosa impossibile e creò il posto di supervisore, per il quale assunsero uno Scarafaggio con molta esperienza. La prima preoccupazione dello Scarafaggio fu standardizzare l’ora di entrata e di uscita e preparà³ pure dei bellissimi report. la storiellina non lo dice, ma e' assolutamente ovvio ed evidente che Scarafaggio era laureato in Ingegneria Gestionale :-) e sicuramente non si limito' a produrre bellissimi report, ma si dette un gran da fare per arrivare a codificare minuziosamente tutte le procedure standard ISO 9001 destinate ad ingabbiare ogni fase del lavoro di Formichina in una rigida griglia predefinita dove non c'era piu' nessuno spazio per la fantasia, per la creativita' e per l'iniziativa individuale. Ben presto la Formica produttiva e felice smise di canticchiare le sue melodie e comincià³ a lamentarsi di tutto il movimento di carte che c’era da fare. qua Formichina dimostra tutti i propri gravi limiti; evidentemente non ha la stoffa giusta per integrarsi in una moderna organizzazione aziendale al passo con i tempi :-P Ma un giorno il gestore generale, al rivedere le cifre, si rese conto che l’unità , nella quale lavorava la Formica produttiva e felice, non rendeva più tanto. E così contatto’ il Gufo, prestigioso consulente, perché facesse una diagnosi della situazione. Il Gufo rimase tre mesi negli uffici ed emise un cervellotico report di vari volumi e di vari milioni di euro, che concludeva: “C’é troppa gente in questo ufficio.” E così il gestore generale seguà il consiglio del consulente e licenziò la Formica incavolata, che prima era produttiva e felice. e cosi' tutto finisce in gloria; una volta eliminati i soggetti anti-sociali come Formichina finalmente l'azienda puo' vantarsi a pieno titolo di essere certificata ISO 9001. e' il trionfo del progresso e della modernita' :-D ciao Sandro p.s. chiunque abbia avuto occasione di andare incontro a qualche infortunio con la propria linea telefonica+adsl capisce immediatamente tutti i notevoli vantaggi offerti dalle piu' moderne organizzazioni aziendali. vuoi mettere l'efficienza fantascientifica di un call-center romeno o albanese che segue alla lettera le procedure di assistenza codificate rispetto all'obsoleto tecnico Formichina che veniva di persona a verificare il problema ? (e che magari era pure capace di inventarsi su due piedi una fix estemporanea ma efficare) :-D ___ 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. 796 iscritti al 28/12/2017
Re: [Gfoss] ERROR: out of memory for query result
On Sat, 24 Nov 2018 12:46:39 +0100, Massimiliano Moraca wrote: Ciao Sandro, avevo editato il primo post con una indicazione che avevo dimenticato, la ricopio qui: _EDIT: uso PostgreSQL 10 ed ho settato, in postgresql.conf, shared_buffers a 2560MB _ Mi ero letto la documentazione e proprio per questo ho aumentato l'uso della RAM ma il risultato è invariato Massimiliano, temo che aggiustare solo "shared_buffers" non basti affatto, presumo che dovresti arrangiare anche "work_mem", e forse anche altri tra i molti parametri che influenzano le allocazioni di RAM. prova a leggerti questo: https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server ciao Sandro Il giorno sab 24 nov 2018 alle ore 12:31 ha scritto: On Sat, 24 Nov 2018 03:56:21 -0700 (MST), Massimiliano Moraca wrote: > Salve a tutti! > Sto provando a fare un left join con PostGIS tra un vettore di linee > con > poco meno di 2.5milioni di elementi ed una tabella con circa 4mila > elementi. > > Questa è la sintassi che sto usando: > > /SELECT > a.geom, > a.fid, > a.id [1], > a.nom, > b.width_cat, > b.importance > FROM > france_rivers_bdtopo_hydrographie as a > LEFT JOIN principal_rivers_nogeom as b ON a.nom = b.toponyme_lower;/ > > Dopo un po' di minuti di attesa, pgAdmin 4 mi da l'errore in oggetto. > > Ho un pc con CPU i7-4970k, 16GB di RAM DDR3, un SSD da 120GB con 20GB > liberi; ho monitorato tramite "Gestione attività" di Windows 10 l'uso > della > RAM e non ha mai sforato i 10GB nei test che ho effettuato. > > Come è possibile che ho quell'errore secondo voi? > Massimiliano, PostgreSQL ha una gestione molto sofisticata della RAM, e tutto quanto dipende fortemente da come hai impostato i files della configurazione. di norma la configurazione standard che viene installata automaticamente e' molto conservativa e fortemente prudenziale; va bene per piccole macchine poco potenti e con dotazioni molto limitate, mentre tende a sfruttare poco e male le macchine con dotazioni piu' generose. in soldoni, il fatto che tu abbia installato 16GB di RAM non implica automaticamente il fatto che PostgreSQL la sfruttera' tutta quanta: si fermera' alle soglie indicate dalla configurazione corrente, che verosimilmente saranno molto piu' sparagnine. prova a leggerti la doc di Postgres per capire meglio come funziona il file postgresql.conf https://www.postgresql.org/docs/9.4/runtime-config-resource.html [2] ciao Sandro ___ Gfoss@lists.gfoss.it [3] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss [4] 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. 796 iscritti al 28/12/2017 Links: -- [1] http://a.id [2] https://www.postgresql.org/docs/9.4/runtime-config-resource.html [3] mailto:Gfoss@lists.gfoss.it [4] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss [5] mailto:a.furi...@lqt.it ___ 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. 796 iscritti al 28/12/2017
Re: [Gfoss] ERROR: out of memory for query result
On Sat, 24 Nov 2018 03:56:21 -0700 (MST), Massimiliano Moraca wrote: Salve a tutti! Sto provando a fare un left join con PostGIS tra un vettore di linee con poco meno di 2.5milioni di elementi ed una tabella con circa 4mila elementi. Questa è la sintassi che sto usando: /SELECT a.geom, a.fid, a.id, a.nom, b.width_cat, b.importance FROM france_rivers_bdtopo_hydrographie as a LEFT JOIN principal_rivers_nogeom as b ON a.nom = b.toponyme_lower;/ Dopo un po' di minuti di attesa, pgAdmin 4 mi da l'errore in oggetto. Ho un pc con CPU i7-4970k, 16GB di RAM DDR3, un SSD da 120GB con 20GB liberi; ho monitorato tramite "Gestione attività" di Windows 10 l'uso della RAM e non ha mai sforato i 10GB nei test che ho effettuato. Come è possibile che ho quell'errore secondo voi? Massimiliano, PostgreSQL ha una gestione molto sofisticata della RAM, e tutto quanto dipende fortemente da come hai impostato i files della configurazione. di norma la configurazione standard che viene installata automaticamente e' molto conservativa e fortemente prudenziale; va bene per piccole macchine poco potenti e con dotazioni molto limitate, mentre tende a sfruttare poco e male le macchine con dotazioni piu' generose. in soldoni, il fatto che tu abbia installato 16GB di RAM non implica automaticamente il fatto che PostgreSQL la sfruttera' tutta quanta: si fermera' alle soglie indicate dalla configurazione corrente, che verosimilmente saranno molto piu' sparagnine. prova a leggerti la doc di Postgres per capire meglio come funziona il file postgresql.conf https://www.postgresql.org/docs/9.4/runtime-config-resource.html 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Spatialite - fusione massiva di svariati shp in un unico layer
On Wed, 14 Nov 2018 18:52:02 +0100 (CET), falcerisim...@inwind.it wrote: Ciao! Gentilmente, essendo poco pratico con le shell cli, volevo fondere centinaia di shp con spatialite_gui in un unico layer "fusion" con uno script sql. Ho provato con ogr2ogr, ma crea una abnorme schifezza inutilizzabile (virtual FDO...). gdal fa un ottimo lavoro con SpatiaLite, sei tu che stai chiamando ogr2ogr nel modo sbagliato. il driver SQLite di GDAL e' in grado di gestire diversi formati: FDO, GPKG e SpatiaLite. se vuoi usare il formato SpatiaLite devi impostare un'opzione apposita, che se non erro dovrebbe essere -dsco SPATIALITE=YES comunque leggiti la doc del driver GDAL, vedrai che in fondo ci sono esempi specifici per SpatiaLite https://www.gdal.org/drv_sqlite.html Ho appenda scoperto la funzione Importshp(path, nome_nuova_tabella, UTF-8); Come dovrei settare per ogni shp senza passare per le virtual tables? se il tuo problema e' "fondere" qualche centinaio di SHP in una singola Spatial Table la ImportSHP() ti sara' poco utile, visto che per ogni singolo SHP richiede di creare una nuova tavola. direi che ogr2ogr si adatta meglio al tuo caso specifico. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Spatialite - calcolo automatico lunghezze polilinee 3D
On Wed, 14 Nov 2018 14:16:06 +0100, a.furi...@lqt.it wrote:
On Wed, 14 Nov 2018 13:10:46 +0100 (CET), falcerisim...@inwind.it
wrote:
La tabella fa il calcolo grazie ai triggers e confronta con epsg
4326 e 32632.
Son graditi pareri o suggerimenti...
perche' mai usi una roba fragile, delicata, lenta, poco efficiente
e poco affidabile come una VirtualShape per importare i dati dallo
Shapefile ?
guarda che da diversi anni ormai esiste un'apposita funzione SQL
per caricare al volo uno Shapefile creando una Spatial Table:
ImportSHP()
http://www.gaia-gis.it/gaia-sins/spatialite-sql-5.0.0.html
seconda valutazione dopo valutazione piu' ponderata.
ma ne vale proprio la pena di mettere in piedi tutto questo
ambaradan di triggers giusto per calcolare le lunghezze 2D/3D ?
in linea di massima i buoni principi alla base dei DBMS relazionali
(le famose regole auree del Dr. Codd) memorizzare in modo statico
e permanente un valore che per sua natura sarebbe facilmente
derivabile in modo dinamico da altri dati non e' mai consigliato.
per almeno due ottime ragioni:
- occorre piu' spazio per memorizzare il dataset; si impone un
forte rallentamento a carico di tutte le INSERT/UPDATE
- a causa di malfunzionamenti o altri difetti piu' o meno
fantasiosi, potresti trovarti alla fine con una situazione
che non e' logicamente consistente.
del tipo che sulla colonna ti risulta una lunghezza X,
mentre invece se calcoli la ST_Length() ti risulta Y.
la regola aurea superiore a tutte e' sempre il principio
KISS (keep it simple, stupid).
hai preso in considerazione l'ipotesi di risolvere il tuo
problema in modo molto piu' canonico, e cioe' tramite la
definizione di una banalissima View ?
create table linee3d
(pk integer primary key autoincrement,
name text,
note text);
select addgeometrycolumn('linee3d','geom',4326,'LINESTRING','XYZ');
ceate view v_linee3d as
select pk as rowid, name as name, note as note, geom as geom,
st_length(geom) as lung_2d_wgs84,
st_3dlength(geom) as lung_3d_wgs84,
st_length(st_transform(geom,32632)) as lung_2d_wgs84utmz32n,
st_3dlength(st_transform(geom,32632)) as lung_3d_wgs84utmz32n;
questa soluzione non incrementa lo spazio di storage, assicura
sempre il perfetto allineamento dei dati, garantisce INSERT/UPDATE
al top della velocita' mentre rallenta sicuramente in lettura,
ma probabilmente non in modo intollerabile.
se non hai problemi molto seri di assoluta criticita' dei tempi
di risposta in lettura questa soluzione e' certamente preferibile,
se non altro perche' rispetta tutte le regole base per la
progettazione normalizzata delle banche dati senza avventurarsi
in funambolismi acrobatici potenzialmente rischiosi.
ciao Sandro
lung_2d_wgs84 double,
lung_3d_wgs84 double,
lung_2d_wgs84utmz32n double,
lung_3d_wgs84utmz32n double,
___
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.
796 iscritti al 28/12/2017
Re: [Gfoss] Spatialite - calcolo automatico lunghezze polilinee 3D
On Wed, 14 Nov 2018 13:10:46 +0100 (CET), falcerisim...@inwind.it wrote: Ciao a tutti, a chi interessa, condivido uno script sql per creare una tabella 3dpolylines in spatialite NEXTGEN con calcolo automatico. Purtroppo Qgis 3.4.1 non è in grado gestire le polilinee 3d spatialite (Errore di SQLite: causa sconosciuta). Solo importando shp-3d da spatialite funziona. Idem per editing della geom. su questo non so proprio cosa dirti, prova a sentire la community di QGIS. pare comunque decisamente strano, visto che il formato binario delle geometrie di spatialite (comprese quelle 3D) non ha subito nessun cambiamento (neppure microscopico), durante gli ultimi otto anni, e per quanto mi risulta con le precedenti versioni di QGIS funzionava tutto correttamente. La tabella fa il calcolo grazie ai triggers e confronta con epsg 4326 e 32632. Son graditi pareri o suggerimenti... perche' mai usi una roba fragile, delicata, lenta, poco efficiente e poco affidabile come una VirtualShape per importare i dati dallo Shapefile ? guarda che da diversi anni ormai esiste un'apposita funzione SQL per caricare al volo uno Shapefile creando una Spatial Table: ImportSHP() http://www.gaia-gis.it/gaia-sins/spatialite-sql-5.0.0.html 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Centroidi di poligoni concavi
On Fri, 2 Nov 2018 09:20:08 +0100, Massimiliano Moraca wrote: Come così? point_on_surface( ST_Centroid( $geometry ) ) no, non cosi' ma cosa': SELECT ST_PointOnSurface(geometry); che tu usi PostGIS o SpatiaLite o QGIS ha ben poca importanza, visto che in tutti i casi il lavoro vero e proprio viene comunque delegato alla libreria GEOS. la GEOS da parte sua supporta due diverse API che vengono poi incapsulate all'interno delle corrispondenti funzioni SQL: 1. GEOSCentroid() questa ritorna sempre il centroide geometricamente corretto, che nel caso di poligoni concavi puo' facilmente cadere all'esterno della figura 2. GEOSPointOnSurface() invece questa per prima cosa prova a chiamare la precedente, e poi verifica se il punto ottenuto cade o meno all'interno della figura. se il vincolo non e' verificato, allora prova a generare ciclicamente altri punti fino a quando non riesce a trovarne uno che effettivamente cada all'interno della figura. ovviamente questa seconda funzionalita' e' piu' lenta della precedente, perche' puo' richiedere elaborazioni piu' lunghe e complesse, ma in genere si tratta di differenze abbastanza marginali. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Code of Conduct & Code of Ethics del Progetto SQLITE
On Tue, 30 Oct 2018 03:27:01 -0700 (MST), stefano campus wrote: Il Progetto SQLITE ha aggiornato il proprio Codice di Condotta passando da [1] a [2]. Il "vecchio" codice di condotta è diventato ora il Codice Etico del progetto. Code of Cobduct: https://www.sqlite.org/codeofconduct.html Code of Ethics: https://www.sqlite.org/codeofethics.html per loro stessa ammissione, forse il Codice Etico non era più al passo coi tempi e non rispondente effettivamente con quanto richiesto in ambito software ad un codice di condotta. Amen! :-) giusto per inquadrare meglio il contesto molto particolare. Richard Hipp (lo sviluppatore principale e capoprogetto di SQLite) e' un informatico USA nato nel 1961 che ha completato il proprio ciclo di formazione accademica nel 1994 quando ha conseguito un PhD in Computer Science c/o la Duke Univesity, che e' una universita' abbastanza particolare. la Duke e' sicuramente una delle migliori univestita' USA, al punto che ha prodotto 13 premi Nobel e 3 premi Turing. ma e' anche ben nota per avere una forte impronta religiosa, in particolare di ispirazione metodista e quacchera, al punto che i suoi motti ufficiali sono: Eruditio at Religio (in latino) Knoledge and Faith (in inglese) come lo stesso Hipp ha rivelato in diverse interviste, lui e' sempre stato un ateo convinto per tutta la prima parte della sua vita. ma dopo il conseguimento del PhD ha passato un brutto periodo di depressione quando ha scoperto che le sue chances di ottenere una cattedra univesitaria erano praticamente zero, nonostante il suo curriculum accademico particolarmente brillante; evidentemente, non e' solo l'Italia a soffrire di questi problemi :-D si e' risollevato dalla depressione solo nel 1994 quando ha conosciuto la sua attuale moglie Ginger Wyrick, una musicista particolarmente attiva nella direzione del Coro di svariate Chiese metodiste, battiste e presbiteriane del North Carolina. sia come sia, a questo punto della sua vita Richard ha vissuto una profonda esperienza religiosa, ed ha aderito con grande entusiasmo al movimente integralista tipico del protestantesimo USA dei "cristiani rinati", che lo ha portato a maturare una visione tutta sua particolare dell'Open Source inteso come adesione ai principi evangelici di Amore per il Prossimo e di Condivisione con i Fratelli. il "codice etico" non e' altro che la formalizzazione di questa sua ispirazione personale. magari qualche punto particolare potrebbe anche suscitare alcune perplessita', tipo scoprire che gli attuali sviluppatori di SQLite si impegnano a rispettare il digiuno rituale, a praticare la castita', ad amare Dio con tutto il cuore ed a pregare il Signore quanto piu' frequentemente possibile. alla fine del "codice etico" pero' Richard afferma a chiare lettere: No one is required to follow The Rule, to know The Rule, or even to think that The Rule is a good idea. The Founder of SQLite believes that anyone who follows The Rule will live a happier and more productive life, but individuals are free to dispute or ignore that advice if they wish. per me e' semplicemente impeccabile; questa frase e' la negazione di qualsiasi integralismo, perche' incorpora chiaro e tondo il principio di tolleranza. io sono pronto a rispettare Richard come credente almeno tanto quanto lui e' disposto a rispettare me come ateo materialista e darwinista. come diceva Voltaire, finche' c'e' tolleranza reciproca la Religione non puo' e non deve mai diventare motivo di divisione quando ci sono cosi' tanti punti di interesse comuni che possiamo portare avanti con reciproca soddisfazione (e si spera, pure con qualche beneficio per il resto dell'umanita'). il fatto che oggi Richard decida di adottare ufficialmente il codice di condotta stabilito da Mozilla mi pare decisamente apprezzabile, perche' contribuisce a dare a SQLite un'impostazione piu' laica ed agnostica. fino a prova contraria, sviluppo software e fede religiosa possono tranquillamente procedere lungo binari paralleli che non necessariamente si intersecano. ;-) 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Spatialite - QgisServer problemi visualizzazione tabella punti
On Fri, 26 Oct 2018 11:48:50 +0200, giuseppe musumeci wrote: Gentile lista. Sto lavorando con un progetto qgis con alla base un database spatialite una delle tabelle spatialite è costituita da circa 4000 punti. Ho installato su una macchina virtuale un server debian 9 e qgis server. Quando carico il progetto Qgis ed il database non è in alcun modo possibile visualizzare questa tabella di punti con una richiesta getmap Ho verificato la correttezza e l'integrità dei dati ed ho altresì verificato che trasformando i dati in shp oppure geojson il servizio wms restituisce perfettamente i punti. Evidenzio che questo tipo di problematica non è presente in altre tabelle di punti presenti nello stesso database. Qualcuno si é mai inbattuto in questa problematica? Giuseppe, hai provato a verificare se QGIS Desktop riesce a visualizzarti correttamente quel layer ? magari hai semplicemene un problema di statistiche non aggiornate, o qualche altro problemino di configurazione e/o vestizione, o magari uno Spatial Index corrotto. il test con l'app desktop dovrebbe verosimilmente aiutarti a capire piu' facilmente cosa c'e' che non va in quel layer. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Spatialite e dissolve
On Sat, 22 Sep 2018 08:21:31 -0700 (MST), ludovico.frate wrote: Ciao a tutti, sto provando ad effettuare un dissolve su un dataset composto da oltre 1.200.000 punti. SELECT cod_90, ST_Union (geom) AS geometry FROM iuti_join GROUP BY cod_90 Solo che questo richiede parecchio tempo. Come è possibile implementare lo spatial index (che ho già creato) in questa query per velocizzare il processo? Ludovico, lo Spatial Index non e' una polverina magica in grado di accelerare miracolosamente qualsiasi elaborazione Spatial. e' semplicemente un meccanismo che consente di rendere molto piu' veloce il filtraggio preventivo delle features da elaborare, visto che lavorando sulla valutazione preventiva dei BBOX e' in grado di scartare rapidamente gran parte delle geometrie "impossibili", facendo cosi' risparmiare un sacco di tempo. ma nella tua query non e' presente nessuna clausola di filtro basata su relazioni Spatial; anzi, per l'esattezza, manca del tutto la clausola WHERE, il che significa che e' tua intenzione aggregare _TUTTE_ le geometrie presenti nella tavola "iuti_join". in queste condizioni (assenza di qualsiasi filto su base Spatial) anche l'eventuale presenza di uno Spatial Index non puo' avere alcun ruolo nell'accelerare la query. vedo invece che stai aggregando in base ai valori di una colonna non-spatial (GROUP BY cod_90). definire un indice "normale" su questa colonna potrebbe aiutare a velocizzare l'esecuzione della tua query: CREATE INDEX idx_cod_90 ON iuti_join (cod_90); a parte questa eventuale piccola ottimizzazione, per il resto il tempo di esecuzione di una query come questa dipende quasi esclusivamente dal tempo che ci impiega la ST_Union(), e qua non c'e' proprio nulla che tu possa fare per ottimizzare. dipende tutto dal numero delle geometrie, dalla loro complessita', dall'efficienza interna degli algoritmi della GEOS e dalla velocita' della tua CPU; tutti fattori sui quali non puoi esercitare alcun controllo. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] spatialite - vista con linee virtuali da tabella punti
On Fri, 7 Sep 2018 13:26:53 +0200 (CEST), falcerisim...@inwind.it
wrote:
Ciao a tutti,
pongo un quesito:
Come faccio a visualizzare la geometria virtuale LINEARE generata da
una tabella POINT con makeline()?
Ho provato così, manca l'ultimo passo:
"create table punti
(pk integer primary key,
nome text);
select addgeometrycolumn('punti','geom',32632,'POINT',2);
create view virtual_lines as
select
a.rowid as rowid,
st_astext(makeline(a.geom, b.geom)) as wkt,
st_length(makeline(a.geom, b.geom)) as lunghezza,
makeline(a.geom, b.geom) as geom
from punti a, punti b;
select * from virtual_lines;
--fin qui OK finchè è tabellare, ma la geometria in mappa?"
Simone,
SpatiaLite non e' PostGIS, e soprattutto SQLite non e' PostgreSQL;
ci sono alcuni punti specifici in cui l'architettura rende
assolutamente impossibili alcune operazioni.
nello specifico, le Spatial Views di SpatiaLite non possono
assolutamente _MAI_ rielaborare in nessun modo le Geometrie,
perche' altrimenti impazzisce letteramente lo Spatial Index
(che su SQLite e' implementato in modo decisamente esotico).
quindi, una View come la tua, che genera "al volo" dei
segmenti a partire da punti tramite la funzione MakeLine()
non potra' mai diventare in nessun modo una Spatial View
visualizzabile su una mappa.
--problema geometria virtuale da visualizzare
insert into views_geometry_columns
(view_name, view_geometry, view_rowid, f_table_name,
f_geometry_column, read_only)
values ('virtual_lines', 'the_geom', 'rowid', 'QUALE_TABELLA??',
'geom',1);
--con postgis è facile
(st_makeline(a.geom, b.geom))::geometry(LineString,32632) as geom
per l'appunto; c'eri gia' arrivato da solo al punto critico.
QUALE TABELLA ??
nel tuo caso non esiste la tavola di origine, proprio perche'
la geometria viene "prodotta al volo"; e quindi non la puoi
assolutamente registrare su views_geometry_columns.
puoi pero' provare una strategia alternativa; invece di
usare una View puoi usare una Table vera e propria: basta
solo che invece di chiamare:
create view virtual_lines as
select ... blah blah
tu chiami al suo posto:
create table virtual_lines as
select ... blah blah
poi ovviamente dovrai completare l'operazione chiamando:
SELECT RecoverGeometryColumn()
e magari anche:
SELECT CreateSpatialIndex()
e' sicuramente piu' macchinoso, e probabilmente richiede
di cancellare e ricreare la tavola ad intervalli fissi,
ma alla fine in genere e' una metodologia che produce
risultati abbastanza soddisfacenti.
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.
796 iscritti al 28/12/2017
Re: [Gfoss] Da linee di confine a poligoni
On Thu, 6 Sep 2018 06:40:15 -0700 (MST), nformica wrote:
Per eventuali prove, questo è un semplice layer di linee di esempio:
https://drive.google.com/open?id=1Zp1Qq69c6WD4knFmmlTvGBiIIfm3Dbjo
ma ovviamente mi interessa una soluzione che vada bene in generale
anche in
casi più complessi.
ciao Nino,
con SpatiaLite sembra facilissimo risolvere il problema, ma
suppongo che PostGIS dovrebbe dare piu' o meno gli stessi
identici risultati visto che entrambi usano le solite
librerie di base (GEOS etc).
1) ho importato il tuo SHP "siciliano" nella tavola "ambiti_reg"
2) poi ho eseguito la Polygonize in forma aggregata:
CREATE TABLE aggr_polyg (id INTEGER PRIMARY KEY);
SELECT AddGeometryColumn('aggr_polyg', 'geom', 3004, 'MULTIPOLYGON',
'XY');
INSERT INTO aggr_polyg
SELECT NULL, ST_Polygonize(geometry) FROM ambiti_reg;
a questo punto ho ottenuto un singolo MultiPolygon con
tutti i poligoni elementari correttamente ricostruiti.
3) ultimo passaggio: ho usato la ElementaryGeometries
per "sciogliere" tutti i poligoni elementari. stop.
ciao Sandro
p.s.: spesso fatico a capire ... usare uno Spatial DBMS
dovrebbe essere _SEMPRE_ la prima soluzione ovvia e
scontata da prendere in esame per affrontare qualsiasi
problema di spatial processing.
noto che invece gli approcci Spatial SQL tendono
sistematicamente ad essere ignorati ... boh
non capisco ma mi adeguo :-D
___
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.
796 iscritti al 28/12/2017
Re: [Gfoss] La NEXT GENERATION di spatialite
On Sun, 5 Aug 2018 18:17:14 +0200, liste DOT girarsi AT posteo DOT eu wrote: Ho questa versione scaricata dai repo experimental (Debian): ii spatialite-gui 2.0.0~devel2-9 amd64 Forse esiste parimenti un repository PPA per mint/ubuntu? e' la versione testing precedente, rilasciata nel giugno 2015; nulla a che vedere con l'attuale, che si chiama 2.1.0-beta0 comunque, giusto per info; il maintainer di Debian ha gia' inserito in distribuzione il nuovo package aggiornato a ieri, ma si trova nella versione sperimentale di sviluppo. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] La NEXT GENERATION di spatialite
On Sun, 05 Aug 2018 16:47:14 +0200, liste_girarsi wrote: È già presente nei repository Linux, cerca il pacchetto spatialite-gui. assolutamente no. quelle presenti nei repository Linux sono le vecchie versioni; qui stiamo parlando di una versione sperimentale che non e' ancora stata rilasciata in forma STABLE. eventuali testers avventurosi che lavorano su Linux non hanno altra strada che farsi da soli una build dai sorgenti. diverso e' il caso per gli utenti Windows; visto che compilare su Windows e' impresa che fa tremare i polsi anche agli stessi sviluppatori, gli eseguibili per Win sono disponibili gia' pronti all'uso e possono essere scaricati da qua: 32 bit: http://www.gaia-gis.it/gaia-sins/windows-bin-NEXTGEN-x86/ 64 bit: http://www.gaia-gis.it/gaia-sins/windows-bin-NEXTGEN-amd64/ 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. 796 iscritti al 28/12/2017
Re: [Gfoss] La NEXT GENERATION di spatialite
On Sun, 5 Aug 2018 07:40:29 -0700 (MST), pigreco wrote: Approfitto per chiedere se esiste un tutorial per 'niubbi' come me per compilare spatialite_gui in GNU/linux mint 19 no, di specifico per Mint non esiste nulla. ma compilare su qualsiasi Linux richiede sempre la solita trafila: ./configure make sudo install nel caso della GUI NEXTGEN e' un pelo piu' complicato, perche' prima ti dovrai compilare librttopo, libspatialite-5.0.0, librasterlite2-1.1.0 e libvirtualpg-2.0.0 (sono ancora tutte versioni sperimentali,ancora non esistono distribuzioni pacchettizzate). molto schematicamente, il ciclo di lavoro e' questo: 1) https://git.osgeo.org/gitea/rttopo/librttopo/src/tag/librttopo-1.1.0-RC1 download, espandi la tarball, vai dentro alla dir, compili ed installi. occhio: la rttopo richiede per prima cosa (prima ancora del ./configure) di fare girare ./autogen 2) http://www.gaia-gis.it/gaia-sins/libspatialite-sources/libspatialite-5.0.0-beta0.tar.gz download, espandi la tarball, vai dentro alla dir, compili ed installi. 3) http://www.gaia-gis.it/gaia-sins/librasterlite2-sources/librasterlite2-1.1.0-beta0.tar.gz idem come sopra 4) http://www.gaia-gis.it/gaia-sins/virtualpg-1.0.2.tar.gz idem come sopra 5) http://www.gaia-gis.it/gaia-sins/spatialite-gui-sources/spatialite_gui-2.1.0-beta0.tar.gz idem come sopra a questo punto dovresti avere la GUI NEXTGEN pronta all'uso. ovviamente serve che siano installati tutte le librerie richieste come dipendenze, con i relativi files di sviluppo. eventualmente, ti accorgerai subito se manca qualcosa, perche' il ./configure si blocchera' indicando il nome del package mancate; tu a quel punto te lo installi, e poi riprendi dal punto dove eri rimasto. se p.es. ti dice che manca qualcosa che ha a che fare con libsqlite3 tu dovrai installarti "libsqlite3-dev", se ti dice che manca wxWindows ti dovrai installare "wxgtk3.0-dev" e cosi' via. non dovrebbe essere affatto difficile, ma se incontri qualche ostacolo puoi sempre provare a chiedere aiuto, 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. 796 iscritti al 28/12/2017
Re: [Gfoss] problema scaricamento dbprior10k cisis - Not found
On Mon, 30 Jul 2018 08:12:16 -0700 (MST), Ivano wrote: "Il Database viene fornito alle Amministrazioni ed Enti di Ricerca, pubblici o assimilati, che ne fanno richiesta, su supporto ottico (DVD-ROM). La richiesta, corredata dalla sottoscrizione di un impegno di riservatezza del dato, di non rielaborazione del dato a fini di lucro e di fornitura di eventuali rielaborazioni del dato al Centro Interregionale/CISIS, deve essere inviata tramite posta ordinaria ed e-mail agli indirizzi: segrete...@centrointerregionale-gis.it Centro interregionale - CISIS , 00187, Roma, via Piemonte 39, all'attenzione dell'Arch. Massimo Attias" http://www.centrointerregionale-gis.it/DBPrior/pippo.htm ci assicurano i fisici che cosi' come esiste la materia esiste anche l'antimateria. e dunque, perche' mai stupirsi se oggi si scopre che accanto agli open-data esistono pure gli anti-open-data ? l'universo e' fatto da una infinita serie di mirabili simmetrie tra gli opposti :-D ciao Sandro p.s. una pagina web di nome "pippo.html" aggiunge un tocco di geniale originalita' difficile da uguagliare ;-) ___ 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Ancora ECW vs TIFF
On Thu, 19 Jul 2018 11:24:16 +0200, pierluigi de rosa wrote: 2) quale è la vera alternativa libera agli ECW che mantenga un livello di compressione paragonabile? ho fatto delle prova ma senza successo. JPEG2000, basato esattamente sulla medesima compressione di ECW (trasformata wavelet). mentre ECW e' tutto chiuso e proprietario (alcuni algoritmi sono persino brevettati), JPEG2000 e' uno standard internazionale supportato da svariati produttori, anche in versione open source. fino a pochi anni fa le implementazioni o.s. di JP2 erano terribilmente lente rispetto a quelle proprietarie, ma le ultime versioni di OpenJpeg (dalla v.2 in avanti) sono in grado di fornire prestazioni decisamente soddisfacenti. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Georeferenziare un DXF
On Fri, 15 Jun 2018 02:58:13 -0700 (MST), nformica wrote: Dovrei georeferenziare e mettere in scala correttamente un DXF, prima di importarlo in QGIS. Altrimenti me lo butta nell'oceano e neanche nella giusta scala !! Come si fa ? Io uso (male) DraftSight o comunque anche con qualche altro tool mi va bene, basta che sia relativamente semplice. ciao Nino, potresti provare ad importare il tuo DXF su SpatiaLite [1], dopo di che, una volta che avrai messo tutte le geometrie dentro ad una normalissima Spatial Table, sarai poi libero di usare tutte le funzioni Spatial SQL che meglio preferisci per arrivare ad una corretta georeferenziazione. magari potresti usareo le funzioni SQL a supporto dei Ground Control Points [2] hint: se dovesse trattarsi di un lavoro ripetitivo in cui prevedi di dovere importare piu' fogli DXF (tutti appartenenti alla medesima famiglia) potresti utilmente impiegare un opportuno SQL Script, o meglio ancora una Stored Procedure [3], per automatizzare completamente il lavoro. [1] https://www.gaia-gis.it/fossil/libspatialite/wiki?name=DXF [2] https://www.gaia-gis.it/fossil/libspatialite/wiki?name=Ground+Control+Points [3] https://www.gaia-gis.it/fossil/libspatialite/wiki?name=Stored+Procedures 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Viste in Spatialite
On Tue, 5 Jun 2018 14:51:01 +0200, Alessandro Ciali wrote:
Ecco il la query di creazione per ind_pu
CREATE TABLE "ind_pu" ("id" INTEGER PRIMARY KEY, "the_geom" POINT,
"ID_SPU" TEXT)
e quella per la tabella sito_puntuale:
CREATE TABLE "sito_puntuale" ("id" INTEGER PRIMARY KEY, "pkey_spu"
INTEGER, "ubicazione_prov" TEXT, "ubicazione_com" TEXT, "ID_SPU"
TEXT,
"coord_X" INTEGER, "coord_Y" INTEGER, "mod_identcoord" TEXT,
"desc_modcoord" TEXT, "quota_slm" INTEGER, "modo_quota" TEXT,
"data_sito" TEXT, "note_sito" TEXT)
ergo, la tavola che fornisce alla View le geometrie e' "sito_puntuale",
che ha un PK INTGER di nome "id"
richiamo: per SQLite quando esiste una PK INTEGER il valore del ROWID
coincide sempre esattamente con quello della PK.
ma nella creazione della tua View non mi pare di vedere citato da
nessuna parte ne "p"."id" ne "p"."rowid", e quindi "by definition"
la tua View non potra' mai funzionare correttamente, perche' gli
manca il perno fondamentale che regge tutta la logica di funzionamento
delle Spatial Views di SpatiaLite.
mi puoi cortesemente dire cosa ti ritorna questa query SQL ?
SELECT *
FROM views_geometry_column
WHERE f_view_name = '';
se eseguo la query (sulla tabella views_geometry_columns) la tabella
è vuota, può essere quindi che DB manager non crea la view nel modo
corretto o meglio la crea ma non registra i dati nella tabella
views_geometry_columns?
non ho la piu' pallida idea di come funzioni il db manager, ma se
non registra la View in "views_geometry_columns" poco ma sicuro che
quella non e' una Spatial View.
e' semplicemente una banale View, che guarda combinazione contiene
una colonna geometria ma che non potra' essere gestita correttamente
perche' non sono specificate da nessuna parte le regole base per
collegare correttamente la View con il suo Spatial Index di supporto.
consiglio: perche' non provi ad usare spatialite_gui, che offre
un tool grafico facilitato per definire e creare le Spatial Views,
e che per quanto mi risulta funziona perfettamente bene con QGIS ?
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.
796 iscritti al 28/12/2017
Re: [Gfoss] Microsoft compra github
On Tue, 5 Jun 2018 12:08:24 +0200, Alessandro Fanna wrote: Chiedo ai più navigati: qual'è la strategia dietro questa acquisizione? Microsft gia' da diversi anni a questa parte ha deciso di invertire radicalmente il proprio atteggiamento storicamente ultra-negativo nei confronti dell'open source. dalle maledizioni, scomuniche e minacce di cataclismi, pestilenze ed invasioni delle cavallette tipiche dell'epoca quando al timone c'erano prima Bill Gates e successivamente Steve Balmer, con l'arrivo del nuovo management guidato da Satya Nadella e' stato tutto un susseguirsi di iniziative assai piu' concilianti e dialoganti verso il mondo open source. giusto qualche passaggio tra i piu' significativi: - e' stata rilasciata pubblicamente la documentazione tecnica integrale dei formati binari MS Office (.doc di Word, .xls di Excel etc). MS continua a mantenere i brevetti originali, ma ha pubblicamente promesso che non promuovera' mai una causa legale per violazione del copyright nei confronti degli sviluppatori che utilizzaranno quelle informazioni per creare dei tools che facilitino l'interoperabilita'. - Internet Explorer sta rapidamente allineandosi agli standard ufficiali del W3C; e' finita l'epoca in cui il browser di casa MS funzionava (volutamente) in modo radicalmente diverso da tutti gli altri. - SQLite e' entrato a pieno titolo tra i componenti "ufficiali" della piattaforma Windows 10; anche se e' un componente open source MS ha deciso che ha tutte le caratteristiche per venire trattato esattamente come se fosse un componente sviluppato internamente. - le versioni piu' recenti di Visual Studio sono in grado di supportare i build scripts di CMake (credo con alcune limitazioni o vincoli specifici, ma non ne sono sicurissimo). comunque sia, e' chiara l'intenzione di voler colmare o comunque restringere il fossato storico che separava lo sviluppo per Win da quello per Linux (Unix, Mac Os X, Android etc). tirando le somme: MS pare aver finalmente compreso che e' finita l'era della contrapposizione frontale contro il resto del mondo, inventandosi uno dietro all'altro dei simil-standard ad hoc che parevano fatti a bella posta per impedire l'interoperabilita'. sicuramente hanno influito la pesante concorrenza del Mac (che dopotutto e' un derivato Unix) nel segmento desktop e di Android (un derivato diretto di Linux) nel settore mobile. cosi' come ha influito in modo decisivo la concorrenza dei numerosi servizi web ed altri strumenti gratuiti messi a disposizione da Google (che non certo a caso, ha da sempre fatto un punto qualificante del proprio sostegno allo sviluppo open source) altrettanto sicuramente hanno influite alcune sentenze di condanna da parte delle Authorities anti-trust per abuso di posizione dominante. alla fine, mettendo tutto quanto assieme, MS ha iniziato a capire che continuando a chiudersi nella sua gabbia blindata alla fine rischiava di precipitare in una trappola mortale che avrebbe messo a repentaglio la stessa sopravvivenza futura dell'azienda. e quindi, in buona sostanza, ha deciso di allinearsi con le strategie gia' messe in opera con successo dai suoi principali competitors: Oracle a Google (un po' meno Apple). acquisire marchi storici dell'O.S. (come ha fatto Oracle con MySQL ed OpenOffice) e finanziare e sostenere attivamente lo sviluppo O.S. (come fa da sempre Google) non e' affatto in contraddizione con il business model di una grande azienda informatica multinazionale con tendenze monopolistiche. anzi, se viene oculatamente gestito puo' addirittura portare numerosi vantaggi perche' rende facile e soprattutto economico raggiungere una reale interoperabilita' (tu mi rubi i miei clienti storici, ma occhio che anch'io posso rubarti i tuoi). insomma, personalmente non credo che dietro a queste iniziative si nascondano mosse diaboliche; siamo semplicemente di fronte ad un nuovo business model che prende realisticamente atto del fatto che la contrapposizione frontale all'open source non paga, anzi puo' produrre pesanti penalizzazioni. ... se non li puoi combattere, allora tanto vale allearsi, specie se puo' generare profitti economici interessanti ;-) 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Viste in Spatialite
On Tue, 5 Jun 2018 12:17:01 +0200, Alessandro Ciali wrote: Ciao Sandro e ciao a tutti, la spatial table che ho usato per la geometria funziona correttamente, l'ho importata da uno shape in un db spatialite direttamente da DB manager in QGIS. questa informazione e' del tutto irrilevante. che la tua View funzioni egragiamente dal mero punto di vista SQL non implica che lo Spatial Index venga usato in modo consistente dal data provider, sono due questioni del tutto scorrelate. La query che ho usato per creare la view è questa: SELECT p.the_geom, s.pkey_spu, s.ubicazione_prov, s.ubicazione_com, s."ID_SPU", s."coord_X", s."coord_Y", s.mod_identcoord, s.desc_modcoord, s.quota_slm, s.modo_quota, s.data_sito, s.note_sito FROM "Sito_puntuale" s LEFT JOIN ind_pu p ON p."ID_SPU" = s."ID_SPU" se non mi passi anche le due CREATE TABLE con cui hai creato sia "sito_puntuale" che "ind_pu" non posso dirti assolutamente nulla, perche' mi stai nascondendo il datatype delle colonne, e soprattutto mi stai nascondendo come sono state definite le PK, che e' l'informazione assolutamente critica che serve per poter dare una valutazione motivata. hint: se usi spatialite_gui c'e' una comodissima voce di menu che ti permette di visualizzare direttamente la CREATE TABLE con cui e' stata creata ciascuna tavola. altrimenti lo puoi scoprire facilmente tramite questa query SQL: SELECT sql FROM sqlite_master WHERE type = 'table' AND name = ''; e utilizzando l'opzione "create a view" sempre su db manager, dando per scontato che la registrasse correttamente. quando di fa debugging la prima regola aurea e' di non dare mai nulla per scontato; occorre sempre verificare. mi puoi cortesemente dire cosa ti ritorna questa query SQL ? SELECT * FROM views_geometry_column WHERE f_view_name = ''; Inoltre non mi è chiara una cosa al punto 3 della tua risposta: se la spatial view deve contenere necessariamente un ROWID che corrisponde al ROWID della spatial table, come posso costruire spatial views con relazioni di 1 a N fra spatial table e tabelle semplici? In questo caso i valori di ROWID si duplicheranno e non saranno più univoci. il ROWID presente nella Spatial View non ha alcuna necessita' di essere univoco a livello della View; serve solo ad assicurare che per ciascuna Geometry della Spatial View il data provider possa risalire correttamente alla voce corrispondente dello Spatial Index che supporta la tavola-madre che fornisce le Geometries alla View. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Microsoft compra github
On Mon, 4 Jun 2018 20:05:15 +0200, Andrea Peri wrote: Salve, dopo aver comprato qualche anno fa' linkedin, ora Microsoft si rifa' sotto e annuncia oggi l'acquisto di GitHub. 7,5 miliardi di dollari pagati tutti in azioni microsoft. ecco qua la dichiarazione rilasciata da Satya Nadella, amministratore delegato (CEO) di Microsoft; "Microsoft is a developer-first company, and by joining forces with GitHub we strengthen our commitment to developer freedom, openness and innovation. We recognize the community responsibility we take on with this agreement and will do our best work to empower every developer to build, innovate and solve the world’s most pressing challenges." meno male che da ora Richard Stallman, la GNU Foundation e la Free Software Foundation non sono piu' isolati nel difendere la liberta' degli sviluppatori e i principi della "opennes". a partire da stasera ci pensera' attivamente anche la Microsoft "nuovo corso" di Nadella ora si che possiamo stare rilassati e tranquilli. ROTFL :-D 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Viste in Spatialite
On Mon, 4 Jun 2018 17:55:06 +0200, Alessandro Ciali wrote: Ciao a tutti, sto riscontrando un comportamento assurdo con le viste SpatiaLite. Ho creato una vista in un DB SpatiaLite tramite il DB manager di QGIS, unendo un file puntuale con una tabella tramite un semplice join con corrispondenza 1 a 1. purtroppo quando carico la vista in QGIS 2.14.17 mi succedono cose strane: - se clicco con l'identify su una feature, mi vengono restituiti i valori corretti per i vari campi, ma non si apre la form, pur avendo spuntato la voce "auto open form" e individuando una sola feature - se cerco di selezionare una o più features, mi vengono selezionati anche oggetti al di fuori del rettangolo di selezione, e magari non tutti gli oggetti all'interno del riquadro vengono selezionati Il DB spatiaLite l'ho creato da QGIS (create new SpatiaLite Layer), la vista dal DB manager. Le tabelle spaziali e quelle senza geometrie sembrano non avere nessun problema, vengono caricate e visualizzate correttamente in QGIS. tengo a precisare che la stessa procedura (ovviamente la query necessita di piccole correzioni) in Postgres mi restituisce viste perfettamente funzionanti Qualcuno si è imbattuto in questo problema? Sbaglio qualcosa io o è un problema di QGIS/SpatiaLite? ciao Alessandro, le Spatial Views di SpatiaLite hanno dei requisiti ben precisi e molto stringenti; se non li rispetti il caos e' assicurato. 1. la colonna Geometry della Spatial View deve corrispondenre esattamente ad una colonna Geometry di una delle Spatial Tables subordinate. 2. non sono ammesse funzioni SQL che possano alterare in qualsiasi modo la geometria originaria (in altre parole: ST_Transform, ST_Union, ST_Difference, ST_Buffer etc sono sempre rigorosamente proibite in una Spatial View. 3. la Spatial View deve necessariamente contenere una colonna di nome ROWID, che deve coincidere esattamente con il ROWID della Spatial Table che fornisce la Geometry. tutti queste restrizioni sono imposte dalla particolare struttura dello Spatial Index di SpatiaLite, che non ha nulla a che vedere con quella adottata da PostGIS. anche se entrambi producono risultati funzionali praticamente identici, l'architettura interna e' totalmente diversa. se la Spatial View non e' stata correttamente definita finisce che il suo Spatial Index di supporto "impazzisce", con risultati assolutamente paradossali ed apparentemente sconcertanti. dal quadro che ci fornisci, questo parrebbe proprio il tuo caso; molto verosimilmente la tua Spatial View si e' presa un po' troppa liberta' con lo Spatial Index, ed ora funziona in modo del tutto inattendibili (piu' o meno a casaccio). hint: prova a condividere la tua struttura dati, ed in particolare: - gli statements CREATE TABLE della/e Table(s) che utilizzi nella tua Spatial View - lo statement CREATE VIEW che hai usato - la registrazione della tua Spatial View che hai inserito nella meta-tavola "views_geometry_columns" se chiarisci meglio tutti questi aspetti potro' darti un parere piu' mirato e meglio argomentato, e magari anche qualche suggerimento utile per uscire dal pasticcio. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] spatialite
On Mon, 28 May 2018 03:22:48 -0700 (MST), pigreco wrote: PS: per favore, da dove posso scaricare spatialite 4.5 e magari il 5? per adesso utilizzo il 4.3 e il 4.5 ma di quest'ultimo non trovo più il link per scaricarlo. regola sempre valida per tutte le versioni ancora in corso di sviluppo e non ancora definitivamente pronte per un rilascio "stable": 1. per ovvi motivi non esistono distro di binari eseguibili (anche se a volte possono essere rilasciati degli snapshots "usa e getta" giusto per promuovere un pizzico di testing "sperimentale" quando serve allo sviluppo). 2. chi usa Linux non dovrebbe incontrare nessun problema particolare nel farsi la propria build a partire dall'ultima versione dei sorgenti che e' sempre scaricabile dal repository Fossil [1],[2] 3. chi usa Windows puo' sempre provare a farsi la sua build dai sorgenti, con l'avvertenza pero' che su Windows tutto diventa mostruosamente piu' difficile di quanto sia su Linux. (diceva mia nonna: "l'hai voluta la bicicletta ? allora pedala !!!") ad ogni modo, esistono due guide how-to [3],[4] a supporto dei coraggiosi impavidi che se la sentono di avventurarsi in una build per Win32 o Win64 (in diversi ci sono riusciti, anche tra chi bazziaca questa ML). ciao Sandro [1] https://www.gaia-gis.it/fossil/libspatialite [2] http://www.gaia-gis.it/gaia-sins/about-fossil.html [3] http://www.gaia-gis.it/gaia-sins/mingw32_how_to.html [4] http://www.gaia-gis.it/gaia-sins/mingw64_how_to.html ___ 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. 796 iscritti al 28/12/2017
Re: [Gfoss] spatialite
On Mon, 28 May 2018 00:09:47 -0700 (MST), pigreco wrote: Ho fatto tante prove e tra queste ho utilizzato anche il casting con esito negativo, negativo in che senso ? che ti tornava dei NULL ? puoi essere piu' preciso ? in questo caso e con questo database funziona bene. grazie deduco che il dataset di partenza può far cambiare l'esito del casting. assolutamente no; il database di partenza non puo' avere nessuna influenza. le funzioni di Casting lavorano in memoria; prendono un geometry-blob, verificano se e' valido e di tipo coerente con il casting richiesto, dopo di che ritornano un nuovo geometry-blob al cui interno e' stato cambiato il valore del GeometryType conformemente alla richiesta. naturalmente alcune operazioni di casting sono sempre proibite; non puoi p.es. trasformare un Point in un Linestring o un Linestring in un Polygon, perche' i due tipi non sono coerenti. e le operazioni di casting proibite ritornano sempre un NULL. puoi invece trasformare qualunque SinglePart nel corrispondente MultiPart, cosi' come puoi trasformare qualsiasi roba in una GeometryCollection. puoi anche provare a trasformare un MultiPart (o una Collection) in un SinglePart, ma solo ed esclusivamente se contiene al suo interno una singola geometria elementare del tipo indicato. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] spatialite
On Sun, 27 May 2018 02:18:45 -0700 (MST), pigreco wrote:
in particolare lo step4 (script.sql [0]) che ritorna (facendo il
Check
geometry) due tipologie di geometria (linestring e multilinestring) e
quindi
lo step5 non genera nessuna geometria.
--step4
CREATE TABLE "lines_split" AS
SELECT a.pk AS id,
ST_LinesCutAtNodes(st_segmentize(a.geom,6),ST_Union(b.geom)) AS geom
FROM "strade" a, "points_snapped" b
GROUP BY a.pk,a.geom;
SELECT
RecoverGeometryColumn('lines_split','geom',3045,'MULTILINESTRING','XY');
su PostGis una colonna MultiQualcosa puo' contenere indifferentemente
sia le geometrie MultiPart che le geometrie SinglePart dello stesso
tipo, ma SpatiaLite impone vincoli piu' stringenti: o sono tutte
MultiPart o sono tutte SinglePart.
quando, come nel tuo caso, c'e' di mezzo una funzione che puo' tornare
entrambi i tipi c'e' un modo facilissimo per risolvere il problema;
basta chiamare l'appropriato operatore di Cast [1] per trasformare
tutti i SingleQualcosa nel corrispondente MultiQualcosa.
quindi nel tuo caso specifico:
SELECT a.pk AS id, CastToMultiLinestring(
ST_LinesCutAtNodes(st_segmentize(a.geom,6),ST_Union(b.geom))) AS geom
FROM "strade" a, "points_snapped" b
GROUP BY a.pk,a.geom;
vedrai che a questo punto tornera' tutti MultiLinestring, e quindi la
successiva AddGeometryColumn() avra' successo.
ciao Sandro
[1] http://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html#cast
___
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.
796 iscritti al 28/12/2017
Re: [Gfoss] Raccolta fondi per una PROJ evoluta
ultimissimi aggiornamenti. Even Rouault ha appena comunicato sulla ML di gdal-dev che il fund raising ha gia' raggiunto il traguardo, e quindi lo sviluppo iniziera' al piu' presto. la prima libreria che verra' modificata sara' proprio la PROJ, che gia' con la prossima v.6 dovrebbe essere in grado di supportare adeguatamente tutti i nuovi requisiti. a seguire sara' il turno di GDAL che in prospetiva cessera' di implementare internamente le operazioni relative ai CRS; la prossima v.2.4 richiedera' quindi il supporto obbligatorio della PROJ v.6 (cioe' in buona sostanza, molti pezzi di codice oggi disponibili solo su GDAL verranno trasferiti dentro alla PROJ, razionalizzando e semplificando cosi' tutto lo scenario complessivo di riferimento). 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Raccolta fondi per una PROJ evoluta
On Tue, 15 May 2018 10:41:16 +0200, Giuliano Curti wrote: una richiesta se posso: non sono riuscito a capire dove la nuova definizione documenta i parametri: .. +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 \ ciao Giuliano, se per "nuova definizione" intendi quella WKT la risposta e' molto semplice. - la matrice a 7 parametri "+towgs94" e' esattamente uno di quegli elementi "fuori standard" esclusivi della PROJ che si intendono eliminare. n.b.: quando effettui una riproiezione p.es. dal 3003 al 32632 la PROJ in effetti applica due trasformazioni: - la prima dal 3003 al 4326 (WGS84) - la seconda dal 4326 al 32632 ecco perche' la PROJ usa a man bassa il +towgs84; perche' le e' strettamente indispensabile per riproiettare dal piano all'ellissoide e viceversa. ma purtroppo "doppia trasformazione" significa anche "doppio errore" (arrotondamenti, troncamenti etc). - l'approccio WKT e' del tutto differente. come si capisce senza troppa fatica, vengono definiti in modo minuzioso l'ellissoide di riferimento, il datum, il meridiano fondamentale, l'orientazione degli assi, eventuali "false easting" e "false northing", le unita' di misura, fattori di scala etc e quidi, essendo noti tutti i parametri su entrambi i lati della trasformazione, non e' piu' richesta la "doppia trasformazione"; puoi andare sparato da un CRS all'altro in modo diretto, a tutto vantaggio della precisione dei calcoli. - ma non finisce neppure qua: leggo che tra le novita' proposte per la nuova PROJ c'e' pure un meccanismo abbastanza raffinato che dovrebbe verificare dove cade esattamente l'area della geometria da trasformare rispetto ai BBOXes dei due CRS, in modo tale da potere compensare automaticamente quei fattori di distorsione che si verificano inevitabilmente quando ci si allontano in modo sensibile dal centro del fuso di riferimento ... almeno sulla carta, decisamente notevole ;-) 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Raccolta fondi per una PROJ evoluta
On Tue, 15 May 2018 00:00:19 -0700 (MST), stefano campus wrote: leggo nelle note sulla nuova versione di GDAL/OGR 2.3.0 [1]: Update to EPSG v9.2 (#7125) Add support for PROJ.5 new API (requires proj 5.0.1 or later). PROJ 4.X is still supported qulche dettaglio tecnico aggiuntivo per aiutare tutti a capire meglio. IL "PROBLEMONE" DI FONDO la libreria PROJ ha radici molto antiche; le primissime versioni risalgono addirittura agli anni '80 (cioe' a svariati secoli fa, in termini di sviluppo informatico). per definire le caratteristiche dei vari CRS la PROJ ha sempre utilizzato un formato tutto suo basato sulle "stringhe di parametri geodetici". p.es. lo SRID=3003 Gauss-Boaga Ovest e' definito come: -- +proj=tmerc +lat_0=0 +lon_0=9 +k=0.9996 +x_0=150 +y_0=0 \ +ellps=intl +towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68 \ +units=m +no_defs -- in anni molto piu' recenti OGC ha pero' definitivamente formalizzato lo standard WKT per descrivere i CRS. p.es. questa e' la definizione WKT del solito SRID=3003: -- PROJCS["Monte Mario / Italy zone 1", GEOGCS["Monte Mario", DATUM["Monte_Mario", SPHEROID["International 1924",6378388,297, AUTHORITY["EPSG","7022"]], AUTHORITY["EPSG","6265"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.01745329251994328, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4265"]], UNIT["metre",1, AUTHORITY["EPSG","9001"]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",9], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",150], PARAMETER["false_northing",0], AUTHORITY["EPSG","3003"], AXIS["X",EAST], AXIS["Y",NORTH]] -- come salta subito all'occhio, i due formati sono del tutto dissimili; ed e' evidente che il WKT e' decisamente piu' raffinato, completo e preciso del "rozzo" formato adottato da PROJ in anni molto precedenti. non solo: OGC WKT e' uno standard internazionale, mentre invece il formato PROJ e' qualcosa che solo la stessa PROJ e' in grado di interpretare. insomma, e' uno di quei rari casi in cui il sw FLOSS non si adegua agli standard ma pretende invece di imporre un proprio formato decisamente fuori standard. chiaramente e' un punto critico di sofferenza per tutto il sw GFOSS, che prima o poi andava sanato. l'iniziativa del fund raising va esattamente in questa direzione, ed ecco perche' e' cosi' importante. LE ULTIME NOVITA' INTRODOTTE DA PROJ v.5 scommetto che molti di voi sono convinti che il nome corretto della libreria sia PROJ.4 nulla di piu' sbagliato; la libreria si chiama semplicemente PROJ; ma la versione 4 e' rimasta sostanzialmente fossilizzata per oltre 20 anni, fino al punto che ha finito per diventare parte integrante del nome :-D il recente rilascio della versione 5 ha finalmente sbloccato la situazione; la PROJ ha iniziato un percorso di transizione che non e' ancora completo. intanto e' stato introdotto un nuovo meccanismo "pipelined" per gestire le catene di trasformazione, cosi' come ora sono supportate le trasformazioni di tipo spazio-temporale. pero' queste nuove funzionalita' non sono compatibili con le vecchie stringhe di parametri geodetici. non solo: le API della libreria sono state radicalmente stravolte, e non hanno piu' nulla in comune con quelle tradizionali. giusto per addolcire la pillola la v.5 e' ancora in grado di supportare le vecchie API v.4 (in soldoni; e' possibile continuare ad utilizzare la 5 esattamente come se fossa la 4, senza dovere adattare il codice). ma e' chiaro che continuando ad usare le vecchie API v.4 non e' possibile godere di nessuno dei benefici introdotti dalla v.5 nota bene: il supporto delle vecchie API e' transitorio, e cessera' definitivamente con il rilascio della v.7 chi ha orecchie per intendere intenda: ancora per qualche anno sara' possibile continuare ad utilizzare la PROJ nel modo tradizionale, ma prima o poi si imporra' comunque una radicale revisione del codice da parte di tutte le librerie / applicazioni basate sulla PROJ; farlo passo-passo sara' verosimilmente meno traumatico. TIRANDO LE SOMME in questo periodo c'e' un gran ribollire di iniziative attorno alla PROJ; il quadro finale e' ancora un po' confuso, ma certamente andiamo verso un'implementazione finalmente del tutto conforme agli standard internazionali, che verosimilmente sara' molto migliore dell'attuale. la transizione sara' per quanto possibile morbida e relativamente indolore, ma un ciclo di sviluppo ventennale (su cui eravamo un po' pigramente adagiati) si e' definitivamente chiuso ed apre la strada per novita' decisamente eccitanti ma anche in qualche modo "rivoluzionarie". e come diceva Lenin (che di rivoluzioni se ne
Re: [Gfoss] Raccolta fondi per una PROJ evoluta
On Tue, 15 May 2018 08:58:56 +0200, Andrea Peri wrote: Questo non e' un aggiornamento, ma una nuova implementazione. Non e' come quando si aggiorna dalla 4.9.2 alla 4.9.3 di proj che basta ricompilare e tutto va a posto. Andrea, c'e' del vero in tutto quel che dici, ma a me pare che si tratti di problemi inevitabili quando si introduce qualsiasi novita' rilevante e significativa che va a toccare in modo sostanziale meccanismi ben consolidati. non e' un problema specifico del FLOSS, e' un problema piu' generale che interessa tutto il sw, sia quello free che quello proprietario. ci sara' sempre chi si adegua prima e chi ci mettera' un po' piu' di tempo ... ma prima o poi tutti finiranno per adeguarsi. e' un po' come un'onda che si propaghi con differenti velocita' nelle varie direzioni; alla fine giungera' comunque dappertutto. certo, nel periodo intermedio di transizione e' molto verosimile che si possano creare conflitti o pasticcetti vari causati dalla coabitazione tra vecchie e nuove versioni. ma a me pare che sia qualcosa che e' praticamente impossibile evitare anche nei contesti del sw proprietario "closed source". vedi per confronto cosa e' successo regolarmente in tutte le grandi organizzazioni ogni volta che MS Office ha introdotto qualche nuovo formato che non era compatibile con le versioni precedenti. ... babele assicurata per un bel po' di tempo, almeno fino a quando tutte le postazioni di lavoro non vengono aggiornate alla versione piu' recente e tutto va finalmente a posto... ma in genere ci vogliono svariati mesi, se non anni. ;-) 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. 796 iscritti al 28/12/2017
[Gfoss] Raccolta fondi per una PROJ evoluta
vi segnalo una iniziativa decisamente strategica e degna di essere sostenuta che puo' portare significativi miglioramenti a tutto il sw GFOSS nel suo insieme. https://gdalbarn.com/ se si raggiungera' la cifra totale di 125.000 USD i fondi raccolti verranno impiegati a partire dal 4 giugno p.v. per sostenere lo sviluppo di una implementazione piu' moderna e completa del supporto per i Sistemi di Riferimento Spaziale delle Coordinate (CRS/SRS) e delle relative trasformazioni. i pacchetti/librerie che beneficieranno direttamente della nuova implementazione sono GDAL, PROJ, libgeotiff, PostGIS e SpatiaLite. considerando l'uso praticamente universale di GDAL, PROJ e degli Spatial DBMS praticamente tutte le applicazioni GFOSS (QGIS, MapServer, GeoServer, Grass GIS etc) finirano per trarre indirettamente significativi benefici dall'operazione. qualche dettaglio tecnico sui principali scopi che si prefigge l'iniziativa: 1. superare gli attuali files CSV utilizzati per la definizione dei CRS definiti dal dataset EPSG, che verranno rimpiazzati da un database SQLite. 2. supporto completo per lo standard internazionale OGC WKT2 (che tra l'altro prevede anche la gestione delle coordinate 4D: classiche coordinate spaziali XYZ + Tempo). 3. superare l'approccio attuale adotatto da PROJ che si basa su matrici di trasformazione a 7 parametri "+towgs84" per la trasformazione intermedia delle coordinate su WGS84 (metodo non sempre applicabile a tutte le trasformazioni e che puo' implicare margini di errore di qualche metro). 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. 796 iscritti al 28/12/2017
Re: [Gfoss] SPLIT LINES WITH POINTS, THE SPATIALITE WAY - aiuto per script SQL
On Tue, 1 May 2018 01:42:48 -0700 (MST), pigreco wrote: Buongiorno a tutti e sereno 1° maggio; altrettanto a te. lanciando l'intero script SQL viene fuori sempre un errore, nel caso in esame un errore alla row 39 , che non esiste!!!) no, a me (su Win7 Pro 64 bit) risultano si degli errori, ma in posizioni differenti, per la pecisione alle linee 30 e 36, che coincidono con le ultime due chiamate alla RecoverGeometryColumn(). ho provato a commentare quelle due linee e tutto funziona bene; a questo punto ho riscritto quelle due righe "a mano" (niente cut) ed ho cancellato le due righe originali. ora funziona tutto bene :-D due possibili spiegazioni alternative: 1) misteri teologici di ordine superiore che trascendono le normali capacita' di indagine della Scienza Galileiana. 2) qualche caratteraccio "zozzo" che si e' infilato dentro al tuo UTF-8, invisibile ad occhio nudo ma comunque capace di mettere in crisi il parser SQL di SQLite. ovviamente quella valida e' la 2) i due files originale/corretto hanno dimensioni diverse (uno e' piu' lungo di 2 bytes), e sia "diff" che "cmp" riportano delle differenze esattamente per le linee 30 e 36. andando a scavare di fino facendo un hex dump del tuo file vedrai che il punto-e-virgola che chiude le due righe incriminate e' codificato in modo diverso tra le due copie originale/modificata. la spiegazione piu' verosimile e' che tu per scrivere quello Script SQL hai usato piu' editor differenti, almeno uno dei quali ha idee un po' stravaganti sulla corretta codifica dei caratteri UTF-8. probabilmente l'errore si e' verificato una sola volta, ma poi si e' propagato grazie alle fantastiche meraviglie del "taglia". ma anche lavorare un po' su Win ed un po' su Linux potrebbe facilmente aiutare ad incappare in incidenti di questo tipo ;-) 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Suddivisione grafo stradale ad ogni incrocio
On Thu, 12 Apr 2018 09:40:56 +0200, Daniele Bonaposta wrote: La butto lì... di solito questi problemi vengono quando ci sono strade di una certa importanza (autostrade e superstrade per capirci) e' vero in moltissimi casi, ma non e' sempre detto. posso assicurarti per esperienza diretta che sia a Siena che a Genova ci sono alcuni casi di normali strade urbane in sovrappasso. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] spatialite: spatial view non visibile in QGIS
On Sat, 7 Apr 2018 08:26:46 -0700 (MST), pigreco wrote: select l.ogc_fid||p.ogc_fid as rowid, CastToMultiLinestring(st_intersection(l.geometry,p.geometry)) as the_geom from linee l,poligoni p where st_intersects(l.geometry,p.geometry)=1; regola inviolabile: la geometria presente in una Spatial View di SpatiaLite per poter essere visualizzata dal data-provider QGIS deve sempre coincidere esattamente con una colonna-geometria presente in una della Tables utilizzate per costruire la View. in altri termini, la View non deve mai chiamare nessuna funzione SQL che possa modificare in qualsiasi modo le geometrie originali presenti nella Spatial Table su cui si basa la Spatial View. rispettare questo vincolo puo' essere sicuramente considerato come pesantemente restrittivo, ma e' assolutamente indispensabile perche' altrimenti tutta quanta la logica degli Spatial Index (cosi' come sono implementati su SQLite/SpatiaLite) finisce letteralmente massacrata a pezzi ed iniziano a fioccare "risultati assolutamente pazzi". nella tua View ci sono ben due funzioni in cascata che manipolano la geometria, e quindi e' del tutto naturale che non potra' mai funzionare come ti aspetti. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] come unire poligoni vicini?
On Fri, 06 Apr 2018 15:13:07 +, Maurizio Napolitano wrote:
Ho 30.000 poligoni distribuiti su di una area
Ho necessità di creare poligoni concavi fra quelli più vicini
Ciao Napo,
non sono sicurissimo di avere capito bene i tuoi requisiti,
comunque provo a buttare giu' un'abbozzo di soluzione su
SpatiaLite.
CREATE TABLE aggregati (id INTEGER PRIMARY KEY);
SELECT AddGeometryColumn('aggregati', 'geom', 3003, 'MULTIPOLYGON',
'XY');
- per prima cosa andiamo a creare una tavola di appoggio
INSERT INTO aggregati
SELECT NULL, ST_Union(geometry)
FROM my_nput_table;
- ora andiamo ad usare la ST_Union come funzione aggegata,
e salviamo il risultato nella tavola precedente.
alla fine otterremo un unico enorme multipolygon, in
cui sicuramente tutti i poligoni elementari adiacenti
sono stati fusi assieme.
SELECT ElementaryGeometries('aggregati', 'geom', 'poligoni', 'new_id',
'old_id');
SELECT DropGeoTable('aggregati');
- come ultimo passaggio andiamo a sciogliere il grosso
multipolygon che abbiamo creato nella fase crecedente
risolvendo individualmente tutti i poligoni elementari.
come ultimissimo passaggio eliminiamo la tavola di
appoggio che non ci serve piu' a nulla.
ATTENZIONE: nulla assicura pero' che i poligoni risultanti
siano concavi oppure convessi ... e non mi viene neppure
in mente nessuna funzione Spatial SQL che possa aiutare a
discriminare tra i due casi.
ciao Sandro (ed in bocca al lupo)
-
___
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.
796 iscritti al 28/12/2017
Re: [Gfoss] grass postgis
On Fri, 6 Apr 2018 09:18:27 +0200, Vittorio Bisaglia wrote: e nel terminale: " ERROR 6: CreateFeature : unsupported operation on a read-only datasource." ciao Vittorio, controlla meglio le impostazioni della connessione ed il profilo di accesso utente. l'errore riportato indica chiaramente che la conessione al DBMS PostgreSQL non ha poteri di scrittura. una delle cause piu' verosimili e' che il tuo user sia abilitato per SELECT ma non per INSERT, UPDATE etc vedi un po' se puo' aiutarti il comando SQL "GRANT" https://www.postgresql.org/docs/9.0/static/sql-grant.html 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. 796 iscritti al 28/12/2017
Re: [Gfoss] R: [ SARDEGNA ] - Shapefile ed errori (?)
On Thu, 22 Mar 2018 16:43:22 +0100, a.furi...@lqt.it wrote: ah ah, ancora una volta fanno capolino le mitiche "banane" :-D esiste un caso particolarissimo di "Poligono con buco interno" in cui il software prodotto da ESRI adotta una convenzione che fa a pugni con gli standard dettati da OGC (vedi figura allegata). il problema nasce quando il "buco" tocca direttamente il boundary della figura; capita molto spesso lungo la linea costiera, quando si incontrano piccolissime insenature. noto che ora il mail server di Gfoss.it non consente piu' di allegare neppure un microscopico PNG da 4 KB :-P ad ogni buon conto, chi e' interessato alla figura citata come esempio la puo' trovare qua: http://www.gaia-gis.it/buchi.png 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. 796 iscritti al 28/12/2017
Re: [Gfoss] R: [ SARDEGNA ] - Shapefile ed errori (?)
ah ah, ancora una volta fanno capolino le mitiche "banane" :-D
esiste un caso particolarissimo di "Poligono con buco interno"
in cui il software prodotto da ESRI adotta una convenzione che
fa a pugni con gli standard dettati da OGC (vedi figura allegata).
il problema nasce quando il "buco" tocca direttamente il boundary
della figura; capita molto spesso lungo la linea costiera, quando
si incontrano piccolissime insenature.
- in questo case secondo ESRI e' lecito disegnare il solo
Exterior Ring, che dal punto P entra dentro alla figura,
descrive il contorno del "buco", e poi riesce fuori passando
ancora una volta dal punto P.
- ma questo non e' tollerabile secondo le specifiche degli
standard OGC, perche' qualsiasi Ring non puo' mi avere
dei punti di autotangenze.
quindi, secondo OGC, una topologia di questo tipo va
obbligatoriamente descritta utilizzando un Exterior
Ring ed un Interior Ring (che ovviamente si intersecano
sul punto P, ma questo e' legittimo).
ho appena controllato su SpatiaLite lo shape ISTAT 2016:
SELECT comune
FROM com2016_wgs84
WHERE cod_reg = 20 AND
ST_IsValid(geometry) <> 1;
---
La Maddalena
Calasetta
in Sardegna ci sono due comuni "stile ESRI", e sono
proprio loro quelli che disturbano.
correggere gli errori fino ad ottenere delle geometrie
impeccabili perfettamente coerenti con i requisiti
richiesti dagli standard OGC e' decisamente molto
semplice:
UPDATE com2016_wgs84
SET geometry = MakeValid(geometry)
WHERE cod_reg = 20
AND ST_IsValid(geometry) <> 1;
verifica finale:
SELECT comune, ST_IsValid(geometry)
FROM com2016_wgs84
WHERE comune in ('La Maddalena', 'Calasetta');
La Maddalena1
Calasetta 1
ora finalmente e' tutto a posto ;-)
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.
796 iscritti al 28/12/2017
Re: [Gfoss] Differenze tra Spatialite e Geopackage
On Thu, 1 Mar 2018 20:11:55 +0100, Massimiliano Moraca wrote: Mi è ben chiara la distinzione tra DB e DBMS, non mi era chiaro il fatto che un file .sqlite fosse esso stessi già un DBMS e che, ad esempio, SpatiaLite GUI è una "semplice" gui perchè credevo piuttosto che fosse il DBMS. Come accade quando si fa un dump da PostGIS e lo si salva in .sql, questo file in se non può essere gestito senza reinmetterlo in un DBMS. --- Il fraintendimento credo sia nato dal fatto che io quando parlo di DB intendo un insieme di dati "fermi da qualche parte", come una serie di raccoglitori con documenti tenuti in una cassettiera. Mentre per DBMS intendo un software che processa quei dati e per client un software che li visualizza. Almeno così l'avevo capita io. Massimiliano, quel che dici e' sostanzialmente corretto. un DBMS e' indiscutibilmente un software; che pero' richiede necessariamente un suo specifico spazio di storage fisico dove memorizzare i dati e tutte le altre meta-strutture SQL (tavole, viste, vincoli, relazioni, indici, triggers etc) nel modo piu' opportuno ed efficiente. a questo punto pero' si apre un ampio ventaglio di possibili implementazioni, tutte ugualmente valide ma tutte radicalmente diverse l'una dall'altra. di norma lo storage legato ai DBMS e' qualcosa di abbastanza "misterioso ed oscuro", ed e' spesso strettamente legato ad una versione ben precisa del DBMS. per trasferire lo storage da una macchina all'altra, ma spesso anche solo per passare ad una versione piu' recente, e' indispensabile scaricare un dump che verra' successivamente ricaricato da zero. SQLite invece adotta un'architettura radicalmente diversa; tanto per cominciare, non e' client-server, ma e' un "personal" DBMS, o se preferisci un "embedded" DBMS. questo significa che tutto il DBMS (ovvero lo SQL engine) consiste semplicemente in una libreria (libsqlite3) che deve necessariamente venire linkata all'interno di qualche applicazione per potere girare (spatialite_gui, QGIS o cosa altro ti pare). quindi quando tu dici che "SpatiaLite GUI è una 'semplice' gui perchè credevo piuttosto che fosse il DBMS" dici una cosa sia vera che falsa, dipende da come la prendi. per come la vedo io Spatialite GUI e' a tutti gli effetti una semplice GUI che si occupa solo della visualizzazione dei dati; tutto il "lavoro sporco" viene delegato al DBMS sottostante, che nello specifico e' rappresentato dalle due librerie libsqlite3 e libspatialite. il fatto che la comunicazione tra applicazione client e DBMS avvenga direttamente in RAM all'interno di un unico processo passando tramite API invece che attraverso una connessione di rete e' semplicemente un dettaglio tecnico, ma non altera la struttura dell'architettura di fondo. ma SQLite presenta ancora un'altra grossa specificita': lo storage consiste in un singolo file, il DB-file, che contiene al suo interno tutto quel che serve per memorizzare i dati e tutte le altre cianfrusaglie assortite richieste da SQL. a questo punto lo scenario diverge radicalmente da quelli piu' convenzionali di MySQL, PostgreSQL etc, in cui esiste un'unica istanza del DBMS che usa un singolo spazio di storage, piu' o meno variamente strutturato al suo interno. su SQLite puoi avere su di un'unica macchina centinaia e persino migliaia di DB-files completamente indipendenti l'uno dall'altro; e li puoi piazzare a casaccio in qualsiasi cartella come meglio preferisci, le regole le stabilisce liberamente l'utente, non il DBMS. non solo: questi DB-files li puoi anche copiare "al volo" tra macchine diverse. e giusto per finire, su SQLite non dovrai mai fare un dump/reload, perche' qualsiasi versione successiva di SQLite (e di SpatiaLite) sara' sempre sicuramente in grado di leggere correttamente tutti i DB-files creati da una qualsiasi versione precedente. Naturalmente nulla assicura l'inverso; non e' sempre detto che una versione obsoleta di SQLite e/o SpatiaLite riesca a leggere correttamente un DB-file creato da una versione successiva. proprio come dici tu, un DB-file in fondo e' semplicemente "un insieme di dati 'fermi da qualche parte', come una serie di raccoglitori con documenti tenuti in una cassettiera" ma per aprire correttamente tutti i cassetti e recuperare tutti i documenti occorre pur sempre passare attraverso il DBMS, cioe' occorre chiamare le API della libsqlite3. non e' affatto importante se la libsqlite3 e' linkata dentro a QGIS o dentro a spatialite_gui o dentro ad un programma Python o Java; in ogni caso tutti gli accessi fisici allo storage passeranno comunque attraverso al solito SQL engine, quello della libsqlite3. tornando a bomba: e' proprio qua che si registra la principale differenza strutturale tra GeoPackage e SpatiaLite. - per riuscire ad aprire un GeoPackage basta la sola libsqlite3 e niente altro. - invece per riuscire ad aprire un DB-file SpatiaLite oltre alla libsqlite3 serve pure la libspatialite,
Re: [Gfoss] Differenze tra Spatialite e Geopackage
On Thu, 1 Mar 2018 08:22:19 -0700 (MST), Massimiliano Moraca wrote: Se il mio inglese non mi inganna ne deduco che il GeoPackage sia un formato dati si ma simile ad un DB. ciao Massimiliano, hai centrato quasi perfettamente il punto, tranne che in un piccolo dettaglio; non e' "un formato dati simile ad un DB", ma e' piuttosto un insieme di regole e regolette che trasformano un normalissimo DB SQLite in un formato dati standardizzato specializzato per il GIS. giusto per sgombrare il campo da possibili malintesi sulla terminologia: - un formato file e' semplicemente uno standard formalizzato che dice come deve essere codificato un determinato tipo di contenuto. ne esistono centinaia e centinaia, che spaziano tra i vari formati per le immagini (Jpeg, Gif, Png etc), per i suoni (mp3, Wav, Vorbis, RealAudio), per i documenti di testo (.doc, .docx, .odt) e cosi' via. i formati file sono intrisecamente "stupidi", e richiedono sempre l'intermediazione di una qualche applicazione o libreria per potere essere letti o scritti. - un DBMS invece e' un sistema sw "intelligente", perche' e' capace di supportare in modo del tutto autonomo potenti capacita' di elaborazione dati senza richiedere altri strumenti esterni (dopo tutto SQL e' un vero e proprio linguaggio di programmazione). uno Spatial DBMS e' semplicemente un DBMS specializzato capace di supportare il data-type Geometry, e quindi in grado di consentire un completo Spatial Processing (elaborazione di dati geografici). naturalmente e' possibile interfacciare un DBMS con una qualsiasi applicazione di terze parti, ma resta il fatto che l'accesso vero e proprio ai dati deve sempre necessariamente passare attraverso al componente DBMS. SQLite e' un vero e proprio DBMS, ma ha la caratteristica abbastanza anomala che tutto un intero DB consiste semplicemente in un singolo file che puo' essere scambiato liberamente e facilmente anche tra piattaforme diverse. Ne consegue che se si usa SQLite applicando sempre scrupolosamente alcune regole chiaramente codificate, allora diventa possibile trasformare un DB SQLite in un vero e proprio formato file. ed e' esattamente questa la strada scelta da GeoPackage. tuttavia GeoPackage non puo' essere assolutamente considerato uno Spatial DBMS, perche' le specifiche OGC non prevedono alcuna estensione Spatial SQL tale da consentire lo Spatial Processing. per visualizzare oppure per elaborare i dati geografici contenuti in un GeoPackage resta assolutamente indispensabile utilizzare una qualche applicazione esterna. l'unico supporto SQL disponibile e' quello nativo di SQLite, che e' ovviamente inadeguato per qualsiasi tipo di Spatial Processing, anche del piu' rudimentale. ed e' proprio sotto questo profilo che SpatiaLite e GeoPackage si collocano esattamente agli antipodi, pur basandosi entrambi su SQLite. SpatiaLite e' un vero e proprio Spatial DBMS capace di supportare uno Spatial SQL molto completo, e quindi e' possibile fare Spatial Processing di alto livello utilizzando esclusivamente SpatiaLite senza alcun bisogno di ricorrere ad altre applicazioni (una caratteristica che risulta estremamente appetibile per molti "power users", anche qua in Italia). concludendo: SpatiaLite e GeoPackage presentano una forte somiglianza superficiale perche' sono entrambi basati su SQLite. ma a parte questo, appartengono a due categorie funzionali assolutamente diverse. uno e' semplicemente un formato file; il suo concorrente naturale e' il vetustissimo shapefile. l'altro e' uno Spatial DBMS "light" ma non per questo meno potente, che in non poche occasioni puo' costiture una valida alternativa per PostgreSQL/PostGIS o per altri Spatial DBMS di tipo proprietario. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Export PostGIS - SpatiaLITE
On Sun, 25 Feb 2018 12:00:41 +0100, Andrea Peri wrote: Forse sarebbe stato meglio introdurre una codifica differente dal NULLO per gestire l'eccezione ? Boh. forse tutto considerato la soluzione piu' corretta sarebbe quella di supportare il geom-type EMPTY, che e' previsto dalle specifiche OGC-SFS ma che purtroppo non e' supportato da SpatiaLite. questo ci consentirebbe di eliminare qualsiasi ambiguita', perche' p.es. determinare un'intersezione tra due geometrie perfettamente valide ma completamente disgiunte tornerebbe EMPTY, mentre un valore di ritorno NULL a questo punto indicherebbe con assoluta certezza che almeno uno tra gli argomenti di invocazione della funzione era inaccettabile. in ogni caso ora anche cio' comporterebbe una perdita di compatibilita' e quindi e' una disquisizione inutile. vero: ma sicuramente l'ipotesi di introdurre prima o poi le geometrie EMPTY si presenta come una soluzione piu' facile da implementare, e con conseguenze molto meno traumatiche. dopo tutto il flusso di esecuzione non verrebbe interrotto, proprio come avviene attualmente. mentre invece i valori di ritorno si presterebbero ad una interpretazione non ambigua. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Export PostGIS - SpatiaLITE
On Sun, 25 Feb 2018 06:48:04 +0100, Andrea Peri wrote: Sempre esatto e preciso ma questa volta sento di dover aggiungere un dettaglio ulteriore. :D L operatore casttomulti te dici che si può sempre applicare. Occorre però stare attenti quando si applica per passare da multi a simple ovvero usando l operatore casttosimple. Infatti occorre controllare prima quante parti ha la multi che si vuole trasformare. Se ne ha una sola, ok, si può fare e tutto funziona bene. Se ne ha più di una , su spatialite non si può fare perché si perde tutte le parti eccedenti la prima. Occorre stare veramente attenti perché spatialite non da errore, ma si limita a passare solo la prima parte. Esempio : se ho il.dataset Delle isole dell' arcipelago toscano con un poligono di tipo multipolygon che comprende tutte le isole. Se faccio un semplice casttosimple perdo tutte le isole eccetto la prima. Andrea, scusami ma ti devo correggere almeno in parte. e' verissimo che occorre molta cautela quando si applica un cast da multi a single, perche' ovviamente il cast funzionera' solo se la collection contiene un singolo elemento. ma quando la collection contiene due o piu' elementi non ti torna affatto il primo elemento; ti torna invece un NULL. spiegazione per chi non e' al corrente: Andrea sostiene da tempo che SpatiaLite ha un "brutto vizietto", cioe' quello che moltissime funzioni (praticamente tutte) ritornaro valori NULL o FALSE quando riscontrano una condizione di errore, mentre invece sarebbe preferibile che sollevassero un'eccezione bloccando immediatamente il flusso di esecuzione. dal punto di vista teorico non c'e' dubbio che ha ragione Andrea; nella pratica pero' dovere correggere pesantemete svariate centinaia di funzioni, oltre ad essere una faticaccia impproba, implica anche il rischio di introdurre involontariamente un visibilio di regressioni potenzialmente pericolose. infine va anche considerato che un cambiamento cosi' radicale provocherebbe sicuramente molte difficolta' a tantissime applicazioni gia' esistenti che si basano strutturalmente sulla logica di funzionamento attuale. insomma, non escludo che in qualche versione futuribile SpatiaLite finira' per abbracciare sistematicamente la logica delle eccezioni bloccanti, ma almeno per ora e' piu' prudente non allontanarsi troppo da una tradizione storicamente ben consolidata. ciao Sandro che implica un vero e proprio cambiamento ___ 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Export PostGIS - SpatiaLITE
On Sat, 24 Feb 2018 19:01:46 +0100, Massimiliano Moraca wrote: Buonasera a tutti, vi scrivo dopo un po' per aggiornarvi. Senza fare alcuna modifica al db esportato da PostGIS ed usando un semplice drag in QGIS tutti i layer vengono correttamente letti. Il problema nasce però dopo un po', infatti per non so quale motivo saltano tematismi ad esempio. Ho quindi seguito le indicazioni di Alessandro Furieri in questo modo: - per prima cosa occorre verificare cosa contiene esattamente il dataset; basta eseguire la seguente query SQL: SELECT Count(*), GeometryType(geom), Srid(geom), CoordDimension(geom) FROM table GROUP BY 2, 3, 4; A seguito di questa verifica in SpatiaLite mi sono ritrovato con alcune tabelle che erano multi geometrie ma che almeno non mischiavano le tipologie di geometrie. Ho ad esempio Polygon e MultiPolygon. Quindi mi trovo nel caso 2: Non mi è chiaro però se le procedure indicate devono essere svolte in PostGIS pre esportazione o in SpatiaLite post esportazione. Qualcuno può chiarirmi questo punto? ciao Massimiliano, la procedura di cui al caso 2) la devi eseguire su SpatiaLite. Un'altra cosa che non mi è chiara, e l'ho verificata anche in PostGIS: come è possibile che da una intersezione di due vettori MultiPolygon ne venga fuori uno che è sia Polygon che MultiPolygon? risposta rapida: il risultato dell'intersezione tra due (o piu') poligoni dipende tutto da come si relazionano le figure; a seconda dei casi potresti avere un POINT (le due figure si toccano su un unico vertice), un LINESTRING (le due figure si toccano solo lungo un lato), oppure un POLYGON (esiste una vera e propria intersezione). piu' ovviamente tutte le combinazioni in salsa "multi" tra i casi precedenti; non esiste regola, dipende tutto caso per caso. risposta ragionata: --- cerchiamo per prima cosa di sgombrare il campo da eventuali equivoci sulla terminologia; immagino che quando tu dici "vettore" intendi dire "dataset contenente geometrie vettoriali", vero ? che quindi secondo la terminologia SQL corrisponde ad una Spatial Table. giusto un richiamo veloce al data-model OGC-SFS per il data-type GEOMETRY: - esistono 3 classi "semplici" (single-part, capaci di rappresentare un unico oggetto geometrico) che sono POINT, LINESTRING e POLYGON. - poi esistono 4 classi "collection" (multi-part, con la possibilita di contenere contemporaneamente piu' oggetti geometrici di tipo semplice) che sono MULTIPOINT, MULTILINESTRING, MULTIPOLYGON e GEOMETRYCOLLECTION. nei primi tre casi tutti i membri della collection devono essere del medesimo tipo; nell'ultimo caso possono essere di qulunque tipo senza restrizioni di sorta. nota: qualsiasi collection puo' contenere un numero arbitrario di elementi a partire da uno. corollario: un oggetto "semplice" come p.es. un POLYGON secondo il modello canonico OGC-SFS si puo' legittimamente rappresentare anche sotto forma di MULTIPOLYGON e persino di GEOMETRYCOLLECTION. dato che questo apre una potenziale ambiguita', e' ovvio che in questo caso occorre assegnare esplicitamente il Geom-Type desiderato. purtroppo in molti casi non e' possibile determinare a priori il geom-type del risultato atteso, e quindi molte librerie lo determinano basandosi esclusivamente sul conteggio degli oggetti elementari. quindi se trovano un unico POLYGON concludono che tutta quanta la Geometry nel suo complesso sia un POLYGON, senza prendere in considerazione che invece ci si attendeva un MULTIPOLYGON. SpatiaLite offre un metodo molto semplice ed efficare per aggirare il problema; le funzioni di casting. p.es. la CastToMultiPolygon() e' in grado di trasformare "al volo" un POLYGON in un MULTIPOLYGON. sarebbe sempre opportuno applicare il casting piu' appropriato prima di provare ad inserire una Geometry in una Spatial Table, proprio per evitare pasticci come questi di cui stiamo parlando, ma e' ovvio che da qualche parte questa buona regola non viene applicata. ultima puntualizzazione per chiarire definitivamente il quadro. SpatiaLite segue alla lettera le specifiche OGC-SFS, cosa che per vari motivi non avviene invece in altri Spatial DBMS ed applicazioni GIS. (e quando dico che "segue alla lettera" intendo dire che non solo e' conforme alle ultime specifiche che definiscono lo standard, ma che l'implementazione e' stata verificata ed approvata dai tecnici della stessa OGC al tempo del comitato che defini' la prima bozza dello standard GPKG - GeoPackage). le specifiche OGC impongono che tutte le Geometrie contenute nella medesima colonna di un qualsiasi Spatial Table _DEVONO_ avere esattamente lo stesso Geom-Type, e che questo deve coincidere col valore dichirato nella meta-tavola "geometry_column". SpatiaLite e' molto pignola su questo: se una Spatial Table e' definita come M
Re: [Gfoss] SpatiaLite query builder grafico
On Wed, 14 Feb 2018 17:03:44 +0100, nino formica wrote: Alcuni amici a cui sto cercando di insegnare i primi rudimenti per scrivere delle query SpatiaLite, mi hanno chiesto se esiste la possibilità di farlo con qualche query builder grafico (per capirci simile a quello che c'è in MS Access). In effetti non ci avevo pensato prima, ma effettivamente ciò eviterebbe a molti utenti basici di evitarsi la sintassi SQL un po' astrusa. ciao Nino, sono personalmente convinto che qualsiasi query builder grafico "stile MS Access" alla lunga sia fortemente controproducente, e cerco di spiegare perche'. qualsiasi wizard GUI, per quanto sofisticato possa essere, finisce inevitabilmente col ricondurre qualsiasi problema a poche situazioni standard "pre-masticate" in modo abbastanza rigido, che vanno verosimilmente bene in molti casi generici ma che lasciano del tutto scoperte tante altre situazioni meno frequenti e/o piu' complesse che pure si riscontano abbastanza di frequente. viceversa il linguaggio SQL (perche' non dobbiamo mai dimenticare che e' un vero e proprio linguaggio di programmazione, per quanto atipico) offre una potenza ed una flessibilita' praticamente illimitate. incapsulare SQL dentro ad un rigido guscio GUI finisce quindi inevitabilmente per castrare molte delle funzionalita' piu' avanzate e sofisticate, che finiscono semplicemente per essere ignorate dato che sarebbe troppo complesso supportarle adeguatemente in forma grafica. io non definirei la sintassi SQL "un po' astrusa", perche' e' oggetivamente molto semplice, utilizza giusto una decina di comandi e presenta una struttura del tutto logica, assolutamente regolare e consistente noche' facilmente intuitiva e predicibile. a mio modesto parere molti utenti (basic e non solo) incontrano grosse difficolta' nel loro l'approccio ad SQL principalmente per i seguenti motivi: 1) SQL e' un vero e proprio linguaggio di programmazione; per scrivere una query SQL efficiente e magari non banale serve sicuramente una "testa da programmatore", cosa che evidentemente e' alla portata di molti ma non di tutti. 2) SQL e' un linguagio atipico, visto che si basa sul modello dichiarativo invece che sul piu' comune modello imperativo. detta in parole semplici: nei linguaggi imperativi (C/C++, Java, Python, PHP etc) il programmatore deve minuziosamente indicare una serie di "azioni" che eseguite in sequenza producono il risultato desiderato. viceversa in un linguaggio dichiarativo (come SQL) il programmatore deve semplicemente descrivere il risultato atteso, specificando tutti i vincoli e le condizioni restrittive a cui deve essere soggetto. a partire da questi elementi sara' poi il sw stesso a determinare automaticamente la corretta sequenza di "azioni" che produce il risultato richiesto nel modo piu' efficiente ed ottimizzato. purtroppo capita molto spesso che sviluppatori in possesso di una discreta familiarita' con altri linguaggi continuano a ragionare in modo imperativo anche quando devono scrivere una query SQL, e questo li porta inevitabilmente fuori strada. 3) dato che SQL e' un linguaggio, richiede un certo livello di conoscenze e di competenze specifiche per potere essere utilizzato con qualche soddisfazione. nulla di particolarmente complicato, visto che per acquisire una discreta padronanza di SQL bastano abbondantemente un paio di giornate di studio accompagnato da tanti test pratici, magari seguendo un buon tutorial. purtroppo invece moltissimi utenti sono assolutamente convinti che SQL si possa usare "ad orecchio", procedendo ad occhio e croce senza mai degnarsi di consultare uno straccio di documentazione (peraltro largamente diffusa e facilmente consultabile). 3.bis) per potere usare con qualche successo lo Spatial SQL serve ovviamente una discreta competenza generale relativa a "SQL liscio", visto che la parte "spatial" e' semplicemente un'estesione che si appoggia sulla comune sintassi base. noto purtroppo che molti utenti GIS tendono invece a concentrare la propria attenzione esclusivamente sulla parte specificamente "spatial", mentre trascurano gli aspetti "non spatial" ritenendoli di scarso interesse. 3.ter) ogni DBMS ha la sua specifica variante dialettale di SQL, con le sue tipicita' ed idiosincrasie. chi gia' padroneggia un qualsiasi dialetto SQL incontrera' ben poche difficolta' a familiarizzare in tempi brevissimi con un dialetto differente, ma sicuramente serve almeno un pizzico di studio della documentazione specifica. passaggio che invece molti tendono a saltare a pie' pari. conclusione: SQL non e' di per se un linguaggio particolarmente ostico. diventa terribilmente ostico quando si pretende di utilizzarlo senza avere una preparazione adeguata, almeno a livello basic. la soluzione in genere e' semplice ed alla portata di tutti con poco sforzo: basta semplicemente studiare prima di agire.
Re: [Gfoss] Export PostGIS - SpatiaLITE
On Wed, 7 Feb 2018 12:06:06 +0100, Totò Fiandaca wrote:
correggetemi se dico fesserie:
una soluzione sarebbe quella di aggiungere un altro campo geometry
(es:
geom, definirlo per bene) alle tabelle e popolarle con la geometria
con un
UPDATE.
credo funzioni.
si, dovrebbe funzionare, ma il percorso da seguire per
fare un lavoro ben fatto e' un po' piu' complesso:
- per prima cosa occorre verificare cosa contiene
esattamente il dataset; basta eseguire la seguente
query SQL:
SELECT Count(*), GeometryType(geom), Srid(geom), CoordDimension(geom)
FROM table
GROUP BY 2, 3, 4;
n.b. chi usa spatialite_gui puo' usare direttamente
il tool "check geometries" dal menu associato a quella
particolare colonna-geometria.
- a questo punto tutto dipende dai risultati della
query precedente.
caso #1
===
nel resultset appare una singola riga.
basta creare la seconda colonna-geometria con gli
argomenti appropriati, p.es.
SELECT AddGeometryColumn('table', 'geom2', srid, 'POINT', 'XY');
a questo punto si procede direttamente al popolamento
della nuova colonna-geometria:
UPDATE table SET geom2 = geom;
caso #2
===
nel resultset appaiono un paio di righe, ma
tutte con il medesimo modello dimensionale e
con tipi geometrici compatibili, uno di tipo
single-part e l'altro di tipo multi-part
(p.es. POINT e MULTIPOINT, oppure POLYGON
e MULTIPOLYGON).
a questo punto occorre creare la seconda
colonna-geometria stando ben attenti a
specificare il MultiType:
SELECT AddGeometryColumn('table', 'geom2', srid, 'MULTIPOLYGON', 'XY');
infine si procede al popolamento della
seconda colonna-geometria applicando un
opportuno operatore di cast, tale da
forzare il geometry-type per uniformare
tutte le geometrie al caso multi-part:
UPDATE table SET geom2 = CastToMultiPolygon(geom);
caso #3
===
nel resultset appaiono svariate righe, con
geometry-type incompatibili (p.es. POINT,
LINESTRING e MULTIPOLYGON).
in questo caso non e' possibile procedere
ad una conversione diretta, andranno create
tante colonne-geometria quanti sono i
geometry-types, e durante la fase di popolamento
le geometrie andranno opportunamente filtrate
in base al tipo.
ciao Sandro
poi, il provider spatialite di QGIS vedrebbe due colonne geometriche
dello
stesso strato.
___
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.
796 iscritti al 28/12/2017
Re: [Gfoss] Export PostGIS - SpatiaLITE
On Wed, 7 Feb 2018 10:35:39 +0100, Totò Fiandaca wrote: Ciao, ho notato che i layer non riconosciuti da QGIS hanno, nella tabella "geometry_columns" di spaltialite, codice 0 nella colonna geometry_type; conformemente alle specifiche OGC-SFS geometry-type=0 identifica la super-classe astratta GEOMETRY (cioe' in soldoni indica che quella colonna puo' contenere qualsiasi tipo di geometria, dal POINT al LINESTRING al POLYGON etc). e notoriamente QGIS non e' in grado di gestire i geometry-type GEOMETRY e GEOMETRYCOLLECTION, come invece fanno piu' o meno tutti i WMS/WFS servers ed OpenJump. credo che dipenda, come hai scritto, dal modo con cui li hai generati. probabilmente sono il frutto di qualche funzione che genera risultati "a tipo variabile". in ogni caso una query come la seguente aiuta a comprendere meglio la situazione reale del dataset: SELECT ST_GeometryType(geom), count(*) FROM table GROUP BY ST_GeometryType(geom); un parere da persone più esperte sarebbe gradito. provate a contattare Even Rouault sulle mailing lists di GDAL; nessuno meglio di lui e' in grado di darvi una risposta completa ed esaustiva per tutto quel che riguarda tutta la famiglia dei drivers OGR/SQLite. 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. 796 iscritti al 28/12/2017
Re: [Gfoss] Uno scambio di emails
On Wed, 31 Jan 2018 05:07:44 +0100, Alessandro Sarretta wrote: Mah Andrea, non riesco a interpretare nemmeno io se è un buontempone che si diverte a rompere le scatole e ha tanto tempo libero oppure qualcuno che non capisce di cosa si sta parlando, è convinto di capirlo e quindi pensa che tutti gli altri siano incompetenti mi sono letto tutto il carteggio; e devo dire sinceramente che e' stata una faticata, perche' pare piu' che altro un dialogo abbastanza stralunato dove in termini tecnici non si capisce mai bene di cosa si stia parlando esattamente. my 2 cents: l'interlocutore e' verosimilmente un grafico. cioe' uno che magari conosce bene strumenti di grafica vettoriale come Corel Draw mentre non padroneggia affatto gli strumenti CAD anche se sa che esistono (lo deduco dall'accenno al "collega geometra" che forse potrebbe aiutarlo a leggere i famigerati shapefiles), che non ha neppure la piu' pallida idea di cosa siano i dati geografici e tanto meno arriva ad immaginare che possano esistere i GIS. tutto questo, unito alla presunzione di essere un "espertone" di dati vettoriali in qualsiasi possibile declinazione, porta alla assoluta impossibilita' di trovare un terreno di discussione condiviso basato su ragionevoli elementi tecnici. finisce per diventare un confronto tra sordi, in cui uno degli interlocutori fraintende sistematicamente gli argomenti e le spiegazioni che l'altro cerca di mettere sul tavolo. l'ignoranza (=non sapere) non e' mai negativa se si accompagna ad una sana dose di auto-consapevolezza dei propri limiti e ad una vivace curiosita' che spinge ad apprendere concetti nuovi. diventa assolutamente nefasta quando si ammanta di supponenza e di false certezze, e finisce cosi' per diventrare testardo rifiuto o totale fraintendimento di tutto quello che non rientra in un quadro concettuale cristallizzato "a priori". consiglio dell'uomo saggio: "Mai discutere con un idiota. Prima ti trascina al suo livello e poi ti batte con l'esperienza." (Oscar Wilde) 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. 796 iscritti al 28/12/2017
Re: [Gfoss] [INFO] Re: pyspatialite in virtualenv
On Fri, 19 Jan 2018 11:54:12 +0100, Francesco P. Lovergine wrote:
Condivido l'inutilità di una replica del binding di sqlite3 per
Python
come tutti gli altri linguaggi. In questo periodo per motivi
lavorativi
uso più Perl di Python e per i medesimi motivi faccio brutalmente
qualcosa tipo:
--
# load Spatialite extension
$dbh->sqlite_enable_load_extension(1);
# this extension load instruction is platform specific...
my $sth = $dbh->prepare(qq/SELECT
load_extension('libspatialite.so')/);
eval { $sth->execute; };
if ($@) {
# in version 4.3 extension changed name
$sth = $dbh->prepare(qq/SELECT load_extension('mod_spatialite')/);
$sth->execute;
}
--
che però evidenzia la bruttezza intrinseca della cosa: caricare una
shared library
è qualcosa di platform specific a causa del fatto che
load_extension() è una funzione
che non cerca proprio di nascondere certi dettagli.
caro Frankie,
mi pare che al riguardo ci sia un po' di confusione; sia SQLite
che SpatiaLite si sono evolute nel corso degli anni, ed alcuni
dettagli sono significativamente cambiati con le versioni
piu' recenti.
SQLite a partire dalla versione 3.7.17 (rilasciata nel maggio
2013, quasi cinque anni fa) e' in grado di supportare una
"load_extension" realmente portabile cross-platform.
molte cose che si leggono in giro sono purtroppo basate
sul comportamento di versioni ormai morte e sepolte, che
oggi e' definitivamente superato.
con le versioni recenti di SQLite non c'e' piu' nessun
bisogno di specificare il suffisso .dll o .so o .dylib;
ci pensa automaticamente SQLite ad aggiungere il
suffisso appropriato per la piattaforma di run-time.
decisamente e' un grosso aiuto per scrivere codice
portabile tra piattaforme diverse.
attenzione pero'; tutto questo avviene solo se il nome
del modulo non contiene gia' di suo un suffisso; quindi
utenti e sviluppatori dovrebbero sempre avere l'accortezza
di evitare accuratamente di aggiungere qualsiasi tipo di
suffisso al nome del modulo.
secondo aspetto assulutamente critico che viene spesso
frainteso.
la load_extension() di SQLite e' direttamente basata
sulla dlopen() dei sistemi Posix (compreso Linux),
oppure sull'analoga LoadLibrary() di Windows.
entrambe andranno automaticamente a cercarsi il modulo
da caricare e le relative dipendenze tra le directories
"di piattaforma" abilitate al caricamento delle librerie
dinamiche; ovviamente i dettagli sono diversissimi tra
Linux e Win, ma il succo e' sempre il medesimo.
ne consegue che il modo migliore e piu' facilmente portabile
per caricare l'estensione SpatiaLite e' semplicemente questo:
SELECT load_extension('mod_spatialite');
in questo modo si lascia completamente mano libera a SQLite
di seguire al meglio tutte le regole specifiche della
piattaforma; cioe' il massimo che si possa chiede in termini
di effettiva portabilita' universale.
l'ultima spiaggia dettata da assoluta disperazione: se proprio
insistete SQLite e' anche in grado di caricare un modulo di
estensione identificato tramite un path relativo o assoluto;
ma a questo punto dovrebbe essere ben chiaro a tutti che una
cosa del genere rappresenta un vero e proprio attentato
contro la portabilita'.
purtroppo troppi tra gi utenti e gli sviluppatori ignorano
del tutto persino l'esistenza delle variabili d'ambiente.
l'eseprienza maturata sul campo insegna che molto spesso problemi
apparentemente irresolubili che impediscono il caricamento di
spatialite come estensione dinamica diventano invece banali
semplicemente configurando a modo la variabile LD_LIBRARY_PATH
(su Linux) oppure la PATH (su Win).
conclusione: oggi come oggi non e' piu' giustificato
sostenere che caricare un'estensione dinamica per
SQLite implichi necessariamente ammazzare la portabilita'
universale del codice.
basta solo seguire scrupolosamente le regole della piattaforma
specifica (largamente preferibile), oppure avere quel pizzico
di skill che serve per riconfigurare un ambiente custom nel
caso (sciagurato, ma praticamente inevitabile su WinZoz) in
cui si preferisca installare i moduli e le loro dipendenze in
qualche posizione "strana".
Va beh, sto troppo pigro per scassare gli zebedei upstream,
sono i 50 anni...
e allore cosa dovrebbe dire chi ormai viaggia sopra ai 60 ? :-P
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.
796 iscritti al 28/12/2017
Re: [Gfoss] Spatialite - calcolo lunghezza 3d
On Fri, 19 Jan 2018 13:15:57 +0100, Totò Fiandaca wrote:
Ho fatto un rapida prova con spatialite 4.4 e 4.5, stesso risultato:
la ST_3DLength() richiede il supporto della libreria librttopo,
e quindi e' disponibile solo sulle versioni piu' recenti
(appunto: 4.4 o 4.5)
SELECT
ST_3DLength(GeomFromText('LINESTRINGZ(0 0 0,1 1 1)'))
risultato:
1.732051
NB: devi uisare LINESTRINGZ
forse qua e' opportuno puntualizzare: a differenza di
PostGIS, SpatiaLite segue pedantemente le specifiche OGC,
e queste prevedono che nelle espressioni WKT il tipo
della geometria deve anche dichiarare esplicitamente
le dimensioni supportate.
n.b.: l'anomalia di PostGIS e' largamente giustificata
dal fatto che e' nato prima che OGC formalizzasse
definitvamente le specifiche per il WKT.
giusto alcuni esempi banali:
2D (XY)
---
ST_GeomFromText('LINESTRING(0 0,1 1)')
3D (XYZ)
---
ST_GeomFromText('LINESTRING Z(0 0 0,1 1 1)')
2D + misura (XYM)
---
ST_GeomFromText('LINESTRING M(0 0 0,1 1 1)')
3D + misura (XYZM)
---
ST_GeomFromText('LINESTRING ZM(0 0 0 0,1 1 1 1)')
naturalmente la regola si applica a tutti i tipi
geometrici (POINT, POLYGON etc)
n.b. secondo le specifiche OGC lo stile corretto
e' quello che vede uno spazio tra il nome del
tipo e le dimensioni, quindi p.es. "POLYGON ZM";
spatialite e' piu' tollerante, ed ammette un
numero arbitrario di spazi (anche nessuno) tra
i due elementi: "POLYGONZM" o "POLYGONZM"
sono perfetti sinonimi.
ovviamente se c'e' conflitto tra la dichiarazione
tipo+dimensioni ed il numero delle coordinate
effettivamente presenti il parsing dell'espressione
WKT fallira' tornando un bel NULL. esempio:
SELECT ST_GeomFromText('LINESTRING(0 0 0,1 1 1)');
---
NULL
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.
796 iscritti al 28/12/2017
Re: [Gfoss] pyspatialite in virtualenv
On Thu, 18 Jan 2018 16:33:54 +0100, pierluigi de rosa wrote: Ciao a tutti, qualcuno di voi ha mai avuto esperienze nell'installare pyspatialite in un virtualenv di python? Stavo lavorando con django ma sono impossibilitato nell'installare la libreria. Ottengo il seguente errore: __main__.HeaderNotFoundException: cannot find proj_api.h, bailing out Ho letto in rete si dice che manca libproj-dev solo che nel mio caso è installata. Altre idee o suggerimenti? ciao Pierluigi, io a proposito di pyspatialite posso dirti un'unica cosa; che il suo stesso ideatore, sviluppatore e maintainer (Lokkju Brennr aka Loki) e' convinto che oggi come oggi non andrebbe piu' usata. se hai la pazienza di leggerti tutti i dettagli (e per scoprire quali sono le possibili alternative), trovi tutto in questo post sulla ML di spatialite: https://groups.google.com/forum/#!topic/spatialite-users/o0jUwMUqx_g 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. 796 iscritti al 28/12/2017
Re: [Gfoss] spatialite e le virtualKNN
On Mon, 8 Jan 2018 18:44:55 +0100, Totò Fiandaca wrote:
Salve a tutti,
ho scoperto che QGIS supporta solo spatialite 4.3, credo sia l'ultima
versione stabile.
Sto studiando le virtualKNN, un modulo implementato nella spatialite
4.4,
ed ho scoperto che possono cambiare le sorti di un geodatabase.
ciao Toto',
occhio che la prima implementazione della KNN che trovi nella 4.4.0
era affetta da diversi problemi anche gravi che sono stati risolti
in seguito.
ti consiglio caldamente di utilizzare i sorgenti trunk che trovi sul
repository Fossil (4.5.0-devel) se vuoi essere sicuro di avere un
KNN che funzioni correttamente.
Ho scritto un articolo e vorrei sottoporlo all'attenzione di persone
più esperte di me.
Ho alcuni dubbi sui trigger che ho realizzato, soprattutto su quelli
senza
far uso delle virtualKNN.
ho testato il tuo trigger, e funziona correttamente.
ci trovo un unico difettuccio: utilizza ben tre UPDATE per
ciascuna INSERT, e ciascuna delle UPDATE lancia una subquery
KNN che e' un'operazione computazionalmente pesantuccia.
... non mi pare la via migliore per ottenere performances
di buon livello.
quindi ho provato a razionalizzare e semplificare, e sono
arrivato a produrre questo:
CREATE TRIGGER ins_punti AFTER INSERT ON punti
BEGIN
INSERT OR REPLACE INTO punti (fid, nome_strada, data_ins, distanza,
geom)
SELECT NEW.ROWID, s.nome_strada, DateTime('now'), k.distance,
NEW.geom
FROM knn AS k
LEFT JOIN strade AS s ON (k.fid = s.pk_1)
WHERE k.f_table_name = 'strade'
AND ref_geometry = NEW.geom
AND k.max_items = 1;
END
a questo punto e' ovvio che serve un secondo Trigger
che entri in azione quando un "punto" gia' inserito
viene spostato in una nuova posizione.
come vedi il secondo Trigger e' praticamente identico
al primo, tranne che per le dichiarazioni nella prima
riga.
CREATE TRIGGER upd_punti AFTER UPDATE OF geom ON punti
BEGIN
INSERT OR REPLACE INTO punti (fid, nome_strada, data_ins, distanza,
geom)
SELECT NEW.ROWID, s.nome_strada, DateTime('now'), k.distance,
NEW.geom
FROM knn AS k
LEFT JOIN strade AS s ON (k.fid = s.pk_1)
WHERE k.f_table_name = 'strade'
AND ref_geometry = NEW.geom
AND k.max_items = 1;
END
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.
796 iscritti al 28/12/2017
Re: [Gfoss] Spatialite vista materializzata
On Mon, 8 Jan 2018 17:36:32 +0100 (CET), falcerisim...@inwind.it wrote: Ciao a tutti! Ho appena scaricato il mitico spatialite 4.4. da http://www.gaia-gis.it/gaia-sins/windows-bin-amd64-test/ Volevo sapere gentilmente se è possibile creare con spatialite una vista materializzata, in modo da semplificare il lavoro di inserimento dei dati da parte di utenti meno esperti. ciao Simone, spatialite non supporta le viste materializzate per un motivo molto semplice; perche' SQLite non le supporta. spatialite e' semplicemente un'estensione Spatial che estende le capacita' base di SQLite in modo tale da aggiungere la capacita' di gestire il data-type Geometry, ma non puo' mai in nessun modo uscire fuori dal perimetro del supporto SQL cosi' come viene reso disponibile dallo stesso SQLite. hint: prima ancora di metterti ad usare SpatiaLite e' sempre bene studiarsi a fondo cosa offre realmente SQLite in termini di funzionalita' SQL standard: https://www.sqlite.org/lang.html nota bene: anche su SQLite e' comunque possibile realizzare delle "writable views", cioe' delle VIEW in grado di accettare operazioni di INSERT, UPDATE e DELETE, che e' qualcosa che si avvicina molto al classico concetto di vista materializzata. ma per ottenere una "writable view" su SQLite e' indispensabile scriversi (a mano) tutta una serie di Triggers; il che, detto per inciso, e' un lavoro abbastanza complicato che richiede una comprensione ed una familiarita' abbastanza spinte con gli aspetti piu' complessi ed esoterici del linguaggio SQL. insomma, scordati "da parte di utenti meno esperti"; e' qualcosa che puo' funzionare ragionevolmente bene solo se viene pianificato ed implementato accuratamente "da parte di utenti particolarmente esperti". -- se vuoi iniziare a studiarti come funzionano le "writable views" su SQLite/SpatiaLite puoi cominciare da qua: https://www.gaia-gis.it/fossil/libspatialite/wiki?name=writable-view se usi spatialite_gui troverai che esiste un wizard grafico che semplifica di molto la creazione di una "writable view" rendendola un lavoro praticamente automatico. 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. 796 iscritti al 28/12/2017
[Gfoss] sicurezza informatica ? sempre piu' un'illusione
il 2018 appena iniziato si apre con una notizia drammatica; alcuni autorevoli gruppi di ricerca tra cui Google ProjectZero hanno identificato Spectre e Meltdown, due gravi criticita' che affliggono tutte le CPU prodotte da Intel negli ultimi 20 anni. pare che comunque le medesime criticita' siano presenti anche sulle CPU di AMD e di ARM ... non si salva nessuno. attenzione: questo non e' il solito tipo di criticita' legato a difetti SW a cui siamo gia' abituati. In questo caso e' un problema a livello HW della stessa CPU che consentirebbe ad un hacker malevolo di accedere direttamente alla memoria anche senza possedere i relativi permessi di accesso, consentendo cosi' il furto di passwords e di altri dati sensibili e riservati. dato che il problema e' causato dai meccanismi interni della CPU affligge indifferentemente qualsiasi sistema operativo compreso Linux. sono gia' in corso di distribuzione le prime patch (almeno parziali) per Windows e per Linux, che pero' potrebbero avere l'effetto indesiderato di rallentare in modo sensibile il funzionamento della CPU. consiglio: aggiornate tempestivamente i vostri sistemi non appena possibile. [1] https://www.tomshw.it/bug-microprocessori-tutto-meltdown-spectre-90564 [2] https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-every-modern-processor-has-unfixable-security-flaws/ 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. 796 iscritti al 28/12/2017
Re: [Gfoss] esempio Trigger semplice
On Fri, 15 Dec 2017 08:02:22 +0100, Andrea Peri wrote: Tutto bello. Pero' attenzione ad aggiungere i triggers. Il maggior rischio e' pensare di usarli per fare cose troppo sofisticate. un trigger e' esattamente come un coltello molto affilato; se lo sai usare bene e con giudizio puo' servire per fare tante cose utili (per esempio in cucina), ma se lo usi male e senza criterio puo' finire per ferire anche gravemente te stesso o gli altri ... ma la colpa non e' mai del coltello, e' sempre tutta di chi lo maneggia :-D Con il rischio che poiche' non si a mai cosa in futuro ci si deve fare con tali dati, di ritrovarsi magari dopo qualche mese a vedere comportamenti anomali su un applicativo e dimenticarsi che dentro la BD vi' sono dei triggers che facevano certe operazioni e che guarda caso interfericono con altre operazioni all'epoca non preventivate. I triggers non sono facilmente rilevabili , e, specialmente su spatialite, non credo che si possano nemmeno rimuovere senza interferire con i dati stessi. Qui pero' forse lo sa' meglio Furieri. Forse mi sbaglio, ma temo che per rimuovere un trigger su una tabella spatialite sia necessario droppare la tabella con tutto il suo contenuto. Se cosi' fosse occorre stare parecchio attenti a usarli , perche' se per rimuovere un trigger che da noia si deve cancellare tutti i dati in tale tabella. Si fa' certamente, ma diventa macchinoso e complicato . no, su SQLite non ci sono problemi di sorta a rimuovere un trigger; basta semplicemente eseguire: DROP TRIGGER ; una volta rimosso il trigger tutti gli effetti connessi cesseranno immediatamente. ovviamente i dati gia' presenti nella tavola rimarranno del tutto inalterati. il limite di SQLite e' che a differenze di PostgreSQL non supporta "ALTER TABLE DISABLE TRIGGER", "ALTER TABLE ENABLE TRIGGER" o "ALTER TRIGGER". su SQLite l'unico modo per modificare un qualunque trigger gia' definito e' quello di fare una "DROP TRIGGER" seguita da una nuova "CREATE TRIGGER". Quindi attenzione, massima attenzione a usare i triggers. non posso far altro che associarmi alla raccomandazione di Andrea; i trigger sono tanto potenti quanto pericolosi, e quindi vanno maneggiati con estrema cautela e solo dopo avere effettuato a monte un testing molto pignolo e pedante a scanso di brutte sorprese. 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. 801 iscritti al 19/07/2017
Re: [Gfoss] esempio Trigger semplice
On Thu, 14 Dec 2017 22:19:25 +0100, Massimiliano Moraca wrote:
Sti trigger mi stanno inTRIGGando :P
Con un trigger è possibile anche tenere traccia dell'evoluzione
temporale di un vettore? Ad esempio poligoni creati, modificati,
cancellati..?
Massimiliano,
certo che puoi; i triggers sono un meccanismo universale,
ci puoi fare qualsiasi cosa che ti viene in mente
(o quasi ...)
l'unico limite e' la tua capacita' creativa di saperti
"inventare" un buon modello dati; naturalmente serve
anche una base molto solida di conoscenza teorica su
SQL con tutte le sue estensioni Spatial, cosi' come e'
indispensabile quella certa "praticaccia spicciola" che
si acquisisce solo a forza di lavorare sul campo imparando
piu' che altro dai propri errori.
giusto per analizzare per sommi capi il tuo esempio
relativo all'evoluzione storica dei dati, e' molto
piu' semplice di quanto tu possa credere:
1. ti crei una tavola di appoggio in cui andrai a
registrare tutte le successive modifiche delle
tue geometrie. una scelta saggia sarebbe quella
di introdurre un opportuno vincolo FK che associ
direttamente ciascuna "riga-versione" con la
corrispondente riga della tavola-madre.
cosi' come sarebbe opportuno inserire un timestamp
che tenga traccia della data-ora in cui e' avvenuta
la modifica; datti un'occhiata a DateTime('now')
2. a questo punto vai ad installare tre triggers
sulla tavola-madre, uno per la Insert, uno per
la Update ed uno per la Delete.
ovviamente ciascuno di questi non fara' altro
che prendere la geometria e salvarla permanentemente
sulla tavola-versioni associandola al timestamp
corrente.
basta; non serve altro. e' piu' facile da implementare
che da spiegare.
concetti da tenere bene a mente:
un Trigger e' semplicemente un gestore di eventi.
una volta che il Trigger e' correttamente installato
scattera' automaticamente tutte le volte che si
verifica l'evento in oggetto.
l'azione specifica di ciascun Trigger e' determinata
da un "pezzo" di SQL che sta a te scrivere nel modo
che ritieni piu' opportuno; hai tutta la liberta'
che vuoi di fare qualsiasi cosa che ti passi per la
zucca, basta solo che tu trovi il modo di tradurla
in una appropriata sequenza di comandi SQL.
ovviamente liberta' e responsabilita' sono sempre
due facce della medesima medaglia; se non funziona
e' sicuramente colpa tua, e ti dovrai quindi armare
di santissima pazienza per fare tutto il debugging
del caso (che e' poi la vera essenza di qualsiasi
sviluppo sw; un bravo sviluppatore non e' uno bravo
a scrivere codice, e' soprattutto uno bravo a fare
debugging)
Mi indicate una risorsa da cui studiare? Anche un libro se non c'è
nulla online...
non credo proprio che esista nulla di specifico
relativo ai triggers, al massimo puoi trovare qualche
manuale generico su SQL che avra' un capitoletto
sui meccanismi generali dei triggers.
dovresti sicuramente trovare qualche manuale piu' o
meno ponderoso in qualsiasi libreria universitaria.
per tutto il resto serve tenere sempre sotto mano
la doc tecnica del tuo DBMS preferito [1], ma soprattutto
servono tempo, pazienza e perseveranza, uniti ad un
pizzico di intuizione e di fantasia creativa.
[1] https://www.sqlite.org/lang.html
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.
801 iscritti al 19/07/2017
Re: [Gfoss] esempio Trigger semplice
On Thu, 14 Dec 2017 18:18:36 +0100 (CET), falcerisim...@inwind.it
wrote:
Ciao a tutti,
non so quasi niente di triggers, ma desidero condividere la
conoscenza di un semplice esempio di trigger.
In questo esempio si tratta del calcolo automatico della lunghezza di
polilinee ogni qualvolta se ne disegnino di nuove oppure aggiornando
un solo vertice.
In questo modo non dovrete più preoccuparvi di lanciare manualmente
ogni volta il calcolo delle lunghezze!
In pratica si devono creare due triggers: insert e update.
Testato su Spatialite. Enjoy!
Es:
[
CREATE TABLE ril_lunghezze
(pk INTEGER NOT NULL PRIMARY KEY,
indirizzo TEXT,
lunghezza DOUBLE,
note TEXT);
SELECT
AddGeometryColumn('ril_lunghezze','geom',32632,'LINESTRING',2);
CREATE TRIGGER insert_calc_length AFTER INSERT ON ril_lunghezze
BEGIN
UPDATE ril_lunghezze
SET
lunghezza= ROUND(ST_LENGTH(geom), 2)
WHERE ROWID=NEW.ROWID;
END
CREATE TRIGGER update_calc_length AFTER UPDATE ON ril_lunghezze
BEGIN
UPDATE ril_lunghezze
SET
lunghezza= ROUND(ST_LENGTH(geom), 2)
WHERE ROWID=NEW.ROWID;
END
]
Bravo Simone,
hai visto che scrivere un trigger e' tutto sommato facile ?
ed e' uno strumento molto potente, che se viene usato bene
e nel modo corretto puo' consentire di implementare buona
parte della business logic specifica del processo direttamente
dentro al DBMS.
un possibile miglioramento / ottimizzazione:
CREATE TRIGGER update_calc_length
AFTER UPDATE OF geom ON ril_lunghezze
- come l'hai scritto tu il trigger scattera' inesorabilmente
per ogni UPDATE; ma se la geometria e' sempre quella di prima
e' un inutile perditempo.
- se invece lo definisci come "AFTER UPDATE OF geom" il
trigger scattera' solo quando serve realmente, e cioe'
quando la geometria risulta effettivamente modificata.
infine una domanda (ma giusto per curisita'): perche'
usi la ROUND() ?
capisco che lo scopo e' quello di arrotondare le lunghezze
con due sole cifre decimali, ma cosi' rischi di alterare
un po' troppo pesantemente i dati.
forse e' meglio se registri le lunghezze con tutti i
decimali possibili, e magari arrotondi a due decimali
quando poi vai ad interrogare. esempio:
SELECT Sum(lunghezza) FROM ril_lunghezze;
oppure
SELECT Round(Sum(lunghezza), 2) FROM ril_lunghezze;
con la seconda arrotondi il totale finale, e quindi
non introduci scostamenti significativi dal valore
reale.
invece con la prima rischi che la somma di tanti
valori arrotondati a monte vada ad amplificare
gli scostamenti.
a lume di naso sarebbe meglio evitare di arrotondare
tutte le volte che scatta il trigger.
ciao Sndro
___
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.
801 iscritti al 19/07/2017
Re: [Gfoss] ST_Union e PostGIS
On Wed, 13 Dec 2017 17:46:13 +0100, Massimiliano Moraca wrote: Da premettere che non ho usato(ancora) nessun plugin o tool di QGIS per manipolare il db. I TRIGGER (di cui so 0!) potrebbero ovviare alla creazione delle view? si e no: tu hai due problemi distinti e separati. 1. far girare le cose sotto SQL; e qua la tua View (proprio quella che hai gia' realizzato) potrebbe risultare decisamente utile. 2. riuscrire a convincere QGIS che deve visualizzare determinati dati; qua scattano tutta una serie di vincoli ulteriori, e la presenza di una aggregata crea un sacco di problemi. insomma, detto con altre parole, a te serve gestire due "layers": a. il primo e' un vero e proprio layer/tavola, e su cui andrai a fare INSERT/UPDATE/DELETE b. il secondo rappresenta semplicemente l'aggregazione del primo, ad eclusivo beneficio dei processi di visualizzazione di QGIS. definire alcuni opportuni Triggers potrebbe consentirti di rendere totalmente automatico il processo di corretta sincronizzazione tra le due tavole. Mi spiego meglio. Mi sono rassegnato, per ora, a creare le tabelle e non le view: un trigger potrebbe fare in modo che aggiornata la tabella principale(ammesso si possa fare questo distinguo) si attivi automaticamente l'aggiornamento di quella "correlata" all'area aggiornata? esattamente: e' proprio cosi'. se vuoi entrare piu' in profondita' ti consiglio di studiarti il codice SQL dei triggers a supporto dello Spatial Index. prova a spulciare con SpatiaLite GUI una qualsiasi tavola con geometria e Spatial Index; vedrai che ha associati tre triggers il cui nome sara' "gii__" e "giu__" come vedrai, il trigger "gii_" intercetta tutte le INSERT sulla tavola-madre, ed aggiorna coerentemente lo Spatial Index. invece "giu_" intercetta tutte le UPDATE (ma solo nel caso in cui la geometria sia realmente variata), ed anche in questo caso aggiorna lo SpatialIndex. ovviamente il tuo caso richiedera' un approccio diverso, ma l'idea di fondo e' identica; ogni evento che tocca la tavola-madre dovra' riflettersi automaticamente sull'altra tavola. Come ho scritto stavo provando con i filtri di QGIS, ma forse Sandro quando parlavi dell'approccio ingannevole di QGIS ti riferivi a questo? mi riferivo semplicemente alla mia esperienza diretta maturata sulla mailing list di spatialite. per il 90% degli utenti (power users Spatial SQL, sviluppatori Java/C++/Python etc) il problema delle Spatial Views e delle Views "updatable" non si pone proprio, e' qualcosa che non interessa o che al massimo viene percepito come un'ardita stravaganza tecnica. tutte le domande relative a questi due argomenti arrivano solo ed esclusivamente dagli utenti di qgis. pare abbastanza ovvio che e' una specie di "bisogno indotto" ;-) 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. 801 iscritti al 19/07/2017
Re: [Gfoss] ST_Union e PostGIS
On Wed, 13 Dec 2017 17:05:43 +0100, Sandro Santilli wrote: On Wed, Dec 13, 2017 at 04:38:22PM +0100, Massimiliano Moraca wrote: Tra l'altro noto che le VIEW rendono il caricamento dei dati in QGIS un processo molto lento, cosa che non avviene nelle table. Perche' non puo' usare un indice su un oggetto che non esiste ancora fino al momento della SELECT, immagino. Se la materializzi, e ci definisci un indice, dovresti risolvere. Per l'aggiornamento "automatico" potresti usare dei trigger (almeno in PostGIS, non so in Spatialite). Strk, mi hai letto nel pensiero ;-) SQLite offre un supporto molto efficiente per i Triggers. [1] https://www.sqlite.org/lang_createtrigger.html Se Massimiliano se la sente non sarebbe per nulla difficile aggiornare automaticamente la tavola aggregata ogni volta che viene modificata la tavola madre. ok, richiederebbe la scrittura di un po' di codice SQL a supporto di qualche Trigger da impiantare da zero. ma alla fine otterebbe qualcosa di sicuramente piu' efficiente e robusto di quel che puo' ottenere automaticamente dai vari tool di QGIS basati sulle improbabili Spatial Views "updatable" che sono semplicemente un tentativo decisamente estremo per cercare di nascondere "sotto al cofano" tutte le numerose differenze di architettura che ci sono tra PostgreSQL e SQLite. 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. 801 iscritti al 19/07/2017
Re: [Gfoss] ST_Union e PostGIS
On Wed, 13 Dec 2017 16:38:22 +0100, Massimiliano Moraca wrote: Tra l'altro noto che le VIEW rendono il caricamento dei dati in QGIS un processo molto lento, cosa che non avviene nelle table. Massimiliano, nota bene: su SQLite (come su tantissimi altri DBMS) le VIEW sono oggetti READ_ONLY; cioe' roba che puoi interrogare, ma che non potra' mai essere modificata. c'e' un unico modo per ottenere su SQLite una VIEW che supporti gli aggiornamenti, e consiste nel riuscire a definire sapientemenre un sofisticato waltzer ben orchestrato tutto basato sui TRIGGER. riassunta all'osso la logica e' questa: - ciascuno di questi triggers deve intercettare gli eventi di tipo INSERT/UPDATE/DELETE che possono interessare la View - dopo di che il trigger provvede ad lanciare una seconda INSERT/UPDATE/DELETE che questa volta avra' come target la/e tavola/e che stanno sotto alla View. stringendo: se tutti i triggers sono scritti dal Dio dello SQL in persona sara' comunque un processo abbastanza lento, perche' quella che apparentemente sembra una banale INSERT finisce per diventare materialmente una catena piu' o meno ramificata di ulteriori INSERT. ma se (come non pare affatto improbabile) i triggers sono scritti "alla garibaldina" senza curarsi troppo delle ottimizzazioni (magari da qualche tool automatico e cieco), allora potrebbe facilmente diventare un processo decisamente _MOLTO_ inefficiente. l'approccio dei data-providers di QGIS e' spesso ingannevole; ti presentano sempre ed in tutti i casi una specie di "modello uniforme", che magari funziona anche (seppure a volte in modo decisamente avventuroso, rischioso e border-line), ma non ti dicono mai se quel determinato tipo di operazioni in relazione ad uno specifico DBMS e' piu' o meno sensato. io posso solo darti il mio personalissimo parere maturato in base ad una certa conoscenza dei meccanismi di SQLite; io personalmente mi guarderi bene dal mettere in piedi un baraccone basato su Views che consentano le scritture e gli aggiornamenti tramite triggersi. ptrei prendere in considerazione l'idea solo se qualcuno mi tenesse una pistola puntata alla tempia :-D 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. 801 iscritti al 19/07/2017
Re: [Gfoss] ST_Union e PostGIS
On Wed, 13 Dec 2017 13:56:20 +0100, Massimiliano Moraca wrote:
Come ho detto a Marco ogc_fid è chiave primaria. Avevo notato
un po' di tempo fa che nel creare le VIEW SpatiaLite ti chiede
comunque un id dalla tabella sorgente, id assegnato poi random.
Massimiliano,
stai ben attento perche' qua rischi di combinare un bell'arrosto.
1. "nel creare le VIEW SpatiaLite ti chiede comunque un id dalla
tabella sorgente"
esatto, e' proprio cosi': per la precisione ti chiede di
specificare quale sia il nome della colonna-VIEW che riporta
il ROWID che identifica la riga della tavola-input che
fornisce la geometria presente nella View.
Corollario: una Spatial View di SpatiaLite non puo' mai
fornire una geometria che sia il risultato di una funzione
o il frutto di una aggregazione.
_DEVE_ necessariamente essere una geometria presa tal
quale da una delle tavole di input della View, senza che
intervenga nessuna manipolazione di sorta.
e la colonna "rowid" presente nella Spatial View deve
consentire di tenere coerentemente in synchro le righe
della tavola-madre con il suo eventuale Spatial Index.
2. "id assegnato poi random"
assolutamene _NO_
non puo' essere random, _DEVE_ identificare esattamente
la riga della tavola che fornisce la geometria (ergo, o
si tratta di una PK oppure in forma piu' geerica di un
ROWID).
e c'e' un motivo assolutamente stringente per imporre
questo vincolo: altrimenti lo Spatial Index (che e' sempre
basato sulla tavola primaria e non sulla View) impazzisce,
e fornira' risultati padellati di pura fantasia con
risultati folli e potenzialmete devastanti.
in buona sostanza, se nella colonna ROWID della Spatial
View fai in modo che ci finiscano "valori random" stai
facendo tutto il possibile per massacrare la logica di
funzionamento dello Spatial Index.
per inciso, ti ricordo che su SQLite/SpatiaLite lo
Spatial Index R*TRee non e' affatto un "indice", ma e'
semplicemente un'ulteriore tavola, anzi per l'esattezza
e' una VirtualTable.
funziona, e funziona pure in modo molto efficiente, ma
esige lo scrupoloso rispetto di tutta una serie di vincoli
basati sullo scrupoloso rispetto dei JOIN relazionale
basati sul ROWID, altrimenti salta tutto per aria.
hint: ma perche' vuoi usare proprio una Spatial View ?
nel tuo caso, se ho capito bene il problema, sarebbe molto
piu' opportuno materializzare ancora un'altra tavola, p.es.:
CREATE TABLE dipart2 AS
SELECT cd_diparti, dipartimen, ST_Union(geom) AS geometry
FROM dipartimenti
GROUP BY cd_diparti;
SELECT RecoverGeometryColumn('dipart2', 'geometry', ..);
SELECT CreateSpatialIndex('dipart2', 'geometry');
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.
801 iscritti al 19/07/2017
Re: [Gfoss] ST_Union e PostGIS
On Wed, 13 Dec 2017 12:13:37 +0100, Massimiliano Moraca wrote: Buongiorno, in QGIS con un virtual layer scrivendo questa query: *SELECT ST_Union(geom) AS geometry, ogc_fid, cd_diparti, dipartimenFROM dipartimentiGROUP BY cd_diparti;* Ottengo l'effetto dissolve che mi interessa(anche in SpatiaLite. La stessa query in PostGIS mi genera invece questo errore: *ERROR: ERRORE: la colonna "dipartimenti.ogc_fid" deve comparire nella clausola GROUP BY o essere usata in una funzione di aggregazioneLINE 3: ogc_fid, ^SQL state: 42803Character: 39* Massimiliano, occhio ai dettagli, a volte sono assolutamente critici. i due dialetti SQL supportati rispettivamente da PostgreSQL e da SQLite si assomigliano, ma non sono affatto identici. l'implementazione delle clausole GROUP BY e' uno dei punti in cui si nota maggiormente la diversitra' tra i due: su SQLite e' decisamente flessibile e molto pratica da usarsi, mentre su PostgreSQL e' molto piu' rigida e pedante. scendendo nei dettagli, SQLite non ti impone mai il vincolo per cui tutte le colonne presenti nel dataset devono essere obbligatoriamente definite nella GROUP BY oppure devono essere il risultato di una funzione di aggregazione. Viceversa per PostgreSQL il vincolo e' stringente. nota: inserire "ogc_fid" (che si suppone sia una PK) tra i risultati senza citarlo nella GROUP BY non ha senso logico; SQLite accetta tranquillamente questa condizione, ma poi scoprirai che nel resultset di ritorno ci troverai semplicemente un valore pescato a casaccio tra tutti quelli che presentano il medesimo valore per "cd_diparti". 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. 801 iscritti al 19/07/2017
Re: [Gfoss] WMS Ufficiale Agenzia delle Entrate
On Wed, 13 Dec 2017 11:24:21 +0100, Maurizio Napolitano wrote: - tawolare un progettino che mi sono sviluppato per i fatti miei con i dati catastali trentini https://tavolare.labmod.org ... e che prima o poi sistemerò inserendo i dati altoatesini ed altro (fra cui comprare il certificato SSL) Napo, aggiornati :-D da un paio d'anni esistono certificati SSL per i web servers che sono del tutto gratuiti e che vengono riconosciuti da qualsiasi browser. non solo: il rilasccio ed il rinnovo dei certificati sono del tutto automatici ed istantanei, basta semplicemente installare sul server un sw (rigorosamente open source) che gestisce in modo "automagic" tutti gli step di verifica e validazione della reale identita' del server ... con due click ti levi definitivamente il pensiero ;-) [1] https://letsencrypt.org/ [2] https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-debian-8 [3] https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-centos-7 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. 801 iscritti al 19/07/2017
Re: [Gfoss] aree sovrapposte in shape file solo per alcuni software
On Thu, 7 Dec 2017 12:28:16 +0100, Stefano Romanelli wrote: Buongiorno a tutti, ho il seguente problema con una serie di shape file relativi all'uso suolo dell'Honduras ad es [0]: in pratica GDAL (OGRINFO), QGIS e GRASS GIS identificano una serie di aree sovrapposte (aree molto grosse, non piccole sovrapposizioni), mentre SPATIALITE, POSTGIS, ARCVIEW 3.2 e ARCMAP non le identificano e le aree interrogate (doppie per i software prima citati) forniscono le risposte giuste sulla classe di uso suolo. Ciao Stefano, nessuno dei sw da te citati e' in grado di calcolarsi autonomamente le operazioni geometriche (come p.es. le intersezioni/sovrapposizioni etc); tutti quanti (almeno quelli FLOSS/GFOSS) delegano questi lavori alla libreria GEOS; non ho idea di cosa usino ArcView ed ArcMap, suppongo roba loro proprietaria. il problema e' che la GEOS e' disponibile in tante versioni successive, che a volte possono fornire risultati differenti (p.es. perche' si e' scoperto in seguito che c'era qualche bacarozzolo che e' poi stato eliminato e risolto nelle versioni successive). vedo che tu riporti le versioni per svariati pacchetti, ma quello che sarebbe realmente significativo sarebbe andare a vedere quale versione della GEOS viene realmente utilizzata caso per caso. nota: molto spesso questi "risultati strani" sono causati da geometrie sporche che possono trarre in inganno gli algoritmi di calcolo delle relazioni spaziali. ti suggerirei di verificare questo aspetto, p.es. utilizzando la funzione ST_IsValid disponibile sia sotto PostGIS che sotto SpatiaLite. nel caso in cui effettivamente nei tuoi datasets ci fossero delle geometrie invalide dovresti riuscire a correggerle automaticamente usando la ST_MakeValid (anche questa supportata tanto da PostGIS come da SpatiaLite). 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. 801 iscritti al 19/07/2017
Re: [Gfoss] Da Linee 3D a Poligoni 3D in QGIS-Spatialite
On Wed, 29 Nov 2017 08:08:44 -0700 (MST), titino2 wrote: Ciao a tutti. Sto riscontrando numerosi problemi per quanto riguarda la costruzione di uno strato poligonale partendo da uno strato lineare. Le linee che utilizzo sono di tipo Linestring ZM (st_geometrytype(geometry)) e dove si intersecano, o sono spezzate o sono perfettamente "snappate" ad un vertice (eseguiti tutti i controlli di GRASS v.clean); partendo da queste linee vorrei produrre uno strato poligonale 3D. ciao Titino2, (visto che non ti firmi ti chiamero' con il nome della tua mailbox), c'e' un punto che non mi e' del tutto chiaro. quando tu dici "dove si intersecano o sono spezzate o sono perfettamente snappate ad un vertice" intendi dire che ti stai aspettando che vengano applicati automaticamente tutta una serie di "tagli" la dove ci sono intersezioni tra i tuoi Linestrings ? sarebbe importante chiarire meglio, perche' come vedremo tra poco non si tratta affatto di un dettaglio irrilevante. Le linee sono caricate all'interno di un db SpatiaLite. questo dettaglio e' praticamente irrilevante; quello che e' invece assolutamente critico e' identificare con chiarezza quale sw stai usando per le tue elaborazioni: - quando parli di strumenti e tool box di QGIS ovviamente stai usando QGIS; il fatto che poi alla fine i dati vadano a finire dentro ad un DB spatialite oppure dentro ad uno shapefile o che altro non puo' avere nessuna influenza. - quando invece parli di funzioni SQL e di query allora stai realmente usando SpatiaLite, ed in questo caso usare o meno QGIS e' del tutto irrilevante. io ti rispondero' solo ed esclusivamente per quanto riguarda SpatiaLite. ho provato con delle funzioni geometriche tipo st_buildarea, st_poligonize o st_makepolygon ma anche in questo caso i risultati sono stati molto poco soddisfacenti (sospetto per mia incapacità nello scrivere la query correttamente). ok, queste sono effettivamente funzione SQL di SpatiaLite. occhio pero' che sono molto diverse l'una dall'altra, non le puoi certo usare a capocchia come se fossero la stessa cosa. ti confermo comunque che tutte loro rispettano fedelmente le dimensioni che ricevono in input, ragion per cui se i tuoi Linestrings sono XYZM anche i Polygons in output saranno altrettanto XYZM. dettagli fortemente critici (specie nel tuo caso): - la ST MakePolygon() si limita semplicemente a trasformare i Linestrings "chiusi" (con il primo vertice esattamente sovrapposto all'ultimo) in Rings e quindi in Polygons. ma se i tuoi Linestrings non sono gia' di per se "chiusi" la ST_MakePolygon() ti tornera' semplicemente dei NULL. quindi in base alle scarne notizie che ci hai dato, direi proprio che la ST_MakePolygon() non puo' essere la soluzione giusta per il tuo problema. - la ST_BuildArea() e' un po' piu' sofisticata; se gli passi tanti "pezzettini stagliuzzati" prova a riassemblarli in modo tale da formare dei Rings, e quindi dei Polygons. Attenzione pero': i "pezzettini" devono essere gia' tagliati a monte, perche' la ST_BuildArea() di per se non taglia mai nulla (per definizione), si limita semplicemente a riassemblare i Linestrings esattamente per come li ha ricevuti. Se non ci riesce (per esempio perche' ancora ci sono delle intersezioni non tagliate, oppure perche' "avanzano pezzi inutilizzati") ovviamente fallisce. - infine c'e' la ST_Polygonize() che e' molto simile alla ST_BuildArea() eccetto che e' una funzione _AGGREGATA_, cioe' non lavora riga per riga ma elabora tutte le righe del dataset di input in un sol colpo. detto in soldoni: alla fine ti ritornera' un _SINGOLO_ MultiPolygon, che tu dovrai pazientemente risolvere in tanti Poligoni elementari (ma lo puoi fare abbastanza facilmente chiamando la ElementaryGeometries). se ho capito correttamente il tuo problema e' questa la funzione che fa al caaso tuo (previo "stagliuzzamento" preventivo) insomma, queste funzioni fanno esattamente quello che ti aspetti da un classico approccio coerente di tipo SQL: - evitano accuratamente di fare "magie nere" full-auto in cui non si capisce mai come siamo arrivati al risultato finale in un unico passaggio. - fanno invece tanti piccoli passettini elementari, molto piu' facili da tenere sotto rigoroso controllo uno alla volta. ovviamente e' un approccio piu' flessibile, ma richiede uno sforzo piu' grande da parte dell'utente per produrre i risultati sperati. Comunque da tutte queste prove la funzione che più si avvicina al risultato da me sperato è il tool poligonize peccato che mi restituisce poligoni 2D. Ho provato con ArcGis che ha generato dei perfetti poligoni 3D coerenti con le linee di partenza. Avete qualche consiglio da darmi? consiglio #1 prova a tagliare preventivamente tutti i tuoi Linestrings la dove ci sono delle intersezioni; prova a dare un'occhiata alla ST_LinesCutAtNodes(), potrebbe semplificarti il lavoro. dopo di che darai tutto in pasto
Re: [Gfoss] WMS Ufficiale Agenzia delle Entrate
On Mon, 27 Nov 2017 02:57:14 -0700 (MST), pigreco wrote: geodrinx wrote Domanda: ma a voi funziona, questo WMS ? Ho fatto varie prove su QGIS 2.18, il wms : https://wms.cartografia.agenziaentrate.gov.it/inspire/wms/ows01.php funziona, inizialmente da un errore ma basta ignorarlo. ho fatto alcune prove, ed ho scoperto che neppure il WMS di RasterLite2 riesce ad accedere al servizio perche' c'e' un errore bloccante nella catena delle Certification Authorities che autenticano il certificato X.509 utilizzato dal server del catasto: CURL error: Peer certificate cannot be authenticated with given CA certificates la cosa strana e' che invece (anche su Linux) Firefox non rileva alcun errore o criticita' quando accede direttamente questa URL: https://wms.cartografia.agenziaentrate.gov.it/inspire/wms/ows01.php?=WMS=GetCapabilities andando a scavare viene fuori che il certificato X.509 incriminato e' rilasciato da DigiCert, una azienda strettamente legata a Microsoft. pare proprio che CURL incontri diversi problemi nel riconoscere come valida la CA di DigiCert, come parrebbe testimoniare questo lungo thread su StackExchange: https://stackoverflow.com/questions/20941808/curl-not-correctly-applying-ca-certificate-file conclusione: non possiamo certo dire che la CA scelta da Sogei per conto del Catasto sia "open source friendly". purtroppo l'uso del protocollo HTTP (non cifrato) non e' supportato, e quindi in ultima analisi l'accesso al WMS del catasto implica per tutti coloro che usasno free sw di fidarsi di una catena di autenticazione farlocca e non verificabile; non e' proprio il top per la sicurezza informatica :-P ultima stravaganza: il certificato del sito del catasto scade a Novembre 2020, cioe' tra ben tre anni :-) in genere si ritiene che la sicurezza dei certificati si basa essenzialmente sul loro continuo rinnovo con frequenze molto ravvicinate. giusto per dire, la ben nota CA open source Let's Encrypt rilascia esclusivamente certificati server con validita' di tre mesi, altro che tre anni :-D 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. 801 iscritti al 19/07/2017
