[Gfoss] disponibilità di TIN

Gio 9 Gen 2014 15:03:49 CET

Il giorno 09 gennaio 2014 14:40, Andrea Peri <aperi2007 a 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 <giohappy a 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" <aperi2007 a 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 <giohappy a 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" <giohappy a 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 <giulianc51 a gmail.com> ha
>>>>> scritto:
>>>>>
>>>>>> Il giorno Thu, 9 Jan 2014 11:27:54 +0100
>>>>>> "G. Allegri" <giohappy a 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 a lists.gfoss.it
>>>>>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>>>>>> Questa e' una lista di discussione pubblica aperta a tutti.
>>>>>> I messaggi di questa lista non hanno relazione diretta con le
>>>>>> posizioni dell'Associazione GFOSS.it.
>>>>>> 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 a lists.gfoss.it
>>>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>>>> Questa e' una lista di discussione pubblica aperta a tutti.
>>>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>>>> dell'Associazione GFOSS.it.
>>>> 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
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20140109/a0c130c9/attachment-0001.html>