disponibilità di TIN

[giohappy]

Il giorno 09 gennaio 2014 14:40, Andrea Peri <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> ha scritto:

Il giorno Thu, 9 Jan 2014 11:27:54 +0100

"G. Allegri" <[hidden email]> 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

_______________________________________________
[hidden email]
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

_______________________________________________
[hidden email]
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

_______________________________________________
[hidden email]
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

[giohappy]

x GH : era questo il senso del tuo discorso?

Esattamente.

 

A.

Il giorno 09 gennaio 2014 14:38, antoniovinci <[hidden email]> 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.

_______________________________________________
[hidden email]
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 àèìòù
-----------------

_______________________________________________
[hidden email]
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

_______________________________________________
[hidden email]
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

[antoniovinci]

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...

[giohappy]

QGIS usa GDAL in parte tramite le sue API (essenzialmente per la lettura/scrittura dei raster, e come OGR per i vettoriali), mentre alcuni tool delegano il lavoro alle utility dellw GDAL, lanciando un processo esterno a QGIS, come nel caso dell'interpolazione raster che citavi (la quale utilizza gdal_grid).

giovanni

Il 10/gen/2014 08:43 "antoniovinci" <[hidden email]> ha scritto:

/
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.
_______________________________________________
[hidden email]
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

_______________________________________________
[hidden email]
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

[antoniovinci]

Ti ringrazio Giova',
credevo di essere "imparato", invece ne imparo più in 1 giorno qua dentro che nel resto del Web in 1 mese...