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 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 àèìòù >>> ----------------- >>> >> > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty àèìòù > ----------------- > -- 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
