[Gfoss] art. 68 - linee guida valutazione comparativa
Non mi pare sia già passata qui la notizia: http://www.digitpa.gov.it/notizie/riuso-valutazione-comparativa-online-circolare Buona lettura Piergiovanna ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] QGis2threejs plugin !!!!
/ kikapu wrote Ho una domanda, forse banale: quale strumento/comando QGis deve essere usato per il drap di immagini (ortofoto, pendenze, ecc) sul DEM? / Intanto benvenuto fra noi ! Il plugin drappa automaticamente qualunque immagine insista sul Dem, purchè appartenga al medesimo CRS proiettato: http://novarese.t15.org/freegis/qgis2threejs/ In questo esempio, ho semplicemente clippato un Geotiff rispetto ad un confine Istat, e ci ha pensato il software a 'spalmarlo' sul modello 3D. - -- View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/QGis2threejs-plugin-tp7585634p7585772.html Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] art. 68 - linee guida valutazione comparativa
Grazie Piergio, me l'ero persa... Mi pare il documento sia, almeno teoricamente, molto importante per la nostra associazione, quindi credo ci sarà l'esigenza di valutarlo per bene allo scopo di adottarlo, supportarlo, chiederne modifiche e/o correzioni a seconda di quello che verrà fuori da un'analisi condivisa, e ovviamente alla luce degli scopi e obiettivi dell'Associazione. L'ho scorso in 5 minuti e mi sembra che, ovviamente con possibilità elevata di sbagliarmi, ci siano dei buoni spunti e criteri, ma come spesso succede troppe scappatoie e modi per guidare la procedure verso dove si vuole e alla fine cmq fare quello che risulta più comodo invece che migliore. In generale un problema che vedo, non necessariamente legato al documento, è che i criteri di selezione delle soluzioni e poi i vari pesi da assegnare credo che possano essere molto condizionati dalla non conoscenza dell'esistenza di soluzioni alternative e ancora di più dalla non conoscenza delle potenzialità di soluzioni che non sono in uso. Cosa ne pensate? Ci aggiorniamo prossimamente dopo letture più approfondite? Ale On 01/09/2014 10:05 AM, piergio wrote: Non mi pare sia già passata qui la notizia: http://www.digitpa.gov.it/notizie/riuso-valutazione-comparativa-online-circolare Buona lettura Piergiovanna ___ 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. 666 iscritti al 22.7.2013 -- Alessandro Sarretta e-mail: alessandro.sarre...@gmail.com skype: alesarrett Web: http://ilsarrett.wordpress.com Twitter: https://twitter.com/alesarrett Google scholar: http://scholar.google.it/citations?hl=ituser=IsyXargJ ORCID: http://orcid.org/-0002-1475-8686 ResearchGate: https://www.researchgate.net/profile/Alessandro_Sarretta/ ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] QGis2threejs plugin !!!!
Attualmente il drappeggio è finto, nel senso che si tratta solo di un'immagine (una texture) che viene applicata al DTM. Lo sviluppatore ha in programma di sviluppare anche la visualizzazione 3D dei vettoriali. A quel punto sarà possibile fare un drappeggio reale, come fa ad esempio GRASS con Nviz. giovanni Il 09/gen/2014 10:19 antoniovinci sier...@outlook.com ha scritto: / kikapu wrote Ho una domanda, forse banale: quale strumento/comando QGis deve essere usato per il drap di immagini (ortofoto, pendenze, ecc) sul DEM? / Intanto benvenuto fra noi ! Il plugin drappa automaticamente qualunque immagine insista sul Dem, purchè appartenga al medesimo CRS proiettato: http://novarese.t15.org/freegis/qgis2threejs/ In questo esempio, ho semplicemente clippato un Geotiff rispetto ad un confine Istat, e ci ha pensato il software a 'spalmarlo' sul modello 3D. - -- View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/QGis2threejs-plugin-tp7585634p7585772.html Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. ___ 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. 666 iscritti al 22.7.2013 ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] disponibilità di TIN
Giusto per informazione, se qualcuno non lo sapesse, GRASS ha già un importatore PLY: http://grass.osgeo.org/grass70/manuals/addons/v.in.ply.html giovanni Il giorno 05 gennaio 2014 17:36, Paolo Cavallini cavall...@faunalia.it ha scritto: Il 05/01/2014 17:34, Geodrinx ha scritto: Se lo faccio io, qualcuno mi pagherà ? ;) se a qualcuno serve, direi di si' saluti -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.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. 666 iscritti al 22.7.2013 -- Giovanni Allegri http://about.me/giovanniallegri blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] disponibilità di TIN
Scusate, mi ero perso una risposta di Paolo, che riportava la stessa cosa... Il giorno 09 gennaio 2014 11:27, G. Allegri gioha...@gmail.com ha scritto: Giusto per informazione, se qualcuno non lo sapesse, GRASS ha già un importatore PLY: http://grass.osgeo.org/grass70/manuals/addons/v.in.ply.html giovanni Il giorno 05 gennaio 2014 17:36, Paolo Cavallini cavall...@faunalia.itha scritto: Il 05/01/2014 17:34, Geodrinx ha scritto: Se lo faccio io, qualcuno mi pagherà ? ;) se a qualcuno serve, direi di si' saluti -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.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. 666 iscritti al 22.7.2013 -- Giovanni Allegri http://about.me/giovanniallegri blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus -- Giovanni Allegri http://about.me/giovanniallegri blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] disponibilità di TIN
GRASS ha già un importatore PLY: http://grass.osgeo.org/grass70/manuals/addons/v.in.ply.html Sì, ma è in Grass 7. A quando in QGis ? Roberto ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] QGis2threejs plugin !!!!
Inviato da iPhone Il giorno 09/gen/2014, alle ore 10:45, G. Allegri gioha...@gmail.com ha scritto: Attualmente il drappeggio è finto, nel senso che si tratta solo di un'immagine (una texture) che viene applicata al DTM. Lo sviluppatore ha in programma di sviluppare anche la visualizzazione 3D dei vettoriali. A quel punto sarà possibile fare un drappeggio reale, come fa ad esempio GRASS con Nviz. ... e non sarebbe male una colorazione automatica per altezze... ... anche se forse conviene farla prima, in QGis con il city_col plugin ( o un nome simile... ) Roberto___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] disponibilità di TIN
Non è poi così complesso, visto che esistono diverse librerie ed esempi. Io non ci posso dedicare tempo ora, ma se qualcuno volesse, riporto un paio di risorse utili: RPly, parser C sia per PLY ASCII che binari: http://w3.impa.br/~diego/software/rply/ E un esempio di parsing in Python, ASCII e binario (usato da Blender): https://developer.blender.org/diffusion/BA/browse/master/io_mesh_ply/;71eb0065f3d5d8d0b1fbdc46a21309f6c60c6175 v.in.ply di GRASS non gestisce PLY binari, a quanto vedo dal codice (chiederò a Markus Metz di indicarlo nella documentazione). giovanni 2014/1/9 Geodrinx geodr...@gmail.com GRASS ha già un importatore PLY: http://grass.osgeo.org/grass70/manuals/addons/v.in.ply.html Sì, ma è in Grass 7. A quando in QGis ? Roberto -- Giovanni Allegri http://about.me/giovanniallegri blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] QGis2threejs plugin !!!!
... e non sarebbe male una colorazione automatica per altezze... ... anche se forse conviene farla prima, in QGis con il city_col plugin ( o un nome simile... ) intendi dire una colorazione dei vertici in base alla Z? Roberto -- Giovanni Allegri http://about.me/giovanniallegri blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] QGis2threejs plugin !!!!
/ giohappy wrote intendi dire una colorazione dei vertici in base alla Z? / Ne avevamo già parlato nel post del 2 gennaio alle 9:30, riallego il link: http://novarese.t15.org/gfoss/gradiente http://novarese.t15.org/gfoss/gradiente ottenuto con una classificazione tradizionale per quota. - -- View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/QGis2threejs-plugin-tp7585634p7585782.html Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] disponibilità di TIN
Il giorno Thu, 9 Jan 2014 11:27:54 +0100 G. Allegri gioha...@gmail.com ha scritto: ciao Giovanni; Giusto per informazione, se qualcuno non lo sapesse, GRASS ha già un importatore PLY: http://grass.osgeo.org/grass70/manuals/addons/v.in.ply.html il problema, almeno per me che avevo iniziato il thread :-), non era tanto la lettura di PLY quanto studiare (forse meglio giocare :-) con visualizzazione ed elaborazioni 3D di file vettoriali (per elaborazioni intendo ad es. sezioni orizzontali/verticali, ma potrebbero essere quotature, calcolo di superfici, volumi, ecc.); il formato PLY era stato incidentalmente il primo ad essere investito dell'interesse; guarderò anche i link che hai messo nel post successivo: mi serviranno a limitare l'ammontare di acqua calda della mia sperimentazione :-) giovanni grazie, ciao, giuliano ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] QGis2threejs plugin !!!!
Ne avevamo già parlato nel post del 2 gennaio alle 9:30, riallego il link: http://novarese.t15.org/gfoss/gradiente http://novarese.t15.org/gfoss/gradiente ottenuto con una classificazione tradizionale per quota. Non penso che Roberto intendesse questo. L'uso della texture può andar bene come primo approccio, ma è evidente che non gode dei benefici di un dato 3D reale. La colorazione dei vertici significa invece dare un colore che poi può essere gestito dagli shader. giovanni - -- View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/QGis2threejs-plugin-tp7585634p7585782.html Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. ___ 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. 666 iscritti al 22.7.2013 -- Giovanni Allegri http://about.me/giovanniallegri blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] disponibilità di TIN
Ciao Giuliano, certo, la questione non è tanto il formato dei dati, ma cosa potercene fare :) Non so se hai esperienza con Paraview. Ti assicuro che riprodurlo è un impresa titanica! Il punto fondamentale, al solito, è distinguere i due aspetti: - l'elaborazione dei dati - la visualizzazione Se uno ha bisogno di lavorare sul primo punto, direi che con QGIS si va poco lontano ad oggi, visto che non esiste una riga di codice che gestisca una struttura dati 3D. Se quindi lo sforzo fosse solo di usare QGIS come contesto applicativo in cui far girare codice non QGIS (es. via plugin), la questione si riduce alla gestione dello scambio di dati (e quindi dei formati). Per quanto riguarda la visualizzazione, bhè lì si tratta di smanettare con OpenGL/WebGL, ma anche qui QGIS in sé c'entra ben poco... giovanni Il giorno 09 gennaio 2014 13:56, giulianc51 giulian...@gmail.com ha scritto: Il giorno Thu, 9 Jan 2014 11:27:54 +0100 G. Allegri gioha...@gmail.com ha scritto: ciao Giovanni; Giusto per informazione, se qualcuno non lo sapesse, GRASS ha già un importatore PLY: http://grass.osgeo.org/grass70/manuals/addons/v.in.ply.html il problema, almeno per me che avevo iniziato il thread :-), non era tanto la lettura di PLY quanto studiare (forse meglio giocare :-) con visualizzazione ed elaborazioni 3D di file vettoriali (per elaborazioni intendo ad es. sezioni orizzontali/verticali, ma potrebbero essere quotature, calcolo di superfici, volumi, ecc.); il formato PLY era stato incidentalmente il primo ad essere investito dell'interesse; guarderò anche i link che hai messo nel post successivo: mi serviranno a limitare l'ammontare di acqua calda della mia sperimentazione :-) giovanni grazie, ciao, giuliano ___ 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. 666 iscritti al 22.7.2013 -- Giovanni Allegri http://about.me/giovanniallegri blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] disponibilità di TIN
Dimenticavo. SFCGAL ( http://www.sfcgal.org/) va in questa direzione. Chi avesse capacità o risorse da impiegare secondo me dovrebbe valutare di dirottarle là... Giovanni Il 09/gen/2014 14:04 G. Allegri gioha...@gmail.com ha scritto: Ciao Giuliano, certo, la questione non è tanto il formato dei dati, ma cosa potercene fare :) Non so se hai esperienza con Paraview. Ti assicuro che riprodurlo è un impresa titanica! Il punto fondamentale, al solito, è distinguere i due aspetti: - l'elaborazione dei dati - la visualizzazione Se uno ha bisogno di lavorare sul primo punto, direi che con QGIS si va poco lontano ad oggi, visto che non esiste una riga di codice che gestisca una struttura dati 3D. Se quindi lo sforzo fosse solo di usare QGIS come contesto applicativo in cui far girare codice non QGIS (es. via plugin), la questione si riduce alla gestione dello scambio di dati (e quindi dei formati). Per quanto riguarda la visualizzazione, bhè lì si tratta di smanettare con OpenGL/WebGL, ma anche qui QGIS in sé c'entra ben poco... giovanni Il giorno 09 gennaio 2014 13:56, giulianc51 giulian...@gmail.com ha scritto: Il giorno Thu, 9 Jan 2014 11:27:54 +0100 G. Allegri gioha...@gmail.com ha scritto: ciao Giovanni; Giusto per informazione, se qualcuno non lo sapesse, GRASS ha già un importatore PLY: http://grass.osgeo.org/grass70/manuals/addons/v.in.ply.html il problema, almeno per me che avevo iniziato il thread :-), non era tanto la lettura di PLY quanto studiare (forse meglio giocare :-) con visualizzazione ed elaborazioni 3D di file vettoriali (per elaborazioni intendo ad es. sezioni orizzontali/verticali, ma potrebbero essere quotature, calcolo di superfici, volumi, ecc.); il formato PLY era stato incidentalmente il primo ad essere investito dell'interesse; guarderò anche i link che hai messo nel post successivo: mi serviranno a limitare l'ammontare di acqua calda della mia sperimentazione :-) giovanni grazie, ciao, giuliano ___ 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. 666 iscritti al 22.7.2013 -- Giovanni Allegri http://about.me/giovanniallegri blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] disponibilità di TIN
Su qyesta libreria fornisco la mia esperienza: In occasione della ultima migrazione che ho fatto , ho provato a compilare assieme al postgis anche la SFCGAL, ma dopo mezza giornata di tentativi ci dovetti rinunciare.Se ricordo bene vi furono un paio di dipendenze che non risuscii a soddisfare. Inoltre, leggendo i commenti su di essa, non sembra un fulmine di guerra come velocita'. La spiegazione è legata anche al fatto che per fornire determinate precisioni, necessarie nell'analisi 3D hanno ri-implementato alcuni algoritmi matematici che cosi' sono piu' precisi, ma anche piu' lenti. Inoltre la precisione dell'algoritmo non ncessariamente è un pregio. Sarebbe un pregio se fosse in una libreria portabile come la Geos, ma se è in una libreria che è usabile solo da Postgis diventa un elemento negativo, perche' fai i conti su postgis e tornano in un certo modo. Li fai in altro ambiente e tornano in maniera differente. Quello che non so' è se compilando postgis con la SFCGAL si altera i risultati anche sul bidimensionale (perche' sfrutta a tutto tondo i nuovi algoritmi) o se i nuovi algoritmi sono solo per la parte 3D. Comunque questi sono argomenti soggettivi, mi rendo ben conto che altri possono pensarla in altro modo. A. Il giorno 09 gennaio 2014 14:09, G. Allegri gioha...@gmail.com ha scritto: Dimenticavo. SFCGAL ( http://www.sfcgal.org/) va in questa direzione. Chi avesse capacità o risorse da impiegare secondo me dovrebbe valutare di dirottarle là... Giovanni Il 09/gen/2014 14:04 G. Allegri gioha...@gmail.com ha scritto: Ciao Giuliano, certo, la questione non è tanto il formato dei dati, ma cosa potercene fare :) Non so se hai esperienza con Paraview. Ti assicuro che riprodurlo è un impresa titanica! Il punto fondamentale, al solito, è distinguere i due aspetti: - l'elaborazione dei dati - la visualizzazione Se uno ha bisogno di lavorare sul primo punto, direi che con QGIS si va poco lontano ad oggi, visto che non esiste una riga di codice che gestisca una struttura dati 3D. Se quindi lo sforzo fosse solo di usare QGIS come contesto applicativo in cui far girare codice non QGIS (es. via plugin), la questione si riduce alla gestione dello scambio di dati (e quindi dei formati). Per quanto riguarda la visualizzazione, bhè lì si tratta di smanettare con OpenGL/WebGL, ma anche qui QGIS in sé c'entra ben poco... giovanni Il giorno 09 gennaio 2014 13:56, giulianc51 giulian...@gmail.com ha scritto: Il giorno Thu, 9 Jan 2014 11:27:54 +0100 G. Allegri gioha...@gmail.com ha scritto: ciao Giovanni; Giusto per informazione, se qualcuno non lo sapesse, GRASS ha già un importatore PLY: http://grass.osgeo.org/grass70/manuals/addons/v.in.ply.html il problema, almeno per me che avevo iniziato il thread :-), non era tanto la lettura di PLY quanto studiare (forse meglio giocare :-) con visualizzazione ed elaborazioni 3D di file vettoriali (per elaborazioni intendo ad es. sezioni orizzontali/verticali, ma potrebbero essere quotature, calcolo di superfici, volumi, ecc.); il formato PLY era stato incidentalmente il primo ad essere investito dell'interesse; guarderò anche i link che hai messo nel post successivo: mi serviranno a limitare l'ammontare di acqua calda della mia sperimentazione :-) giovanni grazie, ciao, giuliano ___ 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. 666 iscritti al 22.7.2013 -- Giovanni Allegri http://about.me/giovanniallegri blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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. 666 iscritti al 22.7.2013 -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] disponibilità di TIN
Ciao Andrea, le SFCGAL, come sai, fanno da ponte con le CGAL. Nel fare i binding è stato scelto di usare certi predicati di precisione (tra i vari esposti dalle CGAL) che possono essere pesantini, MA, a fronte di algoritmi GEOS talvolta più performanti, SFCGAL si porta dietro tutta la potenza delle CGAL (3D ma non solo) altrimenti non disponibile. E' comunque sempre possibile scegliere, in PostGIS, quale implementazione usare nel caso di metodi offerti sia da PostGIS che dai binding SFCGAL. Infine perché dovrei ottenere risultati diversi tra diverse piattaforme? Credo che i predicati di CGAL siano riproducibili su tutte, allo stesso modo... giovanni Il 09/gen/2014 14:23 Andrea Peri aperi2...@gmail.com ha scritto: Su qyesta libreria fornisco la mia esperienza: In occasione della ultima migrazione che ho fatto , ho provato a compilare assieme al postgis anche la SFCGAL, ma dopo mezza giornata di tentativi ci dovetti rinunciare.Se ricordo bene vi furono un paio di dipendenze che non risuscii a soddisfare. Inoltre, leggendo i commenti su di essa, non sembra un fulmine di guerra come velocita'. La spiegazione è legata anche al fatto che per fornire determinate precisioni, necessarie nell'analisi 3D hanno ri-implementato alcuni algoritmi matematici che cosi' sono piu' precisi, ma anche piu' lenti. Inoltre la precisione dell'algoritmo non ncessariamente è un pregio. Sarebbe un pregio se fosse in una libreria portabile come la Geos, ma se è in una libreria che è usabile solo da Postgis diventa un elemento negativo, perche' fai i conti su postgis e tornano in un certo modo. Li fai in altro ambiente e tornano in maniera differente. Quello che non so' è se compilando postgis con la SFCGAL si altera i risultati anche sul bidimensionale (perche' sfrutta a tutto tondo i nuovi algoritmi) o se i nuovi algoritmi sono solo per la parte 3D. Comunque questi sono argomenti soggettivi, mi rendo ben conto che altri possono pensarla in altro modo. A. Il giorno 09 gennaio 2014 14:09, G. Allegri gioha...@gmail.com ha scritto: Dimenticavo. SFCGAL ( http://www.sfcgal.org/) va in questa direzione. Chi avesse capacità o risorse da impiegare secondo me dovrebbe valutare di dirottarle là... Giovanni Il 09/gen/2014 14:04 G. Allegri gioha...@gmail.com ha scritto: Ciao Giuliano, certo, la questione non è tanto il formato dei dati, ma cosa potercene fare :) Non so se hai esperienza con Paraview. Ti assicuro che riprodurlo è un impresa titanica! Il punto fondamentale, al solito, è distinguere i due aspetti: - l'elaborazione dei dati - la visualizzazione Se uno ha bisogno di lavorare sul primo punto, direi che con QGIS si va poco lontano ad oggi, visto che non esiste una riga di codice che gestisca una struttura dati 3D. Se quindi lo sforzo fosse solo di usare QGIS come contesto applicativo in cui far girare codice non QGIS (es. via plugin), la questione si riduce alla gestione dello scambio di dati (e quindi dei formati). Per quanto riguarda la visualizzazione, bhè lì si tratta di smanettare con OpenGL/WebGL, ma anche qui QGIS in sé c'entra ben poco... giovanni Il giorno 09 gennaio 2014 13:56, giulianc51 giulian...@gmail.com ha scritto: Il giorno Thu, 9 Jan 2014 11:27:54 +0100 G. Allegri gioha...@gmail.com ha scritto: ciao Giovanni; Giusto per informazione, se qualcuno non lo sapesse, GRASS ha già un importatore PLY: http://grass.osgeo.org/grass70/manuals/addons/v.in.ply.html il problema, almeno per me che avevo iniziato il thread :-), non era tanto la lettura di PLY quanto studiare (forse meglio giocare :-) con visualizzazione ed elaborazioni 3D di file vettoriali (per elaborazioni intendo ad es. sezioni orizzontali/verticali, ma potrebbero essere quotature, calcolo di superfici, volumi, ecc.); il formato PLY era stato incidentalmente il primo ad essere investito dell'interesse; guarderò anche i link che hai messo nel post successivo: mi serviranno a limitare l'ammontare di acqua calda della mia sperimentazione :-) giovanni grazie, ciao, giuliano ___ 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. 666 iscritti al 22.7.2013 -- Giovanni Allegri http://about.me/giovanniallegri blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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. 666 iscritti al 22.7.2013 -- - Andrea Peri . . . . . . . . . qwerty àèìòù -
Re: [Gfoss] disponibilità di TIN
/ giohappy wrote con QGIS si va poco lontano ad oggi, visto che non esiste una riga di codice che gestisca una struttura dati 3D / Dal basso della mia ignoranza voglio crederti, ma non mi spiego come mai Qgis gestisca correttamente le shape 3D. Ad esempio, se carichi queste curve di livello vettoriali in Raster = Interpolazione: http://novarese.t15.org/freegis/isoipse3d.zip http://novarese.t15.org/freegis/isoipse3d.zip il programma legge la coordinata Z integrata geometricamente nelle isoipse, e crea il Dem senza problemi... - -- View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/disponibilita-di-TIN-tp7585663p7585789.html Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] disponibilità di TIN
Intendevo dire differenze tra con e senza le cgal. La scelta tra cgal e normale avviene in fase di compilazione giusto ? Quindi il rischio è di avere in casa un postgis che su determinate intersezioni o elaborazione produce determinati risultati, mentre su altri postgis , perche' realizzati senza le cgal si hanno risultati differenti. E' un valore importante la riproducibilita' del risultato. Va a finire che quando si compila la scheda di metadato relatiamente a un dataset prodotto, occorre metterci tra le informazioni su come si è operato anche la situazione dell'eventuale postgis coinvolto nel lavoro. Pena il rischio che altri soggetti, con altri postgis, non riescano a riprourre il medesimo risultato. Puo' sembrare un dettaglio esagerato, ma secondo me non lo è. A. Il giorno 09 gennaio 2014 14:34, G. Allegri gioha...@gmail.com ha scritto: Ciao Andrea, le SFCGAL, come sai, fanno da ponte con le CGAL. Nel fare i binding è stato scelto di usare certi predicati di precisione (tra i vari esposti dalle CGAL) che possono essere pesantini, MA, a fronte di algoritmi GEOS talvolta più performanti, SFCGAL si porta dietro tutta la potenza delle CGAL (3D ma non solo) altrimenti non disponibile. E' comunque sempre possibile scegliere, in PostGIS, quale implementazione usare nel caso di metodi offerti sia da PostGIS che dai binding SFCGAL. Infine perché dovrei ottenere risultati diversi tra diverse piattaforme? Credo che i predicati di CGAL siano riproducibili su tutte, allo stesso modo... giovanni Il 09/gen/2014 14:23 Andrea Peri aperi2...@gmail.com ha scritto: Su qyesta libreria fornisco la mia esperienza: In occasione della ultima migrazione che ho fatto , ho provato a compilare assieme al postgis anche la SFCGAL, ma dopo mezza giornata di tentativi ci dovetti rinunciare.Se ricordo bene vi furono un paio di dipendenze che non risuscii a soddisfare. Inoltre, leggendo i commenti su di essa, non sembra un fulmine di guerra come velocita'. La spiegazione è legata anche al fatto che per fornire determinate precisioni, necessarie nell'analisi 3D hanno ri-implementato alcuni algoritmi matematici che cosi' sono piu' precisi, ma anche piu' lenti. Inoltre la precisione dell'algoritmo non ncessariamente è un pregio. Sarebbe un pregio se fosse in una libreria portabile come la Geos, ma se è in una libreria che è usabile solo da Postgis diventa un elemento negativo, perche' fai i conti su postgis e tornano in un certo modo. Li fai in altro ambiente e tornano in maniera differente. Quello che non so' è se compilando postgis con la SFCGAL si altera i risultati anche sul bidimensionale (perche' sfrutta a tutto tondo i nuovi algoritmi) o se i nuovi algoritmi sono solo per la parte 3D. Comunque questi sono argomenti soggettivi, mi rendo ben conto che altri possono pensarla in altro modo. A. Il giorno 09 gennaio 2014 14:09, G. Allegri gioha...@gmail.com ha scritto: Dimenticavo. SFCGAL ( http://www.sfcgal.org/) va in questa direzione. Chi avesse capacità o risorse da impiegare secondo me dovrebbe valutare di dirottarle là... Giovanni Il 09/gen/2014 14:04 G. Allegri gioha...@gmail.com ha scritto: Ciao Giuliano, certo, la questione non è tanto il formato dei dati, ma cosa potercene fare :) Non so se hai esperienza con Paraview. Ti assicuro che riprodurlo è un impresa titanica! Il punto fondamentale, al solito, è distinguere i due aspetti: - l'elaborazione dei dati - la visualizzazione Se uno ha bisogno di lavorare sul primo punto, direi che con QGIS si va poco lontano ad oggi, visto che non esiste una riga di codice che gestisca una struttura dati 3D. Se quindi lo sforzo fosse solo di usare QGIS come contesto applicativo in cui far girare codice non QGIS (es. via plugin), la questione si riduce alla gestione dello scambio di dati (e quindi dei formati). Per quanto riguarda la visualizzazione, bhè lì si tratta di smanettare con OpenGL/WebGL, ma anche qui QGIS in sé c'entra ben poco... giovanni Il giorno 09 gennaio 2014 13:56, giulianc51 giulian...@gmail.com ha scritto: Il giorno Thu, 9 Jan 2014 11:27:54 +0100 G. Allegri gioha...@gmail.com ha scritto: ciao Giovanni; Giusto per informazione, se qualcuno non lo sapesse, GRASS ha già un importatore PLY: http://grass.osgeo.org/grass70/manuals/addons/v.in.ply.html il problema, almeno per me che avevo iniziato il thread :-), non era tanto la lettura di PLY quanto studiare (forse meglio giocare :-) con visualizzazione ed elaborazioni 3D di file vettoriali (per elaborazioni intendo ad es. sezioni orizzontali/verticali, ma potrebbero essere quotature, calcolo di superfici, volumi, ecc.); il formato PLY era stato incidentalmente il primo ad essere investito dell'interesse; guarderò anche i link che hai messo nel post successivo: mi serviranno a limitare l'ammontare di acqua calda della mia sperimentazione :-) giovanni grazie, ciao, giuliano
Re: [Gfoss] QGis2threejs plugin !!!!
Ne avevamo già parlato nel post del 2 gennaio alle 9:30, riallego il link: http://novarese.t15.org/gfoss/gradiente http://novarese.t15.org/gfoss/gradiente ottenuto con una classificazione tradizionale per quota. In questo caso la colorazione è data da un'immagine creata in QGis, giusto ? La colorazione dei vertici significa invece dare un colore che poi può essere gestito dagli shader. La cosa può andare ad integrarsi con il problema della gestione di un file PLY, ovvero di un TIN. In effetti, converrebbe unificare la discussione sotto un argomento : Gestione 3D. Non sarebbe male parlarne a voce, tramite Skype o GMail... Comunque, per adesso diciamo questo: 1) Per il momento, il plugin qgis2threejs gestisce DEM in formato grid ( e quindi, di tipo raster ) 2) Il plugin, nel suo contesto web, si comporta egregiamente e apre una porta alla pubblicazione web di 3D a partire da dati QGis 3) Il plugin ha talmente tante potenzialità, che... dovrà fare di più (perchè nel 3D l'appetito vien ... volando) 4) Attualmente, per vedere la superficie, occorre utilizzare una colorazione preventiva. Se non si colora la superficie, il 3D compare nero (o grigio a fasce) cioè praticamente invisibile. 5) Nel caso si volesse solo controllare al volo com'è una superficie (senza colorarla con QGis), il plugin potrebbe colorare i punti per altezza, nel grid, e quindi non usare il tag dell'immagine (oppure potrebbe generare un'immagine colorata per altezza, al volo). E quindi, non ci sarebbe la necessità di farlo in QGis. E' una duplicazione di codice ? Probabile, ma questo darebbe una immediatezza maggiore al plugin. Comunque, mentre noi stiamo discutendo, è probabile che il programmatore stia già implementando questo... ;) Se volete, ci fermiamo qui, e meditiamo su quanto detto. E poi, inizieremo a parlare di TIN, all'interno del plugin... Ma prima dovremo discutere su ... che cosa è un TIN, e che cosa implica visualizzarlo in un Gis 2D :) A presto Roberto ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] disponibilità di TIN
Qui forse riesco a risponderti io. Il comando che te scateni gira il lavoro sporco a gdal. Il quale sa fare il suo mestiere e produce il risultato che poi qgis presentera'. Io credo che GH si riferissse a codice nativo qgis. E quindi o si dispone di un tools esterno he fa cio' che si chiede oppure nisba. QGIS non è in grado di sopperire. Nel senso che se si va in programmazione e sulle API , non si trova niente che consenta di gestire una struttura 3D. x GH : era questo il senso del tuo discorso? A. Il giorno 09 gennaio 2014 14:38, antoniovinci sier...@outlook.com ha scritto: / giohappy wrote con QGIS si va poco lontano ad oggi, visto che non esiste una riga di codice che gestisca una struttura dati 3D / Dal basso della mia ignoranza voglio crederti, ma non mi spiego come mai Qgis gestisca correttamente le shape 3D. Ad esempio, se carichi queste curve di livello vettoriali in Raster = Interpolazione: http://novarese.t15.org/freegis/isoipse3d.zip http://novarese.t15.org/freegis/isoipse3d.zip il programma legge la coordinata Z integrata geometricamente nelle isoipse, e crea il Dem senza problemi... - -- View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/disponibilita-di-TIN-tp7585663p7585789.html Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. ___ 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. 666 iscritti al 22.7.2013 -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] disponibilità di TIN
Il giorno 09 gennaio 2014 14:40, Andrea Peri aperi2...@gmail.com ha scritto: Intendevo dire differenze tra con e senza le cgal. La scelta tra cgal e normale avviene in fase di compilazione giusto ? Quindi il rischio è di avere in casa un postgis che su determinate intersezioni o elaborazione produce determinati risultati, mentre su altri postgis , perche' realizzati senza le cgal si hanno risultati differenti. E' un valore importante la riproducibilita' del risultato. Va a finire che quando si compila la scheda di metadato relatiamente a un dataset prodotto, occorre metterci tra le informazioni su come si è operato anche la situazione dell'eventuale postgis coinvolto nel lavoro. Pena il rischio che altri soggetti, con altri postgis, non riescano a riprourre il medesimo risultato. Puo' sembrare un dettaglio esagerato, ma secondo me non lo è. Concordo con te. Sì, come si vede dalla matrice delle funzioni [1] alcune sono esposto solo da SFCGAL, altre sono gestite da SFCGAL se presente, altrimenti dalle GEOS [2]. Non ho mai testato le differenze di risultato... [1] http://postgis.net/docs/manual-2.1/PostGIS_Special_Functions_Index.html#PostGIS_TypeFunctionMatrix [2] https://github.com/postgis/postgis/blob/svn-trunk/postgis/Makefile.in#L32 A. Il giorno 09 gennaio 2014 14:34, G. Allegri gioha...@gmail.com ha scritto: Ciao Andrea, le SFCGAL, come sai, fanno da ponte con le CGAL. Nel fare i binding è stato scelto di usare certi predicati di precisione (tra i vari esposti dalle CGAL) che possono essere pesantini, MA, a fronte di algoritmi GEOS talvolta più performanti, SFCGAL si porta dietro tutta la potenza delle CGAL (3D ma non solo) altrimenti non disponibile. E' comunque sempre possibile scegliere, in PostGIS, quale implementazione usare nel caso di metodi offerti sia da PostGIS che dai binding SFCGAL. Infine perché dovrei ottenere risultati diversi tra diverse piattaforme? Credo che i predicati di CGAL siano riproducibili su tutte, allo stesso modo... giovanni Il 09/gen/2014 14:23 Andrea Peri aperi2...@gmail.com ha scritto: Su qyesta libreria fornisco la mia esperienza: In occasione della ultima migrazione che ho fatto , ho provato a compilare assieme al postgis anche la SFCGAL, ma dopo mezza giornata di tentativi ci dovetti rinunciare.Se ricordo bene vi furono un paio di dipendenze che non risuscii a soddisfare. Inoltre, leggendo i commenti su di essa, non sembra un fulmine di guerra come velocita'. La spiegazione è legata anche al fatto che per fornire determinate precisioni, necessarie nell'analisi 3D hanno ri-implementato alcuni algoritmi matematici che cosi' sono piu' precisi, ma anche piu' lenti. Inoltre la precisione dell'algoritmo non ncessariamente è un pregio. Sarebbe un pregio se fosse in una libreria portabile come la Geos, ma se è in una libreria che è usabile solo da Postgis diventa un elemento negativo, perche' fai i conti su postgis e tornano in un certo modo. Li fai in altro ambiente e tornano in maniera differente. Quello che non so' è se compilando postgis con la SFCGAL si altera i risultati anche sul bidimensionale (perche' sfrutta a tutto tondo i nuovi algoritmi) o se i nuovi algoritmi sono solo per la parte 3D. Comunque questi sono argomenti soggettivi, mi rendo ben conto che altri possono pensarla in altro modo. A. Il giorno 09 gennaio 2014 14:09, G. Allegri gioha...@gmail.com ha scritto: Dimenticavo. SFCGAL ( http://www.sfcgal.org/) va in questa direzione. Chi avesse capacità o risorse da impiegare secondo me dovrebbe valutare di dirottarle là... Giovanni Il 09/gen/2014 14:04 G. Allegri gioha...@gmail.com ha scritto: Ciao Giuliano, certo, la questione non è tanto il formato dei dati, ma cosa potercene fare :) Non so se hai esperienza con Paraview. Ti assicuro che riprodurlo è un impresa titanica! Il punto fondamentale, al solito, è distinguere i due aspetti: - l'elaborazione dei dati - la visualizzazione Se uno ha bisogno di lavorare sul primo punto, direi che con QGIS si va poco lontano ad oggi, visto che non esiste una riga di codice che gestisca una struttura dati 3D. Se quindi lo sforzo fosse solo di usare QGIS come contesto applicativo in cui far girare codice non QGIS (es. via plugin), la questione si riduce alla gestione dello scambio di dati (e quindi dei formati). Per quanto riguarda la visualizzazione, bhè lì si tratta di smanettare con OpenGL/WebGL, ma anche qui QGIS in sé c'entra ben poco... giovanni Il giorno 09 gennaio 2014 13:56, giulianc51 giulian...@gmail.com ha scritto: Il giorno Thu, 9 Jan 2014 11:27:54 +0100 G. Allegri gioha...@gmail.com ha scritto: ciao Giovanni; Giusto per informazione, se qualcuno non lo sapesse, GRASS ha già un importatore PLY: http://grass.osgeo.org/grass70/manuals/addons/v.in.ply.html il problema, almeno per me che avevo iniziato il thread :-), non era tanto la lettura di PLY quanto studiare (forse meglio
Re: [Gfoss] disponibilità di TIN
x GH : era questo il senso del tuo discorso? Esattamente. A. Il giorno 09 gennaio 2014 14:38, antoniovinci sier...@outlook.com ha scritto: / giohappy wrote con QGIS si va poco lontano ad oggi, visto che non esiste una riga di codice che gestisca una struttura dati 3D / Dal basso della mia ignoranza voglio crederti, ma non mi spiego come mai Qgis gestisca correttamente le shape 3D. Ad esempio, se carichi queste curve di livello vettoriali in Raster = Interpolazione: http://novarese.t15.org/freegis/isoipse3d.zip http://novarese.t15.org/freegis/isoipse3d.zip il programma legge la coordinata Z integrata geometricamente nelle isoipse, e crea il Dem senza problemi... - -- View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/disponibilita-di-TIN-tp7585663p7585789.html Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. ___ 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. 666 iscritti al 22.7.2013 -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ 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. 666 iscritti al 22.7.2013 -- Giovanni Allegri http://about.me/giovanniallegri blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] bundle per Mapbender3
bravo Diego! sto provando a creare qualche bundle per mapbender3 anch'io, ma sto incontrando parecchi ostacoli, in parte perchè non conosco bene Simfony, con il quale non ho mai lavorato prima, ma soprattutto sulla parte javascript, che invece conosco bene, a causa della molto carente documentazione. il tuo esempio mi è stato di fondamentale aiuto. Posso chiederti come ti sei orientato? conosci della documentazione più dettagliata rispetto a quella del sito ufficiale sullo sviluppo di nuove funzionalità in mapbender3? sto cercando di fare un nuovo tool che reagisca al click sulla mappa, ma ho già dei problemi solo per aggiungere un tool e procedo per tentativi... ogni aiuto per me in questa fase è prezioso grazie -- View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/bundle-per-Mapbender3-tp7584727p7585795.html Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] OSRM - Servizio Web Ricerca percorsi
Risegnalo questo http://graphhopper.com/ che sembra più rapido in performance http://graphhopper.com/maps/?point=Gaetapoint=L'Aquilalocale=en-US ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] QGis2threejs plugin !!!!
/ Geodrinx wrote 1) Per il momento, il plugin qgis2threejs gestisce DEM in formato grid (e quindi, di tipo raster ) / Beh, volendo supporta anche i vettori (vedi post del 2 gennaio ore 9:00) che vengono drappati in automatico sul Dem. / Geodrinx wrote 4) Attualmente, per vedere la superficie, occorre utilizzare una colorazione preventiva. Se non si colora la superficie, il 3D compare nero (o grigio a fasce) cioè praticamente invisibile. / Senza colorare nulla (o per essere piu' precisi, senza classificare nulla) ti svelo il seguente trucco per 'vedere' il gradiente di un Dem. Entra nelle proprieta' del raster, vai su Miglioramento contrasto e settalo su Stira a Min/Max, infine Apply. Se adesso lanci il plugin nipponico, ti crea il 3D sfumato. - -- View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/QGis2threejs-plugin-tp7585634p7585797.html Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] QGis2threejs plugin !!!!
/ Beh, volendo supporta anche i vettori (vedi post del 2 gennaio ore 9:00) che vengono drappati in automatico sul Dem. Stiamo parlando di 3D e in questo momento i layer vettoriali non vengono tradotti in mesh 3D. Per cui sono supportati per modo di dire. Se è per questo è supportato anche il tuo nord, ma non è un oggetto 3D. Il raster viene invece utilizzato per generare una mesh. / Geodrinx wrote 4) Attualmente, per vedere la superficie, occorre utilizzare una colorazione preventiva. Se non si colora la superficie, il 3D compare nero (o grigio a fasce) cioè praticamente invisibile. / Senza colorare nulla (o per essere piu' precisi, senza classificare nulla) ti svelo il seguente trucco per 'vedere' il gradiente di un Dem. Entra nelle proprieta' del raster, vai su Miglioramento contrasto e settalo su Stira a Min/Max, infine Apply. Se adesso lanci il plugin nipponico, ti crea il 3D sfumato. Anche se lo coloro di marrone, lo vedrò marrone. E se lo coloro di verde lo vedrò verde :) Quello che stiamo dicendo è la colorazione della mesh tramite shading (fragment shader). giovanni - -- View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/QGis2threejs-plugin-tp7585634p7585797.html Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. ___ 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. 666 iscritti al 22.7.2013 -- Giovanni Allegri http://about.me/giovanniallegri blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] Pubblicazione nel cloud direttamente da Qgis
Ho fatto un po' di prove...correggettemi se sbaglio: fatto il tuo bel progettino con qgis, si uploadano i dati nel cloud (i dati da spatialite non sono accettati ed è necessario esportarli in shape prima) e questi vengono sostituiti anche sul progetto di Qgis locale...quindi alla riapertura diventa un po' pesantuccio perchè deve riscaricare tutti i layer. Ho provato a non spuntare la flag per sostituire in locale i layer, ma a questo punto mi impedisce di pubblicare. E' corretto? 2014/1/7 Paolo Cavallini cavall...@faunalia.it -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 06/01/2014 18:06, antoniovinci ha scritto: / Andrea Peri wrote I datasets vanno passati armi e bagagli sul suo cloud per potervi poi produrre mappe, oppure sfrutta il tuo qgis locale come macchina elaborativa che produce la mappa e la posta (quella, non i dati) sul cloud ? / Non ho le competenze per rispondere ad una domanda cosi' alta... La sensazione e' che tu uploadi il progetto .QGS (con stili e layout), poi lui lo trasforma in WMS con attributi Gis (visibili con l'icona I d'informazione), e lo pubblica nel cloud. Oltre non vo :( Allora: * qgis cloud fa da cloud, ovvero si copia i vostri dati * lizmap (ma manche qgis web browser) consente la pubblicazione dei propri progetti su un proprio server; il metodo di caricamento dei dati e' a scelta dell'utente (io ad es. non uso FTP, ma ssh). Saluti. - -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlLLtJgACgkQ/NedwLUzIr6m4QCglpXxpdRuKsXOpXoCfc8CrXec ZmMAnjSfai6lTpjmxp9vW33reXi7o5hf =iNxt -END PGP SIGNATURE- ___ 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. 666 iscritti al 22.7.2013 ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] QGis2threejs plugin !!!!
/ giohappy wrote in questo momento i layer vettoriali non vengono tradotti in mesh 3D / Proprio così, essi vengono semplicemente rasterizzati, fusi sul (o nel) Dem, ma comunque partecipano alla scena, non sono trascurati come figli di un dio minore, ergo sono indirettamente supportati da Qgis2threejs... - -- View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/QGis2threejs-plugin-tp7585634p7585800.html Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] disponibilità di TIN
/ Andrea Peri wrote Il comando che te scateni gira il lavoro sporco a gdal / Grazie, ora è tutto chiaro: ero convinto (sbagliando) che GDAL fosse parte integrante del kernel di Qgis... - -- View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/disponibilita-di-TIN-tp7585663p7585801.html Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. ___ 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. 666 iscritti al 22.7.2013
Re: [Gfoss] Pubblicazione nel cloud direttamente da Qgis
/ mando wrote E' corretto? / Correttissimo. Sempre nell'ambito della sperimentazione, ho aggiunto un layout da Composer all'intero territorio nazionale del primo post: http://qgiscloud.com/sieradz/stylized http://qgiscloud.com/sieradz/stylized Per generare il PDF, cliccare Print Map e scegliere la scala al 5000 (essendo la mappa in km.) - -- View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Pubblicazione-nel-cloud-direttamente-da-Qgis-tp7585622p7585802.html Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. ___ 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. 666 iscritti al 22.7.2013
