disponibilità di TIN
Locked
123
123
 
|
Il 05/01/2014 13:22, antoniovinci ha scritto:
> Se invece vuoi diffondere l'opensource, soprattutto nella P.A., devi cercare > di offrire soluzioni integrate, altrimenti otterrai sconfortanti risposte > della serie "E' troppo complicato, non ho tempo d'imparare tutti 'sti > programmi", eccetera... verissimo. in effetti, la forza di qgis e' spesso questa: di fare da collante fra pezzi diversi, in modo che non ci sia ogni volta da reinventare la ruota, ne' dal punto di vista degli sviluppatori (che riusano il sw esistente, vedi ad es.GdalTools), sia da quello degli utenti, che proseguono il lavoro nello stesso ambiente e con la stessa interfaccia, senza doversi preoccupare di come le cose funzionano dietro le quinte. Nello specifico, il problema dovrebbe essere trattabile; ad es. GRASS l'ha risolto: http://grass.osgeo.org/grass70/manuals/addons/v.in.ply.html Strano che non ci sia in OGR, in effetti, io chiederei li' prima di procedere. Saluti. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [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 |
|
|
In reply to this post by antoniovinci
giulianc51 wrote Il drone non montava nessuno scanner laser, ma soltanto una videocamera GoPRO. L'elaborazione è stata effettuata tramite la SfM (Structure from Motion), ed è spiegata sommariamente qui:
mentre qui è descritta più in dettaglio la SfM:
L'elaborazione SfM da foto ( o video, come in questo caso ) produce un TIN di tipo sculturato in formato PLY, completo di texture UV o tipo "real" ortofoto di alta risoluzione.
Il poter caricare il TIN (PLY o altro) anche all'interno di programmi GIS come QGis (per l'appunto) darebbe la possibilità (per ora solo futuribile) di lavorare direttamente sui dati grezzi in uscita da un rilievo aereo a basso costo (o anche terrestre…).
Non a caso, è stato rilasciato un modulo per Grass GIS che permette di caricare, per l'appunto, file PLY all'interno di questo potente programma di analisi territoriale. Ciao Roberto / _______________________________________________ [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 |
|
|
In reply to this post by pcav
Gia' chiesto, sia a Ben Discoe (di VTerrain - http://vterrain-italia.blogspot.it/2013/02/vtp-italia-benvenuti.html ) che a Frank Warmerdam (di GDAL, OGR ecc), quando erano entrambi in Google. So che ne hanno parlato varie volte, e doveva essere integrato in OGR un driver per ITF (ovvero, il formato TIN di VTerrain) dato che già c'è il driver in GDAL per il formato BT (Binary Terrain grid format di VTerrain.org ).
Poi, purtroppo, la cosa si è arenata, non so esattamente per quale motivo. Comunque, attualmente penso sarebbe utile rilanciare la cosa, e spingere per l'implementazione di un driver per il PLY (binario e ascii) all'interno della GDAL/OGR, essendo, appunto, il formato di uscita della SfM (Structure from Motion).
Ripartirò alla carica. Però, secondo me, bisogna partire con una "manovra a tenaglia", con più richieste da più fronti (OOOOPS, non dovevo dirlo ? ) Ciao Roberto _______________________________________________ [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 |
|
In reply to this post by geodrinx
Davvero spettacolare, sento che questa tecnica stravolgera' la fotogrammetria aerea, ma mi sfugge un particolare. Di norma, su un velivolo dotato di fotocamera, si monta un GPS, in modo che l'ortofoto derivata dal rilievo sia automaticamente georeferenziata. Che tu sappia, c'e' qualcuno al mondo che abbia fatto un SfM accoppiato ad un gps, in modo che il PLY abbia almeno coordinate Lat/Long..? |
|
|
In reply to this post by geodrinx
Il 05/01/2014 14:48, Geo DrinX ha scritto:
> Però, secondo me, bisogna partire con una "manovra a tenaglia", con più > richieste da più fronti (OOOOPS, non dovevo dirlo ? ) o, molto meglio, mettendosi a scrivere il codice, oppure trovando le risorse perche' qualcuno lo faccia. saluti. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [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 |
|
|
In reply to this post by antoniovinci
Inviato da iPhone Il giorno 05/gen/2014, alle ore 16:35, antoniovinci <[hidden email]> ha scritto: > / > Geo DrinX wrote >> L'elaborazione è stata effettuata tramite la SfM > > / > Davvero spettacolare, sento che questa tecnica stravolgera' la > fotogrammetria aerea, ma mi sfugge un particolare. > > Di norma, su un velivolo dotato di fotocamera, si monta un GPS, in modo che > l'ortofoto derivata dal rilievo sia automaticamente georeferenziata. > > Che tu sappia, c'e' qualcuno al mondo che abbia fatto un SfM accoppiato ad > un gps, in modo che il PLY abbia almeno coordinate Lat/Long..? Certo. Il drone ha (in genere, come in questo caso) un GPS a bordo, per volare su certe posizioni e per documentare (approssimativamente) dove ha volato. Ma in realtà la SfM non ha bisogno del GPS, e calcola da solo le posizioni esatte, sebbene relative e fuori scala, dei punti di vista. Poi, il modello 3d viene calcolato, punti e tin, orientato in un modo qualsiasi nello spazio, più o meno orizzontale, ma da orientare e posizionare e scalare tramite punti di controllo, di coordinate note, visibili nel rilievo. Il formato di uscita dei programmi SfM (open source oppure commerciali) è il PLY binary. Quindi, si puó capire quanto è importante e opportuno implementare in questo formato in un Gis. Chi non lo supporta a breve rimarrà indietro ;) Ciao Roberto _______________________________________________ [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 |
|
|
In reply to this post by pcav
> o, molto meglio, mettendosi a scrivere il codice, oppure trovando le
> risorse perche' qualcuno lo faccia. Se lo faccio io, qualcuno mi pagherà ? ;) So già la risposta: la Gloria... Chissà che ne penserà mia moglie (dato che non si chiama Gloria :) Ciao Roberto > saluti. > > -- > Paolo Cavallini - www.faunalia.eu > QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [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 |
|
|
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 _______________________________________________ [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 |
|
|
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 <[hidden email]> ha scritto: Il 05/01/2014 17:34, Geodrinx ha scritto: 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 |
|
|
Scusate, mi ero perso una risposta di Paolo, che riportava la stessa cosa... Il giorno 09 gennaio 2014 11:27, G. Allegri <[hidden email]> ha scritto:
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 |
|
|
In reply to this post by giohappy
Sì, ma è in Grass 7. A quando in QGis ? Roberto _______________________________________________ [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 |
|
|
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 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 |
|
|
In reply to this post by giohappy
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 |
|
|
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 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 |
|
|
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:
_______________________________________________ [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 |
|
|
Su qyesta libreria fornisco la mia esperienza: ma dopo mezza giornata di tentativi ci dovetti rinunciare.Se ricordo bene vi furono un paio di dipendenze che non risuscii a soddisfare.In occasione della ultima migrazione che ho fatto , ho provato a compilare assieme al postgis anche la SFCGAL, 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:
-- ----------------- 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 |
|
|
Ciao Andrea, 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:
_______________________________________________ [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 |
|
|
In reply to this post by giohappy
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 il programma "legge" la coordinata Z integrata geometricamente nelle isoipse, e crea il Dem senza problemi... |
|
|
In reply to this post by giohappy
Intendevo dire differenze tra con e senza le cgal. La scelta tra cgal e normale avviene in fase di compilazione giusto ?A. Il giorno 09 gennaio 2014 14:34, G. Allegri <[hidden email]> ha scritto:
-- ----------------- 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 |
|
|
In reply to this post by antoniovinci
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'.Il giorno 09 gennaio 2014 14:38, antoniovinci <[hidden email]> ha scritto: / -- ----------------- 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 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |