[Gfoss] disponibilità di TIN

Gio 9 Gen 2014 14:40:15 CET

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 <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 àèìòù
-----------------
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20140109/947621ee/attachment-0001.html>